How to preserve LDAP bind user connection after a user authentication?

Question

I have started to use UnboundID to implement the authentication against LDAP. I implemented the authentication as following:

Connect to LDAP

ldapConnection = new LDAPConnection(host, port, bindUserDN, bindUserPassword);

Search user DN:

Filter.create("(sAMAccountName=" + userName + ")");
SearchRequest searchRequest =
new SearchRequest(baseDN, SearchScope.SUB, 
        DereferencePolicy.NEVER, 0, 0, false, filter,
        attributesToReturn);
SearchResult searchResult = ldapConnection.search(searchRequest);`

Bind a user

SimpleBindRequest bindRequest = new SimpleBindRequest(searchResultEntry.getDN(), userPassword);
BindResult bindResult = ldapConnection.bind(bindRequest); 

Unfortunately, after the last bind using a user DN and a user password ldapConnection is changed to the user DN (and not the bind User DN). I checked it using ldapConnection.getLastBindRequest(). Therefore, I can not use it for father entries retrieval (e.g. group retrieval) since the user does not have an appropriate permission.

Is it expected behavior that ldapConnection changes a user? How to preserve LDAP bind user connection after a user authentication? Should I reconnect using bindUserDN before any LDAP operation (or at least after the authentication)?

Answer 1

LDAP clients use the BIND request to change the authentication state of the connection. When a BIND request is received, an LDAP-compliant server must immediately set the authorization state of the connection to "unauthenticated". If the request is successful, the server sets the authorization state of the connection to the state associated with the distinguished name in the BIND request.

see also

• LDAP: Authentication Best Practices

Answer 2

It is expected that when you bind as a new user you are bound as that user.

I don't know what else you could possibly expect.

Answer 3

Changing the identity of a connection is one of primary effects of an LDAP bind operation. Although some servers may provide a way to authenticate a user over a connection without changing the identity of that connection (e.g., the UnboundID Directory Server provides support for a special control that can accomplish this), I don't believe that Active Directory offers anything like that.

If the server you're using doesn't provide any mechanism to bind without changing the identity of the connection, then you really only have two options for preventing a bind from permanently changing the identity of a connection:

• Use a separate connection for the bind so that it doesn't affect the connection you want to continue using for other purposes.

• After performing a bind to verify a user's credentials, perform a second bind to change the identity of a connection back to what it was before the first bind.

Many applications that interact with LDAP directory servers on behalf of end users employ connection pools with connections that can be re-used by multiple users rather than creating a separate connection for handling each user. If you're using connection pooling in your application, then the UnboundID LDAP SDK for Java does provide some capabilities to help you eliminate the effect that performing a bind has on the identity of the connection. The LDAPConnectionPool.bindAndRevertAuthentication method allows you to perform a bind to verify a user's credentials, and then it will automatically re-bind as the original user for that connection. Similarly, if you have checked out a connection from the pool, you can use the LDAPConnectionPool.releaseAndReAuthenticateConnection method to return the connection back to the pool and have it automatically re-bound as the original user.

If you're not using a connection pool but instead want to stick with individual connections, then I would simply recommend performing a second bind after the first one to revert the authentication state back to the previous identity.

Answer 4

It appears that you are operating a service where you need to locate the user and then let the user "Authenticate"

Since you are using the UnboundID SDK, I would use one of their fine LDAPConnectionPool objects and use separate LDAPConnections for the "Service" LDAPConnection and the user "Authentication" LDAPConnection.

-jim