LDAP auth syncs but users can't authenticate...

[Mike Stanley]

Hi all,

I'm having an issue I can't seem to figure out... maybe partially because I don't completely understand out Gitblit passes or attempts to pass authentication requests to the LDAP server, but here goes:

I have my LDAP configuration successfully connecting to my Active Directory domain, using Gitblit GO on CentOS 7.

It syncs my users to the users.conf file.
It is correctly syncing my git groups to the AD groups I've pointed it at.
Everything looks dandy, except when I try to login with an LDAP user, I'm told Invalid User Name or Password!

The only notification in the log says "Failed login attempt for *username*, invalid credentials from *ip address*"

I am 100% positive I am using correct credentials. I am out of ideas.

halp?

Thanks,

~Mike

[James Moger]

If you search the forum for "debug ldap" you'll find some JVM config options to enable verbose logging for the LDAP client library.  That may shed some light.

-J

--
You received this message because you are subscribed to the Google Groups "gitblit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitblit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Stanley]

Great, I'll do that.

Thank you. I'll report back if I find something useful to you/the community.

To unsubscribe from this group and stop receiving emails from it, send an email to gitblit+u...@googlegroups.com.

[Mike Stanley]

So I've determined that my login binds are failing because, presently, I have my bind pattern as follows:
realm.ldap.bindpattern = CN=${username},OU=Users,DC=vectorform,DC=com

However, in looking in my AD attribute editor, I'm noticing that my CNs are actually equal to Display Name in most cases.

Is there a Gitblit variable similar to ${username} but for ${displayname} ?

[Mike Stanley]

OK, Anybody using Windows AD with Gitblit, I figured out my issue. I know i've seen this posted elsewhere in the forum with no resolution so let me recap:

You have Gitblit syncing your users.conf from AD, but your users still cannot authenticate, you see invalid credentials errors.

The root of my issue was that my bindpattern was set to:
realm.ldap.bindpattern = CN=${username},OU=Users,DC=domain,DC=com

However, in our Active Directory domain's DNs, CN is not equal to username, CN is equal to displayname.
This was causing me to have auth issues.

I changed my bindpattern to simply:
realm.ldap.bindpattern = domain\\${username}

My users can not log in. Below for your reference is a complete [sanitized] Gitblit LDAP configuration that is currently working in a Windows AD environment:

realm.ldap.backingUserService = ${baseFolder}/users.conf

realm.authenticationProviders = ldap
realm.passwordStorage = md5               

# URL of the LDAP server.
realm.ldap.server = ldap://I.P.Address.Redacted:389

# Login username for LDAP searches.
realm.ldap.username = domain\\adminuser
realm.ldap.password = adminpass

# Bind pattern for Authentication.
realm.ldap.bindpattern = domain\\${username}              

# Delegate team membership control to LDAP.
realm.ldap.maintainTeams = true

# Root node for all LDAP users
realm.ldap.accountBase = DC=domain,DC=com

# Filter criteria for LDAP users                
# The filter I made will show all accounts that are in the 'employee_users' security group, in the Groups OU, OR
# in the 'admin_users' group in the Admin OU, OR are in the 'contractor_users' or 'intern_users' groups in the Groups OU
# it will additionally only show accounts whose objectClass=user, and will filter out any object with objectClass of computer.
# The last part [(userAccountControl:1.2.840.113556.1.4.803:=2)] will filter out any disabled account.

realm.ldap.accountPattern = (&(|(memberOf=CN=employee_users,OU=Groups,DC=domain,DC=com)(memberOf=CN=admin_users,OU=Admin,DC=domain,DC=com)(memberOf=CN=contractor_users,OU=Groups,DC=domain,DC=com)(memberOf=CN=intern_users,OU=Groups,DC=domain,DC=com))(objectClass=user)(sAMAccountName=${username})(!(objectClass=computer))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

# Root node for all LDAP groups to be used as Gitblit Teams
# This is a separate OU I created just for security groups to be used as GitBlit teams
realm.ldap.groupBase = OU=gitblit,DC=domain,DC=com

#Group bind pattern
realm.ldap.groupMemberPattern = (&(objectClass=group)(member=${dn}))        
realm.ldap.groupEmptyMemberPattern = (&(objectClass=group)(!(member=*)))

# LDAP users or groups that should be given administrator privileges.
# This is also in my gitblit teams OU
realm.ldap.admins = @gitblit_admins

realm.ldap.displayName = displayName
realm.ldap.email = mail   

# Attribute on the USER record that indicate their username to be used in gitblit
# when synchronizing users from LDAP
realm.ldap.uid = sAMAccountName

# Defines whether to synchronize all LDAP users and teams into the user service
realm.ldap.synchronize = true
realm.ldap.syncPeriod = 5 MINUTES
realm.ldap.removeDeletedUsers = true

[Mike Stanley]

Sorry, I made a typo above.

It should say "my users can NOW log in" instead of "my users can NOT log in" before my config.

[James Moger]

Awesome. Thanks for sharing the AD config. I'm sure it will help others down the road.

-J

--
You received this message because you are subscribed to the Google Groups "gitblit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gitblit+unsubscribe@googlegroups.com.

[Florian Zschocke]

Note to self: This is a use case where it seems to make sense to have a bindpattern set and still use an admin user for synchronization.

[Florian Zschocke]

Mike,

could you explain why you set the realm.ldap.bindpattern?

Logins should have worked without it being set. What was the use case / intention behind setting bindpattern?

Thanks,
Florian

[Mike Stanley]

I had used a base config to get started that included it, so I had assumed it was required. Broke things until I set it to what I posted above. Never tried removing it completely.

[Florian Zschocke]

I had used a base config to get started that included it, so I had assumed it was required. Broke things until I set it to what I posted above. Never tried removing it completely.

Thanks, Mike. That confirms my suspicion that  the bindpattern property wasn't documented clear enough.