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!
LDAP user name suffix removal
-
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.
-
@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.
-
That is expected behavior. ProGet will always strip off the domain suffix from the username. Users in the past have created multiple user directories (one for each suffix) and then using the username@suffix (ex: user.name@company.group) as the login.
An alternative approach is to use the OpenLDAP/GenericLDAP user directory instead. It requires you to enter the AD-based LDAP attributes and queries, but it will not strip off the domain suffix.
Thanks,
Rich
-
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
-
Just to confirm, are you using an Active Directory domain or OpenLDAP doimain in your environment? Your initial post makes it sound like you are using Active Directory and not OpenLDAP. If you are connecting to Active Directory, you can use the following two LDAP settings to get groups and members:
- For List User's Groups:
(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=%s))and for get a groups - For List Group's Members:
(&(objectCategory=user)(memberOf:1.2.840.113556.1.4.1941:=%s))
These will only work when using our OpenLDAP/GenericLDAP user directory and connecting to an Active Directory domain, OpenLDAP domains do not implement these special queries.
That other forums post is a OpenLDAP domain that is using custom attributes for groups.
Thanks,
Rich
- For List User's Groups:
-
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
-
There is nothing off the top of my head that would fix this. The next step would be to see your LDAP queries and potentially some example data. It would probably be best to wait until you get a license if you do not feel comfortable sharing that data on the forums. If you care to look, you can see our code for both our AD User Directories and our OpenLDAP/Generic LDAP user directories on our GitHub repo: https://github.com/inedo/inedox-inedocore
Thanks,
Rich
