Unable to authenticate against Active Directory

I've been playing around for several weeks trying to get Spring Security 3.0.x authenticating against our corporate Active Directory server. The closest I've gotten were either errors around needing to do an authenticated bind before an actual user authentication and bad credentials. I took this to mean we needed to create a service account to bind to AD as and then perform an AD authorization. I will try this once I get that service account.

I then saw that 3.1 has native support for AD authentication so I've tried that but it's now failing because no results are being returned - I was following these instructions: http://static.springsource.org/sprin...tive-directory.

Looking at the debugging information, I'm not sure it's using the correct information and I am unsure as to how to provide it given our setup. Our employee user names are just an ID string, not our names. Our base DN is dc=corp,dc=foo,dc=com. Using an AD browser, our sAMAccountName is <username>@corp.foo.com whereas the value of userPrincipalName is <username>@foo.com.

Here is the code I am trying to execute that returns zero results:

Code:

---

    ActiveDirectoryLdapAuthenticationProvider adlap =
        new ActiveDirectoryLdapAuthenticationProvider("corp.foo.com", "ldap://xx.xx.xx.xx:389");
    adlap.setConvertSubErrorCodesToExceptions(true);

    UsernamePasswordAuthenticationToken auth =
        new UsernamePasswordAuthenticationToken("<username>@corp.foo.com", "<username's password>");
    adlap.authenticate(auth);

---

The debug output is:

Code:

---

DEBUG ActiveDirectoryLdapAuthenticationProvider - Processing authentication request for user: <username@corp.foo.com
DEBUG SpringSecurityLdapTemplate - Searching for entry under DN '', base = 'dc=corp,dc=foo,dc=com', filter = '(&(objectClass=user)(userPrincipalName={0}))'
INFO  SpringSecurityLdapTemplate - Ignoring PartialResultException
org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 0
        at org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:239)
...

---

My division's users are nested down a few layers from the initial tree node of "dc=corp,dc=foo,dc=com" but I don't see a way to specify additional nodes - or know if I even need to.

Any help would be most welcome. Thanks.

I ran into this recently as well using the ActiveDirectoryLdapAuthenticationProvider. I was baffled as this had worked fine for me when pointed it toward my companies domain controller during development.

However we then setup a test lab with a new domain controller and created a user account. I know little about active directory, so originally I got an error that the account was not enabled. After fixing that I ran into the same exception: "org.springframework.dao.IncorrectResultSizeDataAc cessException: Incorrect result size: expected 1, actual 0".

It turns out when creating the account I did not supply a login name. Once I did the exception went away and everything worked. I haven't delved into the details to understand why this happened (particularly as I originally got an exception the account was disabled, so the underlying code seemed to at least partially find the user...).

Hope this helps

So, a month later, here's where we stand:

It turns out our company does not allow anonymous binds or searches against AD and requires SASL (Kerberos) connections. I was able to get beyond the error I pasted above but always wound up getting "Bad Credentials" errors.

Based on another post in the Spring Security forums I though I needed (and requested from corporate IT) a service account to connect to AD as and then perform my bind as a specific user to test for authentication. That request spawned a "talk to this guy who tells you to talk to another guy who tells you to talk to someone else..." email thread until finally I got to the right folks.

While I can't say for certain, if I was running the service on a Windows machine that is part of the domain (i.e., my laptop) I suspect I wouldn't have had any issues. But, we develop and run production on Linux - which is NOT part of the domain - it adds another layer of complexity.

The Spring Security 3 book by Peter Mularien has been somewhat helpful - and I suspect it will be more so as we implement this (we have to go through a security audit first before any development is done) - and mentioned we, at the very least, will need to generate a Kerberos keytab file to authenticate the web application to the AD domain controller.

I'm glad you've made it further though I'm surprised you'd get this particular error if you were trying to connect unsecured (IE - port 389) and AD wasn't configured to allow you to do so in the first place. I haven't attempted trying to communicate through a secure connection myself.

This was really the only post I'd found mentioning this specific problem (IncorrectResultSizeDataAccessException where the result was 0). Apparently you can get the same exception where the result size is greater than 1 (if multiple users have the same account name) but that clearly wasn't my problem with this brand new domain controller so I figured I'd share my experience.

Good luck!

Thanks, I appreciate it.

Although it's been a year since this thread was posted, I'm having the same problem with the current release of Spring Security (3.1.3-RELEASE). It only seems to occur when the Active Directory contains more than one user with the same 'givenName' and 'sn' (surename).

eg

userPrincipleName=fredsmith1, sAMAccountName=fredsmith1 givenName=Fred, sn=Smith

userPrincipleName=fredsmith2, sAMAccountName=fredsmith2 givenName=Fred, sn=Smith

Although you can work around this by using a different approach (see Peter Mularien's book) it does make the ActiveDirectoryLdapAuthenticationProvider class a bit limited.

Any updates on this anyone has would be appreciated.

We've still not yet implemented AD authentication. Corporate has been so SLOW in getting back to us about what we need that we now have to go through another security audit.

In the interim, we've stood up an LDAP server and I'm happy to report that's working just dandy.

I'll post more when I have something to add.