Sync users with AD

I would like connect/synchronize users with AD. I have test active directory with domain name “golob.test” (windows 2012 server)

My settings for authentication source are:
Authentication Type LDAP (via BindDN)
Authentication Name : TestAD
Security Protocol: Unencrypted
Port: 389
Bind DN: /empty/
Bind Password: /empty/
User Search Base: User Search Base
User Filter: (&(objectCategory=Person)(sAMAccountName=%s))
Admin Filter: /empty/
Username Attribute: sAMAccountName
First Name Attribute: /empty/
Surname Attribute: /empty/
Email Attribute: mail
Public SSH Key Attribute: /empty/

Use pagesd Search: not checked
Getch Attributes in Bind DN Context: not checked
Enable user Synchronization: checked
This Authentication Source is Activated: check

When I try to “synchronize extenarl user data” (from dashboard) I see this in Log:
2019/01/11 15:20:11 […gitea/models/user.go:1544 SyncExternalUsers()] [E] LDAP Search failed unexpectedly! (LDAP Result Code 1 “Operations Error”: 000004DC: LdapErr: DSID-0C09072B, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 )

I’ve also tried to change Security Procol to “StartTLS”. After that I get error:
2019/01/11 15:31:02 […gitea/models/user.go:1544 SyncExternalUsers()] [E] LDAP Connect error, LDAP Result Code 52 “Unavailable”: ldap: cannot StartTLS (00000000: LdapErr: DSID-0C090F7B, comment: Error initializing SSL/TLS, data 0, v2580 )

What am I doing wrong?
Can anyone please share with me “working” configuration for Active directory?

Thanks for help.

Matej Golob

The main thing is that AD does not allow querying it without any authentication before. You can see this right in your first error message.

If you use the BindDN option you have to provide a (unprivileged) user that has permissions to read the attributes of your users.

In AD the user name could be given as sAMAccountname, distinguishedName or the userPrincipalName attributes that you can see when you do a manual ldapsearch or when you enable the attribute editor in AD users and computers. (or even through PowerShell with Get-ADUser)

Usually generate a random complex user password that you keep in a Keesafe but it will be store within gitea in plaintext as you can see the warning.

The second issue is that as soon as you enable StartTLS are likely using an AD-integrated CA for your DCs or self-signed certificates which gitea doesn’t trust automatically. You will either have to enable the checkbox to ignore the certificate validation OR (better) have to find out how to provide it on your platform.

1 Like