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)?

Consider creating filter using `Filter filter = Filter.createEqualityFilter("samAccountName",userName);` — Terry Gardner, Jun 27 '13 at 11:21

score 2 · Answer 1 · answered Jun 27 '13 at 10:41

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.

answered Jun 27 '13 at 10:41

user207421

305,947
44
307
483

Should I reconnect using bindUserDN before any LDAP operation (or at least after the authentication)? – Michael Jun 27 '13 at 10:44
2

The connection remains in the authorization state after the BIND until another BIND request is received or the connection is closed, or the server times out the connection, or the StartTLS state is changed. Requests are processed by the server based on the authorization state of the connection. If you must keep the authorization state of the connection but execute operations as another user, the client must use either proxied auth v1 or proxies auth v2. – Terry Gardner Jun 27 '13 at 11:09

score 2 · Answer 2 · answered Jun 27 '13 at 16:55

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.

Thanks for the detailed answer (+1), but @Terry Gardner first answered the question. — Michael, Jun 30 '13 at 06:33

score 1 · Accepted Answer · answered Jun 27 '13 at 11:06

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.

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

4 Answers4

see also