In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article, I will discuss basic password authentication for LDAP domains with the posix schema.
For basic password authentication against an LDAP domain with the posix schema, you need to configure three or four things:
- Domain name
- Server names
- How to bind to the LDAP servers
- The proxy user used to find your user accounts (optional depending on your environment)
Please see and complete the “Create a local sysop”, and “Enabling the plugin” sections of part 1 before proceeding.
Configuring the plugin
Setting the domain name
The domain name is used for all of the LDAP configuration settings, and is also the domain name visible to users when logging in. It is recommended to use the short name of your LDAP domain as the domain name. For example, if your LDAP domain is testposix.example.com, then you should use testposix as your domain name. We will use testposix for the examples in this post.
Place the following in LocalSettings.php file to set the domain name:
$wgLDAPDomainNames = array( "testposix" );
Setting the server names
The plugin needs to know the fully qualified domain name (FQDN) of each of your LDAP servers to contact. You may add multiple servers, delimited by spaces, for server failover.
Place the following in LocalSettings.php to set the server names:
$wgLDAPServerNames = array( "testposix" => "ldapserver1.testposix.example.com ldapserver2.testposix.example.com" );
Telling the plugin how to bind to the LDAP server
Binding to the LDAP server can be straightforward if your Directory Information Tree (DIT) is simple; by simple, I mean your users are in ou=people, and they all have the same naming attribute (such as uid). To bind to this type of DIT, you simply need a bind DN format, and a password. You can tell the plugin to create the bind dn by adding the following in LocalSettings.php:
$wgLDAPSearchStrings = array( "testposix" => "uid=USER-NAME,ou=people,dc=testposix,dc=example,dc=com";
Notice that USER-NAME is a special string, and should not be modified. When the user logs in, USER-NAME will be replaced with whatever username is used.
If your DIT is not flat, or your naming attributes aren’t the same for all users, you’ll need to configure the plugin to first find the user’s DN, then bind as that user. To do this, you’ll need a search attribute, a base DN, and optionally a proxy agent and proxy agent password.
Your search attribute must be an attribute that all users share, and should preferably be a unique attribute; we’ll use uid for this. Your base DN must be at a node in your tree that is a parent to all of your users; we’ll use dc=testposix,dc=example,dc=com for this (the root DN). If your directory server allows users to be searched anonymously (which is abnormal), you don’t need to specify and proxy agent or proxy agent password. If your directory server requires authenticated searches (normal), you can specify a proxy agent and proxy agent password; we’ll use cn=proxyagent,ou=profile,dc=testposix,dc=example,dc=com and “T3stP0$ixP@$$” for this. Notice that you should give the bare minimum privileges needed to the proxy agent!
You can set these options by placing the following into LocalSettings.php:
$wgLDAPSearchAttributes = array( "testposix" => "uid" ); $wgLDAPBaseDNs = array( "testposix" => "dc=testposix,dc=example,dc=com" ); $wgLDAPProxyAgent = array( "testposix" => "cn=proxyagent,ou=profile,dc=testposix,dc=example,dc=com" ); $wgLDAPProxyAgentPassword = array( "testposix" => "T3stP0$ixP@$$" );
By default the LDAP plugin is set to bind using encryption. Specifically, the plugin defaults to tls using LDAP (port 389). The supported encryption types are clear, tls, and ssl. Most posix LDAP servers support TLS and SSL. It is recommended to keep encryption enabled. If you need to switch encryption types, you can use the following option in LocalSettings.php:
$wgLDAPEncryptionType = array( "testposix" => "ssl" );
Configuring the server
Configuring the SSL trust
For ssl to work properly, it is important to ensure the LDAP client (the web server) trusts the root Certificate Authority (CA) of the LDAP server. If your organization is using a third party CA that is in most normal trust lists (like in IE or Firefox), this step can likely be skipped. If your LDAP servers are using self signed certificates or a local CA, this step is needed.
You can find out which CA issued the LDAP server’s certificate using openssl. Run the following command:
openssl s_client -connect ldapserver1.testposix.example.com:636 | egrep "subject|issuer"
If the subject and the issuer are the same, the certificate is self signed. If the subject and issuer are not the same, the certificate was signed by a CA. If the CA is local, ask someone in your organization for a copy of the CA certificate. If the certificate is self signed, you can get the certificate by running the previous command without the grep:
openssl s_client -connect ldapserver1.testposix.example.com:636
Copy everything in between, and including:
Paste the text into a file, and place the file wherever your OS normally stores its CA certificates; Red Hat Enterprise Linux 5 and newer versions of Fedora place these in /etc/pki/tls/certs.
Now place the following into /etc/openldap/ldap.conf:
TLS_CACERT <pathToCACert> TLS_CACERTFILE <pathToCACert>
Restart your web server for this to take effect.
Test your configuration by logging in with an LDAP user
Everything should be working at this point. If you have any questions, you should post them on the discussion page for the plugin on mediawiki.org, or leave me a comment (the former is preferred).