Attribute pwdReset about ldapsdk

[dirmgr]

This isn’t a question about or for the LDAP SDK. Rather, it is specific to the directory server that you’re using, and the best way to get an answer is to ask the people who make that directory server.

I can only provide an authoritative answer for the Ping Identity (formerly UnboundID) Directory Server, and the answer for that server is no, you cannot directly alter the value of the pwdReset attribute. That attribute type is defined with the NO-USER-MODIFICATION constraint and is intended to be maintained by the Directory Server itself. However, a properly authorized client can use either the manage-account command-line tool or the password policy state extended operation to manage many password policy state attributes for a user, including whether that user will be required to change their password the next time they authenticate.

If you’re using a different directory server, then you should use the appropriate support channel for that server to determine how to accomplish this in that server.

[clairton]

So, I am using a InMemoryDirectoryServer of unboundid for tests in a Junit rule, and I don't know how to do this. My code

InMemoryDirectoryServerConfig c = new InMemoryDirectoryServerConfig(new DN(config.base().dn()));
    c.setListenerConfigs(listenerConfig);
    c.addAdditionalBindCredentials(config.bindDn(), config.password());
    server = new InMemoryDirectoryServer(c);
    try {
      server.startListening();
      return server;
    }

[dirmgr]

The in-memory directory server doesn’t currently provide any level of password policy support. It aims to be a standards-compliant server that doesn’t favor any particular vendor implementation, and password policy support is something that varies wildly from one server to another, both in terms of what features they support and how that support is implemented.

Although we could consider making password policy support pluggable so that we could offer different implementations (along with other vendor-specific features like access control), it would be a lot of effort and is not currently on the roadmap.

[clairton]

Thanks @dirmgr

[jameskleeh]

@dirmgr Can you point me in the right direction for how I might implement a simple account lockout for a hardcoded user using the in memory ldap? I just need to verify my LDAP authentication mechanism responds correctly.

[dirmgr]

There are a few key things that you need to do, which you can probably do them in a single InMemoryOperationInterceptor. They are:

• You need to detect requests that change a password (for example, a modify request that targets the userPassword attribute or a password modify extended request). Determine whether the request is a self change (the user is changing their own password) or an administrative reset (the password is being changed by someone else). If it’s a self change, then you’ll want to remove the pwdReset attribute if it’s there. If it’s an administrative reset, then you’ll want to make sure the pwdReset attribute gets set in the entry.

• For bind requests that target an entry that has the pwdReset attribute, you need to indicate to the client that the account is in a “must change password” state (and the way that happens varies based on the type of server that you’re using; for example, it might be a password expired control in a successful response), and you need to set a flag somewhere (probably in the connection state) that will be able to remember that state for subsequent requests.

• For all other requests on an authenticated connection, if the account is in a “must change” state, you should reject it with an indication that the user needs to change their password before other operations will be allowed.

[jameskleeh]

@dirmgr I appreciate the response! I'll look into it