One of the more glaring issues with the environment I’m currently supporting is that there’s no single sign on. Workstations and web tools (mostly Atlassian in nature – Stash, Jira, Confluence, et al) all authenticate against our Active Directory environment. However, all of our Linux and Solaris hosts authenticate against a separate OpenLDAP environment, so users have to maintain two different sets of credentials and passwords. This has all the extra baggage that comes from maintaining password policies, such as two different auth sources that you can get locked out from. I elected to take up the task to eliminate one of the environments, and given that our OpenLDAP database was significantly smaller than Active Directory, we decided to eliminate OpenLDAP from the environment.

I considered three approaches for achieving this. The quick and dirty method is to use SASL passthrough authentication, which is supported by OpenLDAP as detailed in this page. In short, you can take an existing user account in OpenLDAP and modify their userPassword attribute, replacing the existing hash with “{SASL}user@domain” which will point to a matching user in Active Directory. While this would satisfy the requirement of single sign-on, it still requires that you maintain an OpenLDAP backend database for all other data, such as homeDirectory, loginShell, uid, gid, and so on.

A second option is to not use an OpenLDAP server at all, and configure all your clients to natively talk to Active Directory. This isn’t terribly difficult as long as you’re using SSSD – see this excellent article on the subject. However, I’d have to gut a large amount of the environment to move to sssd, and it requires some software bloat – namely, Samba – in order to work. While this wasn’t necessarily a dealbreaker, I didn’t think it was the cleanest option.

The third method – and ultimately is the one we chose to pursue – is to continue leveraging an OpenLDAP backend, but proxy the requests to Active Directory. This has the benefit of utilizing a single source of authentication (AD, in our case) and allows us to continue using the native OpenLDAP client that all our hosts are currently utilizing without any additional configuration. Additionally, it would allow any applications that have weaker LDAP client support to continue to work. The OpenLDAP proxy can also remap fields on the fly, taking an OpenLDAP attribute and remap it to its AD equivalent – translating “uid” to “sAMAccountName”, for example. This allows for maximum flexibility without requiring any special configuration on the client side. The only real downside is that you add an additional layer of complexity to the flow of authentication, which means one extra spot you may have to troubleshoot in the event of auth issues. Still, it seemed this approach would be the best one for us.

Continue reading OpenLDAP to Active Directory Proxy Configuration→