I was recently working on a project that required us to integrate our Spring MVC application with Microsoft’s Active Directory (AD).
Most online tutorials discuss using a privileged system account for perfoming lookups of the user’s distinguished name (DN) based on the provided at login user name. Setting up a generic system account to enable authentication from our application became problametic due to organisational policies.
Normally, it is possible for users to bind to LDAP without the additional system account provided:
- Anonymous searches are allowed, or
- All users are given permissions to search the directory
… and the normal way of getting this set-up to work using Spring Security is to use the LdapAuthenticationProvider.
Unfortunately, AD works differently and “supports its own non-standard authentication options”. This makes the use of the standard LDAP authentication provider difficult without extending its functions (an approach that we briefly entertained but wisely reconsidered).
While looking for alternatives, we’ve stumbled upon the ActiveDirectoryLdapAuthenticationProvider class (available as of version 3.1). As the name suggests, this class implements the authentication options specific to the Active Directory implementation. Using this provider made authenticating to AD from our Spring MVC application trivial.
So, what’s the difference? As we already established, normally LDAP authentication is performed using the user’s DN (e.g.
CN=grigori,O=Goldman Consulting Pty Ltd,L=Melbourne,ST=VIC,C=AU). In the case of AD, however, the domain user name
is used instead (e.g. firstname.lastname@example.org). The authentication is performed against the userPrincipalName attribute and
depending on configuration, the domain suffix can be omitted making things even simpler for users. Most importantly, no additional
permissions need to be granted to users.
I won’t dwell too much on how to wire Spring Security into your application, there are plenty of great tutorials and blogs that discuss this topic. Instead, what is presented here is an example of configuring the AD authentication provider. The first constructor argument, the domain, is optional but unless provided, it would require all users to enter their entire domain user name including the @ suffix. Unless you use AD for cross-domain authentication, it is best to set this option.