#48876 Design: extensible password management
Opened 4 years ago by firstyear. Modified 2 years ago

In the past, LDAP as the single source of truth was okay for passwords. Everything bound only to LDAP, and we only needed the one hash.

But in the modern world, this is not the case. We have to have passwords in secure hash formats, passwords in alternate formats (consider NTHash for Radius), or even passwords to alter and set kerberos principal data.

We also have businesses that want more policies, and quality checks on passwords.

Our current framework is limited, and has led to the IPA team rolling their own plugin, and password policy management plugin. We can't provide many of these functions from these plugins (Even though we want to!) because they are external to how DS functions.

We also receive many requests about addition of different password quality checking mechanisms. We just can't satisfy them.

As a team, we should investigate how we can re-work our password handling to be:

  • correct and secure
  • clearer and easier to debug
  • extensible and able to cope with the needs of users and IPA
  • backwards compatabile to existing installs

Here is my rough draft, but needs work and comment (and a design document)

We would re-write the password handling to have three stages.

First is a PLUGIN_PASSWORD_POLICY_CHECK_FN, which plugins could register. This returns a LDAP_SUCCESS / anything else. Given the target DN only, this would be to determine if the user can change the password of the target DN, or anything else needed. There could be many stacked policy checks here.

Second is the PLUGIN_PASSWORD_RESTRICTION_CHECK_FN, which again, could be registered. This would be a set of LDAP_SUCCESS / anything checks that given the target DN, and now the password cleartext material, and assesment is made of the password qulatiy and whether the change can proceed. There can be many checks, and they would all have to pass to allow the change. These could be derived from the password policy, so they may be finegrained / subtree policy that could apply for example, or scoping of the checks .... (It's still an idea in my mind, so this will improve.)

Third and finally is a set of PLUGIN_PASSWORD_STORE_FN, which take the cleartext material and write the cleartext through a hash to an attribute. There could be many of these in operation. The benefit to this is we could enable an object to write say:

  • userPassword: SSHA512
  • smbNtHash: NTHash
  • krbPrincipalSecret: The kerberos secret based on the password ...

Then the operation is complete.

Another recommendation:

During a bind we should be able to consult multiple password / security modules. This will allow modular MFA or different types of authentication, one time passwords etc.

A hook such as PLUGIN_PASSWORD_BIND_CHECK_FN. The object binding could have a flag to dictate OR or AND behaviour of the plugins associated with the account.

For example, you could then have a PLUGIN_PASSWORD_BIND_CHECK_FN for OTP which takes the last X chars from the password and accepts / rejects the bind. Then the next module is called with the remaining, which is hashed and compared to userPassword.

Another hook would be that if the current password hash type != passwordStorageScheme on bind, given we have the clear text password we could do an optional upgrade of the stored hash to the new scheme on bind.

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone: 1.3.6 backlog

3 years ago

Metadata Update from @firstyear:
- Issue close_status updated to: None

3 years ago

Metadata Update from @firstyear:
- Issue set to the milestone: 1.4 backlog (was: 1.3.6 backlog)

3 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue tagged with: RFE

2 years ago

Login to comment on this ticket.