1. Home
  2. Categories
  3. Support
  4. Permissions only work when set for specific user, not a group (LDAP)

Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Permissions only work when set for specific user, not a group (LDAP)

  • K

    Hello,

    I logged an issue here: https://forums.inedo.com/topic/3271/cannot-push-nuget-package-to-ldap-secured-feed?_=1646689732560 about not being able to upload packages to an LDAP secured feed. It was indicated there that the NuGet client queries the feed first which does not use any API key, so we had to enable Anonymous permissions to View/Download on all feeds. Why is that the case?

    Also, I think this is related to that, we tried to set permissions to View/Download feeds at an LDAP security group level, but users are getting a 403 unauthorized. If I scope the permissions directly to the user it all seems to work as intended. Am I configuring the LDAP group permissions incorrectly?

    0
  • stevedennis
    inedo-engineer

    Hi @kichikawa_2913 ,

    The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of api and the password of your api key.

    Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.

    The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.

    Cheers,
    Steve

    1
  • K

    Thank you for the response.

    1. Using the username of api and the api key as the password, is that setup in the Task/Permissions section or in a NuGet.config file?
    2. I used the "test privileges" function and it shows that the group has View/Download permissions.
    3. My user is directly in the group, not indirectly by some other group.
    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    I believe Steve is suggesting for each user to create a personal API key and then use that to authenticate their NuGet feed. That would allow you to use api as the username and api key as the password. As for where this would be setup, you would create the personal API key in ProGet and use that in the NuGet config.

    Just a couple of other questions.

    • Are users downloading packages using Visual Studio or the NuGet cli?
      • Visual Studio will actually use the Credential Manager and you would have to change the credentials in there.
      • The NuGet.config is typically better used for the NuGet CLI
    • Can the user log in to ProGet's UI and view/download the packages in the feed from the UI?
      • This would indicate that the permissions are configured correctly in ProGet.

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf thank you for the clarification!

    1. Users are downloading packages using Visual Studio and I did see it prompt for credentials that are stored in the Windows Credential Manager.
    2. The users can log into the ProGet UI but are not able to view or download any packages from any feeds despite having the permissions setup with an LDAP group. They are only able to accomplish this when I scope permissions/tasks directly to a user.

    We do have "Search recursively" enabled in our LDAP setup.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    Thanks for checking that for me. Based on the fact that you cannot view/download the packages via the UI, this sounds like a permissions configuration issue. Is it possible to share a screen shot of your permissions configuration? You can send it to support@inedo.com with the subject of [QA-785] Permissions Configuration if you do not feel comfortable posting on the forums. This will give us a better idea of things to check for (we would also not post any AD group names directly in the forums either).

    One last thing, can you confirm the version of ProGet you are using and the version of the InedoCore extension you have installed?

    Thanks,
    DAn

    0 K 1 Reply
  • K

    @Dan_Woolf said in Permissions only work when set for specific user, not a group (LDAP):

    [QA-785] Permissions Configuration

    Sending an email with screenshots.

    We are running 6.0.8 Build 5 and InedoCore 1.13.0 with and update available to 1.13.1.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    Thanks for sending that over. Could you also screenshot the "Domains / User Directories" tab and send that over? Your permissions look correct, I'm wondering if there is another setting that might be conflicting.

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf Sent

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    I think I see what is happening. You currently have both the Built-in and the LDAD user directory enabled. I'm guessing you have users added to the Built-In directory with the same username and it is favoring them. Since those are not in the LDAP group, it is not accepting the permissions. Since you are currently only using the LDAP user directory, I would suggest disabling the Built-In directory.

    The other options would be to remove those users from the built-in directory or add groups to the Built-In with the same name as the LDAP groups and give those groups permissions.

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf we only have one "emergency admin" account created with the built-in method. The only reason that is enabled is because the UI recommended it be enabled in case of an emergency or when switching between methods. We have absolutely no users from AD setup on the built-in method.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    Could you try two things for me?

    1. Temporarily disable the Built-In directory and see if it works?
    2. Re-enable Built-In and login with the user name in the format of "user@domail.local"?

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf 1 did not work and 2 lets me log in but results in 403 unauthorized still.

    0 stevedennis 1 Reply
  • stevedennis
    inedo-engineer

    @kichikawa_2913 I'm wondering if this might be a regression with the preview feature, but I can't imagine how. I have one other idea, too...

    I used the "test privileges" function and it shows that the group has View/Download permissions.

    Can you clarify this? The "test privileges" should only work with a username, not a group name. Could share what happens when you:

    1. Have a specific user navigate to a package in a NuGet feed, and then try to download it from UI? Is there a specific message body you see? (outside of 403)
    2. Enter that same username in the "test privileges" with that particular feed? What are all the permissions you see?

    After doing those, the last thing I would try is to revert to the 6.0 behavior, and see if the problem still occurs. AT least that will tell us where to look....

    0 K 1 Reply
  • K

    @stevedennis

    1. User logs in, clicks on "Feeds", and only sees the 403 message on the page with nothing else available.
    2. I sent an email with screenshots of the test privileges for the group and specific user in that group.

    What do you mean by "revert to the 6.0 behavior"? We are on 6.0.8, should we revert back to the initial release of 6.0.0?

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    When you are on the "Domains / User Directories" tab, you should see a link at the top that says "revert to single-directory mode". Steve is requesting that you click that link and see if the problems with the groups still exists.

    Thanks,
    Dan

    0 K 1 Reply
  • Dan_Woolf
    inedo-engineer

    Also, I just reviewed the email you sent about the view effective privilege's and it looks like something is not linking up correctly for your users group. Would you be able to run the our AD Test tool 1.13.1 from a windows computer and see if your users show up when searching for members in that group? You will see a tab in that tool called "Get Group's Users". It will allow you to verify we are pulling those users back in that group.

    Thanks,
    Dan

    0 K 2 Replies
  • K

    @Dan_Woolf from a Visual Studio perspective it seems to be working better, meaning we can see all versions for a package but unable to download certain versions of packages. The only example I have so far is Selenium ChromeDriver NuGet.

    Error Package 'Selenium.WebDriver.ChromeDriver 99.0.4844.5100' is not found in the following primary source(s): 'https://repo.dev.summit.network/nuget/approved-nuget/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

    Despite the package version there and downloadable:

    a25df9c7-5287-4248-8d11-b925c9e241e1-image.png

    If I log into the UI with a user from that group I still get 403.

    0
  • K

    @Dan_Woolf I'm not getting any users back, I emailed you the debug log.

    0
  • K

    @Dan_Woolf sent a second email showing all the settings used in the tool.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    Do you happen to have multiple groups with the same name in different OUs? Your log output looks like it found the group, but then the search for the users is not returning any users. If you look at the last line of the debug statement you sent, it shows the group name and OUs it is using when searching. That starts at memberOf=CN=<Group_Name>,OU=.

    Thanks,
    Dan

    0
  • S

    @kichikawa_2913 Not sure if this is related to your problem, but we had some strange problems after upgrading to ProGet 6.0.8 / 6.0.9 as well, so maybe sharing the following info might help you:

    We first encountered problems after upgrading to ProGet 6.0.8: Users could access feeds, but could not download any packages. After upgrading to version 6.0.9 this was resolved.

    We then had a problem where access became very slow until users could not access any ressources on our ProGet server anymore (even those with "Anonymous" access rights!). We deactivated the "6.1 Preview Features" and restarted everything (including the IIS). This resolved the issue. We also updated the InedoCore extension, but I don' t think this was related to the problem.

    I think the 6.1 features are still kind of buggy. We try to avoid activating them for now.

    1 K 1 Reply
  • K

    @sebastian thanks for the info! We'll try to update to most recent version and restarting the instance.

    @Dan_Woolf we don't have that group in different OUs from what I can see, that looks like the "path"/hierarchy to the group ("Security Groups" -> "Roles" -> "IT"). I'm not as familiar with AD as I would like to be, so I'll ping our admins on that.

    0
  • K

    We are now having issues just creating the container getting the following error:

    Error: error creating temporary passwd file for container 441b7e059858087ded586bf7b20a02284af788603bd6fb67e532a0021107db1c: open /home/{username}/.local/share/containers/storage/overlay/6b312eb340dc2cafa8c6aaccdec719d8c249b226b4825ada3250bafd209a607d/merged/etc/passwd: value too large for defined data type

    I don't think this is related to ProGet, so I'll report back after we get this resolved.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    I would agree that does not look like a ProGet error. Please let us know what you find.

    Thanks,
    Dan

    0 K 3 Replies
  • K

    @Dan_Woolf the issues we were running into (value too large for defined data type) were related to our AV being installed and enabled on the server.

    @sebastian we updated to 6.0.10 and made sure InedoCore was up-to-date and we are still seeing issues where scoping view/download permissions to an AD group does not work but adding "Anonymous" or specific users does work.

    0
  • K

    @Dan_Woolf working with some other team members, we found that the user we are using for the AD configuration does not have permissions to enumerate the user groups. I tried with a different user that does have permissions and view/downloading packages from the UI works fine, but from Visual Studio still does not. I tested using pre 6.0 security features and post-6.0 features with the same results.

    So part of the issue is the permissions of the user we are using in the AD configuration.

    0
  • K

    @Dan_Woolf something else I noticed in the preview security features is that I can't find where to manage the AD credentials for the LDAP integration user. I had to revert back to pre-6.0 behavior to do it.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    For managing the AD Credentials, that will be fixed in ProGet 6.0.11. Unfortunately, that was not caught in time for the release, but it is fixed in a current development branch.

    So I just want to make sure I understand the current state.

    • You have updated the AD Credentials to use a user that can query groups.
    • When you test the permission in ProGet it shows view/download.
    • When one of those users logs into the ProGet UI, they can view and download the packages fine.
    • When they try to view and download from Visual Studio, it does not work.

    Can you confirm that is correct?

    When the user is using visual studio, are they logging in with their domain username and password? Or are they using an API key (username api the key as their password)? Can you try resetting the credentials used for visual studio? We have a walk through on how in our troubleshooting section of the how to add a repository to Visual Studio How To.

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf All your bullets are correct and I did clear out my Visual Studio credentials; re-entering my credentials appears to have resolved the issue even with the 6.1 preview features enabled. I did not use an API key, I just entered my Windows credentials.

    We are going to get our LDAP integration user corrected and continue to test to be sure. Thank you all for your help! It is greatly appreciated.

    0
  • Dan_Woolf
    inedo-engineer

    Hi @kichikawa_2913,

    Glad to hear it is working now. I know the NuGet client does a lot of caching on it's side, so it is very possible that resetting the credentials for Visual Studio forced a reset of that, but I'm not positive. Either way, I'm happy it is working for you now! Please let us know if you find any other issues with it.

    Thanks,
    Dan

    0 K 1 Reply
  • K

    @Dan_Woolf everything seems working as expected except for the following error from Visual Studio:

    Severity Code Description Project File Line Suppression State Error Package 'Selenium.WebDriver.ChromeDriver 99.0.4844.5100' is not found in the following primary source(s): 'https://repo.dev.internal/nuget/approved-nuget/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

    This error has apparently been reported since before we started working in this ticket. Should I open a new ticket to look into this one? This seems to be the only package we have this issue with, if we go directly to nuget.org we do not have this issue.

    0
  • K

    Seems to be related to versions after 95.0.4638.6900, we are able to install that version and prior without issues from ProGet.

    0
  • rhessinger
    inedo-engineer

    Hi @kichikawa_2913,

    Could you please open another topic for the Selenium.WebDriver.ChromeDriver issue? I think that is unrelated to the authentication issue.

    Thanks,
    Rich

    1
Log in to reply
 
Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation