Hi Rich,
Yes, we do have Active Directory at the back end.

Alas the LDAP filters you've specified haven't helped. I'm still seeing the same behavior - everything working except for the Load User by User Name test - user is found but group membership fails. I've run the queries by hand through ldapsearch at the shell, and confirmed by eye that they seem to be returning the correct data. I also tried removing the nested group property modifiers - the results appeared identical but the queries returned a little faster .

Unless you've other instant ideas then I think at this point I can wait until we've got a purchased license (grinding through the corporate works now) and then I'll open a support ticket. That way I can share some LDAP queries and results with you directly. We can update the thread here after that.
Cheers
phil

Thanks Rich,
I think I'd gotten my directories muddled up - not sure how else I managed to start off with a v4 connection. Once I went through the setup process again using the OpenLDAP/GenericLDAP directory format, and got all of the queries correct, then it went from broken to mostly working.

The remaining issue I have seems to be very much like that in the other current LDAP thread. I'll post some details over there.
Cheers
phil

@phil-sutherland_3118 I should add that I've configured the above as a v4/Generic LDAP connection, and we're running 2025.19 as a container on a Linux host.

I'm currently getting LDAP authentication going for our trial Proget instance. We're accessing a corporate AD server, and normally our users are identified via userPrincipalName which is a full "email address" - ie user.name@company.group. The suffix of these names is not always the same as the AD domain - as several companies have been joined together at various times.

I cannot seem to make this work with Proget. I can configure it OK, but trial logins fail. What appears to be happening from the Test User Directories log is that the entered login name is having the @company.group suffix stripped prior to creating the LDAP query. Is this expected behavior?

I've got LDAPS working successfully if I change the "User Name Property Value" field to sAMAccountName instead of userPrincipalName, so we're not stuck, but our most of our users don't remember this constructed field value so it's a bit of a nuisance to have to use it for login.

Thanks for the comprehensive response - which was very helpful.
Closing the loop, we've elected for the short term to run up a parallel aptly server to manage our existing apt snapshots, but in the longer term we'll revisit how we use snapshots at all and very likely will switch our process to use upstream provided snapshots.

We are currently evaluating Proget to possibly replace our existing Sonatype blobstore, and one of the features we currently make of is apt snapshots. The Debian feed documentation in Proget states that apt snapshots are explicitly not supported. Is this functionality on a future roadmap, or is there another way to do this within Proget that we've missed?