Below the connection to a LDAP tree is covered. Thereby Mageni uses a very simple interface. While other most systems supporting LDAP first search for the matching object in the LDAP tree and subsequently log in as this object afterwards (Search&Bind), Mageni uses a simple bind with a hard coded object path.
Then the distinguishedName of the objects can be defined distinctively. Thereby the wildcard %s replaces the username. Examples for the Auth. DN are:
While the two first examples should work for any LDAP server with the correct attributes, the third and fourth example are typical formats used by Active Directory. Hereby the exact location of the user object is irrelevant.
The first example does not support users in different sub trees or different recursive depths of an LDAP tree. All users that need to log into the Mageni must be in the same branch and in the same level of the LDAP tree! The second example uses the uid attribute. In this case, uid=user will be used as filter, and ou=people,dc=domain,dc=org will be used as base object to perform a search and to retrieve the corresponding DN for the authentication. Hereby the uid attribute location becomes relevant and should be at the first position.
The other information required is the LDAP Host. Only one system with its IP address or name can be entered here. Mageni accesses the LDAP host via SSL/TLS. To verify the host the certificate of the host must be uploaded to Mageni. Without SSL/TLS the LDAP authentication will not be accepted. Further information is available in the section LDAP with SSL/TLS.
Once you have enabled LDAP authentication, you will notice a new option LDAP Authentication Only in the New User section which will be off by default. Checked it if the new user should be able to login with the credentials configured in the directory service. For existing users you may enable this option through the Edit User dialog.
Please note that the user has to exist with this name in your directory service prior to use with Mageni. Mageni will not add, modify or remove users in your directory service. It will also not grant any user from your directory service automatically access to Mageni. You have to authorize every user separately by adding a user with the same name to Mageni with Allow LDAP-Authentication only checked as described above.
Also note that a locally configured user (i.e. a user which is not enabled for LDAP authentication) “Smith” on Mageni takes precedence over a user “Smith” in the connected directory service.
LDAP with SSL/TLS
Mageni uses either the command StartTLS via the LDAP protocol on port 389 or SSL/TLS via LDAPS on port 636. Therefore the LDAP server must make its services available via SSL/TLS. The exact configuration of all available LDAP servers is out of scope for this manual. Therefore the following are just a couple of references:
- Microsoft: http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
- OpenLDAP: http://www.openldap.org/doc/admin24/tls.html
In order for Mageni to verify the identity of the LDAP server it must trust its certificate. For this the certificate of the issuing certificate authority must be stored on Mageni. To do so the certificate of the certificate authority must be exported as a Base64 encoded file. A Base64 encoded certificate is often using the file extension
.pem. The file itself starts with
If the certificate authority is an intermediate certificate authority the complete certificate chain needs to be imported. This is often true if an official certificate authority is used because the Root CA is separated from the Issuing Certificate Authority. In these cases the contents of the file looks like:
-----BEGIN CERTIFICATE----- ...... Issuing Certificate Authority ...... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ...... Root CA ...... -----END CERTIFICATE-----
The actual place where you may find this certificate may vary based on your environment.
Univention Corporate Server (UCS)
Here you may retrieve the CA certificate from the file
/etc/univention/ssl/ucsCA/CAcert.pem. This file already contains the certificate in the correct format and must be uploaded when enabling LDAP.
Active Directory LDAP
If your Active Directory LDAP service does not yet use LDAPS, you may find the following article helpful: http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx The Active Directory LDAP — CA certificates can then be exported using the following procedure which must be performed from a desktop or server that has access to the Certification Authority console.
- Open the Certification Authority console from any domain-joined computer or server.
- Right-click the name of the certification authority and then select Properties.
- In the CA certificates dialog box, choose the General tab, and then select the certificate for the certification authority you want to access.
- Choose View Certificate.
- In the Certificate dialog box, choose the Certification Authority tab. Select the name of the root certification authority and then choose View Certificate.
- In the Certificate dialog box, choose the Details tab and then choose Copy to File.
- The Certificate Export Wizard appears. Choose Next.
- On the Export File Format page, select the Base-64 encoded X.509 (.CER) option.
- Choose Next.
- In the File to Export box, choose the path and name for the certificate, and then choose Next.
- Choose Finish. The .cer file will be created in the location that you specified in the previous step.
- A dialog box appears to inform you that the export was successful. Choose OK to finish.
The contents of the file must be uploaded when enabling LDAP.
If the LDAP authentication does not work please verify that the entry in LDAP Host matches the commonName of the certificate of the LDAP server. If there are deviations Mageni will refuse using the LDAP server.