Hi,

We recently had a case where Visual Studio as well as some internal tooling was recommending that our projects update System.CompnentModel.Composition to version 2010.2.11.1, which looks to have been built in either 2013 or 2018 and has been unlisted for a long time.

It looks like somehow ProGet cached this version and did not keep track that this package was unlisted by the public Gallery.

Deleting the cached package from ProGet reset it and now it is recommending 9.0.10 as the highest available version again, which is correct.

Do you have any ideas how this would have happened and what can be done to prevent it occurring again on the same or other packages in future?

Is the v5 provider available on Linux, or only on Windows?

We have a new setup we're building using the container image, and AD v5 doesn't show up in Version 2025.8 (Build 17).

Are there any APIs that could be used to automate managing ProGet tasks/permissions?

I couldn't find anything in the docs nor in the pgutil code.

I'd like to be able to issue API requests to e.g. give a user or group certain privileges on a feed, or remove those rights at a later point.

a-ha!

v5 seems to work.

It has the same problems with the Test User Directories dialog, it says that my user is a member of proget_users (correct) but does not say that my user is a member of PGUSERS (incorrect).

However, that fades into irrelevancy - when I go assign a task/permission to the group, it saves it as proget_users@proget.test and not as PGUSERS@proget.test, so then when I log in it can follow the entire chain from proget_test_user -> memberof proget_users -> has Administer right.

How far along is v5? Is that prerelease build stable enough that I could give it a spin in our current production environment, or should I wait until its released as stable?

@stevedennis
It can't find the group on its own:


But it does find it as part of all groups:

This whole approach seems a lot more finnicky. The AD solution seems to be clearer and more reliable, it just has that bug with the mismatching object properties.

I can kind of get it working under OpenLDAP/Generic directory with the "Test User Directories" tool by setting the queries to match AD and then setting LDAP Object > Group Name Property Value to distinguishedName. However, if I then try and assign any privileges to that group, it doesn't save it and there are no errors logged.

I don't think the issue is that ProGet's Active Directory Integration does not support Active Directory group lookup using a "pre-Windows 2000" Group Name as much as ProGet's Active Directory Integration does not support any group where the "pre-Windows 2000" Group Name differs from the Group Name, which I believe is where name and sAMAccountName differ.

When looking up what groups a user is a member of, that system relies upon group name.
When assigning permissions to a group, that system relies upon the pre-2K name.

Those two systems aren't talking to eachother unless the values happen to match (which to be fair is going to be the 99% case).

Having the link to the code now, I think the bug is here:

https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/PrincipalId.cs#L51-L54

This hardcodes sAMAccountName (i.e. "PGUSRS") as the primary source of group name, and only falls back to name if it is not present.

But then, when checking the memberOf property of the user, that is done here against the group's full X.500-style name ("CN=proget_test_user,DC=proget,DC=test")

https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/Clients/DirectoryServicesLdapClient.cs#L103-L107

Even though the "group name property name" is overridable (https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ActiveDirectory/ADUserDirectoryV4.cs#L113-L118) neither of these code paths use it, so changing that doesn't help.

I haven't tried OpenLDAP/Generic yet, I may give that a try this afternoon.

I've run the same query that the Test User Directories pane spit out in its little debug log there and it returned exactly what I expected. The user is in that group.

I have spun up a completely separate test system to reproduce this, running Windows Server 2025 with the default Azure image.

1. Install Active Directory Domain Services and IIS. Make sure to install Windows Authentication for IIS.
2. Create a new forest. I used the domain name proget.test.
3. Create an AD user for ProGet to run as. I made app_proget@proget.test. Give it a password, disable password expiry.
4. Download and install Inedo Hub for Windows.
5. Install ProGet 2025.7 with Embedded database running as the above user account.
6. In Windows Services, set the user password under ProGet Service > Properties > Log On
7. Activate ProGet. I used an Enterprise trial key, but I think a Basic trial will work too.
8. Enable Active Directory v4 (new).
9. Use Test User Directories to make sure that AD integration is working.

Then, to reproduce this scenario:

1. In Active Directory Users and Computers, create a new group. Set the group name to proget_users and the group name (pre-windows 2000) to PGUSRS

   

2. Add yourself as a member of this group

3. Look yourself up as a group member in ProGet:

   

   

To reproduce the exact problem, rather than the general circumstance:

1. Assign permissions (tasks) to this group. For example, Administer. Note that when looking up the group, ProGet displays its "pre-windows 2000" name and persists it as so:

   

   

2. Create a new AD user and add them to this group.

3. Log in to ProGet as the new AD user

4. Note that you have no privileges in ProGet, despite being a member of a group that grants full administrative rights.

   

Hey, I have a bit of an odd corporate setup. I don't know the specifics, but we have some Entra hybrid sync thing going on that synchronises Entra cloud groups into local Active Directory. I'm pretty sure this is a standard offering from Microsoft.

I am trying to utilise this along with Entra Access Packages so that people can request access to groups and have them approved without needing go through an Active Directory admin.

For login we use SAML SSO via Entra, not Windows Authentication. This is documented as ignoring group claims and going straight to AD.

The generated AD groups have very odd names. They look something like $JQA200-TQZJ4H3I77X8@domain even though they have a long name of CN=cg_actual_name_plusrandomizedprefix,OU=Cloud,DC=domain.

Using the "Test User Directories" feature of ProGet, I can see the members of the group whether I look up $JQA200-TQZJ4H3I77X8 or look up cg_actual_name_plusrandomizedsuffix, I can correctly see the members.

If I look up a user and group together, ProGet can see that a user is a member of cg_actual_name_plusrandomizedsuffix, but it cannot see that the user is a member of $JQA200-TQZJ4H3I77X8.

I believe this is the source of the actual issue I am seeing - when I assign Task permissions to $JQA200-TQZJ4H3I77X8 (e.g. Administer), users who are members of that group do not actually get those permissions.

Group search:

Check membership by SAMAccountName

Check membership by Entra name (plus suffix)