Error when running: LDAP failure: no such object.

[BOW-el]

When running the tool, it fails with the following relevant output:

con_gitlab_ldapsync | [notice] 184 directory user(s) recognised.
con_gitlab_ldapsync | ldap_build_search_req ATTRS: cn member
con_gitlab_ldapsync | [error] LDAP failure: No such object. (Code 32)

I suspect that the tool is not finding any groups matching the filter, but I am not sure this is the case. I've set the following settings in the config file:

queries:
    ...
    userUniqueAttribute:            "sAMAccountName"
    userNameAttribute:              "cn"
    userEmailAttribute:             "mail"
    ...
    groupFilter:                    "(objectClass=group)"
    groupUniqueAttribute:           "distinguishedName"
    groupMemberAttribute:           "member"

In our Windows AD, group membership is based on the 'member' attribute, which is a comma separated list of all the unique DistinguishedNames of the members (the full path in the AD). Would the setting be correct in that case? Does the tool support that configuration? Thanks for any lead on what to adjust!

[Adambean]

Hello,

You're right in that PHP's LDAP client is not finding an object that has been specified.

You'd have to use "cn" instead of "distinguishedName" for groupUniqueAttribute, or your group names in Gitlab would be named as their full distinguished name. (E.g. "cn=My Group,ou=Users,dc=example,dc.com" instead of just "My Group".) Also groupMemberAttribute would typically be "memberUid" expecting an array of user "uid" values. (In my Active Directory both "member" and "memberUid" group fields are populated with an equal quantity of values.)

I see you changed userUniqueAttribute to "sAMAccountName" from "uid". Do your users have different values for these? (In my Active Directory the values match for every user, both real and service users.)

[BOW-el]

Hey Adam, Thank you for the fast and helpful answer!

You'd have to use "cn" instead of "distinguishedName"

Got that changed, thank you!

Also groupMemberAttribute would typically be "memberUid" expecting an array of user "uid" values. (In my Active Directory both "member" and "memberUid" group fields are populated with an equal quantity of values.)

In the AD, the groups do not seem to possess a memberUid attribute. Therefore, I can neither see login names nor UID values of group members from the group attributes. Not sure if this is a result from migration. Is it also possible to match group membership with the distinguishedName attribute in general? That is the only connection I have here, the member attribute containing a list of distinguishedNames of all group members...

I see you changed userUniqueAttribute to "sAMAccountName" from "uid"

Users in this AD do not have a UID attribute - only an objectGUID, which is probably not helpful... The SAMAccountNAme attribute contains the login name with which a user would also log into GitLAB The users furthermore have their distinguishedName attribute that could be used for matching, the memberOf attribute containing a list of distinguishedNames of the groups they are a member of and a mail attribute containing their email address.

Do you think your tool could basically work with these conditions?

Again, thank you for your help!

[Adambean]

I'm wondering if my Active Directory has these extra attributes because my server has the subsystem for UNIX feature installed, or perhaps 2012 was the latest version to use it. (Mine is 2008 R2.) -- Equally surprised about the uid attribute missing on users though sAMAccountName should be sufficient.

Looks like you're not the only person to have a problem with memberUid missing: https://github.com/gogs/gogs/issues/4792

It would likely involve a fair amount of re-writing to work with DNs instead of UIDs as it's mainly revolved around what Gitlab expects (a user name, because no end user is expected to enter or even know their entire DN). Possible feature though.

[BOW-el]

That is interesting, I'll try to ask what exact configuration we are running. Maybe it would be of interest to make the tool work with 'standard' configurations of AD structures, if you would like to see the tool in broader use - I'll try to see if our configuration is just exotic or if that structure is more common.

In any way, only the matching of the AD users with the AD groups would have to be done using DNs, the AD users posess usernames and email attributes which gitlab expects in our structure (in the attributes 'SAMAccountName' and 'email'). The groups can already be found using the query structure of the tool. So the DN matching would be done completely outside of gitlab itself. I agree, users can not be expected to enter a DN, so that should never appear in gitlab...

I wonder if the changes might be small, as the tool would primarily have to be programmed to support DNs instead of Usernames for determining group membership of individual users, at least as far as I can see.

[Adambean]

To be honest I've only really played around with two Active Directory instances, both my own, and one was just virtualised about 15 years ago on Windows 2000. However I will be starting a fresh AD in the upcoming months for our office expansion at work, which will be Windows 2019 based, so I'll definitely have a look at what attributes are there as standard. -- I had made the assumption that the groups work as I thought because I've not really done any schema modification to mine other than install the subsystem for UNIX feature, and a custom attribute for holding SSH public keys.

You can almost certainly use "SAMAccountName" instead of "uid", as they will be the same for the majority of cases.

Looks like group member matching just needs some work as "memberUid" doesn't appear to be a standard thing.

[BOW-el]

That sounds great - I am not sure ours is completely standard either but having a solution that works out of the box for standard setups sounds like a good idea. I've tried to expand the group matching section to optionalle use a separate attribute than UserUniqueID. Setting UserMatchingID to 'cn' and UserUniqueID to 'SAMAccountName' now works for us. Thank you for your help in understanding this, I've attached the changes for review above.