Part 7: Setup LDAP authentication
Critical Angle is a company cited on the original RFC for LDAP. This picture demonstrates the engineering concept of critical angle. It’s also cool looking. Did you know the angle of repose of fresh coffee beans is 35–45°? That’s right, you can drink it.
Note that I use Microsoft Active Directory for my LDAP directory services.
Create an LDAP querier group and an account
On your domain controller, run dsa.msc, and create a group. For this example, the group name is “LDAP_Users”.
Then create a user and set the password to be very complex and set it to never expire (or as you wish). For this example, the username is “ldapquerier”.
For ldapquerier, go into the user properties. Add ldapquerier to be a member of LDAP_Users.
Set this group as it’s primary user group and remove it as a member of Domain Users, just in case anything is secured using Domain Users (like the roots of shares, etc.).
We’ll use ldapquerier as the object we’re granting permissions, but you may use LDAP_Users instead.
Determine the LDAP access rights redmine and rhodecode need
According to the documentation, it is safe to assume the following:
Depending on which OU (or the base of your domain) your user objects reside, you must grant ldapquerier access to the following attributes of objects:
First name = givenName Email = mail Login/Account ID = sAMAccountName Last name = sn
Verify access in Active Directory
This is done on a Windows 2003 DC. Note sure if this has changed in Windows 2008.
Once again start dsa.msc.
Check View> Advanced Features.
Traverse your Domain OU tree until you arrive at an OU that contains user objects that you expect to authenticate.
Right-click> Properties> Security tab> Advanced> Effective Permissions> Select> ldapquerier> OK.
Look at that. Not sure where those permissions are coming from, but ldapquerier has Read All Properties permissions.
In fact, ldapquerier will be considered to be part of Authenticated Users once whatever redmine and rhodecode use to query LDAP authenticates against the server.
Configuring Active Directory for LDAPS
Seems idiot proof… too idiot proof. As in, it’s just automatically enabled when the server gets a certificate and key pair installed into it’s certificate store. That’s pretty vague and uncontrollable.
I’ll need to expand this a bit
Configure redmine for authentication over LDAPS
- Log on to redmine’s UI by accessing https://SERVERNAME.domain.local/
- Logon using admin:admin (we’ll reset this password shortly).
- Click on “Administration” on the top menu, then “LDAP Authentication” in the list.
- On the “Authentication modes” page, click “New authentication mode.”
- Enter the configuration as follows then click Create:
- Next to the list item “globalcatalog.domain.local” click test, and a shiny green “Successful connection” message should appear near the top of the page.
Change the admin password
Click Administration on the top menu, click Users, click the entry for ‘admin.’ Change the settings. I suggest you change the name of the admin user, but use the internal authentication for this user, in case you need access and LDAP is unavailable.
Configure rhodecode for LDAPS authentication
- Log on to the rhodecode web UI by accessing https://SERVERNAME/rhodecode.
- Logon as admin, and use the password you used much earlier.
- On the menu near the top right, hover over Admin, then click on ldap.
- Enter the configuration as follows then click Save:
For Rhodecode, most errors will be reported in /var/log/pasteserve.log, so you can throw a tail on that while authenticating to see errors.
For instance, I had configured my admin user with my Email address. So when I attempted to logon with my AD user object, where the email attribute was set to my Email address, I saw the following error in the log:
IntegrityError: (IntegrityError) column email is not unique
A condition will occur that if a username exists in the local database of Rhodecode or Redmine, the LDAP credentials with the same username will not be presented for authentication. Meaning, if your LDAP logon is mbrown and you created a username in Rhodecode mbrown, then the Rhodecode user mbrown will be the user the user will use.
Also check out using tcpdump to verify network communication:
tcpdump -c 100 -w ~/ldapquery.pcap port 636
Lastly, as of Rhodecode 1.2.3, the Certificate Check setting isn’t applied until you restart the paste instance. So, when you have this problem:
raise LdapConnectionError("LDAP can't access " LdapConnectionError: LDAP can't access authentication server
Even when you see the packets going back and forth, it’s probably an issue with the certificate acceptance rules on python-ldap. Try ALLOW instead of TRY. Cycle the paste instance, and you should be good!