resetbytoken.php does not respect ppolicy openldap

[konvergence]

Hello ,

When testing the resetbytoken function, I found that the ppolicy was not respected. You can enter a password that already exists in the pwdHistory attribute.

I think this is because the page "resetbytoken.php" use an ldap connection with the admin account, while the "change.php" page use a connection with a "user" (if configured into the config)

How is it possible to do a resetbytoken while respecting ppolicy?

I thought to do it in 2 steps:

• the 1st step would be to do a resetpassword as the admin account to put a temporary password.
• the 2nd step would be from this logged in as user with this temporary password transmitted by mail, to change the password. This will allow to respect the ppolicy like is done in the "change.php" page.

But this make a big change. May be the is another way to do it ?

[plewin]

Hi, it is normal that the manager bypass the ppolicy.

In theory, sorry I never tried that yet I'm not 100%sure it will work, but if you create a service account with the correct ACL to read and modify user data you would not need any changes. SSP will use your service account instead of the manager / rootdn and the ppolicy will be enforced.

Alternatively, if only pwdHistory matters to you for a reset, it is possible to analyze it client side in SSP to refuse a password before sending it to the server. It's not implemented but two open PR currently have the primitives to do that.

Also, I really like your idea of a 2 steps reset, that's a possible solution but as you said it will require a lot of work.

On Fri, Aug 11, 2017, 2:04 PM konvergence notifications@github.com wrote:

Hello ,

When testing the resetbytoken function, I found that the ppolicy was not respected. You can enter a password that already exists in the pwdHistory attribute.

I think this is because the page "resetbytoken.php" use an ldap connection with the admin account, while the "change.php" page use a connection with a "user" (if configured into the config)

How is it possible to do a resetbytoken while respecting ppolicy?

I thought to do it in 2 steps:

• the 1st step would be to do a resetpassword as the admin account to put a temporary password.
• the 2nd step would be from this logged in as user with this temporary password transmitted by mail, to change the password. This will allow to respect the ppolicy like is done in the "change.php" page.

But this make a big change. May be the is another way to do it ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ltb-project/self-service-password/issues/135, or mute the thread https://github.com/notifications/unsubscribe-auth/AArKrZqw87-G2A8102zSfbrQrGdWHRBcks5sXENUgaJpZM4O0kkA .

[konvergence]

Thanks plewin,

I effectively find the PR #57 where the solution is to analyse in the SSP side the pwdHistory.

But this approach is limited to a specific LDAP and must implement the algorithm on the SSP side. So I will try the "service account", and keep you update ....

Knowing that this is not possible in MSAD, the 2-step reset approach is better and should works for any LDAP server.

On another subject : I'm surprised that SSP manage the hash encode for the password, on his side , knowing that OpenLDAP can force the hash on the server side.

For me, the password hash encoding must by managed on LDAP server side, and not by a client (SSP or another).

• With openldap, you must change the "olcPasswordHash" attribute configuration from "clear" to another value ("{CRYPT}" for example). Otherwise, you may see the clear password on an LDIF export. And we can not think that SSP is the only possible client for the LDAP server.
• With MSAD, you cannot read the password. So the risk is less

So in my opinion, SSP don't need to manage hash on his side, if Openldap handled hash in LDAP side. So you can simply send the password from SSP without hash, because OpenLDAP will hash it for you

But may be it not the case for ApacheDS ?

[konvergence]

Hi plewin,

Here my feedback about the fact to use a "service account" wiht correct ACL to manage users instead of the manager.

I did the tests on phpLDAPadmin and SSP

When I use a "service account" with correct ACL to read/modify a user, I get "ldap extended error" when the ppolicy is not respected. But only if the userPassword is send in "clear" (no hash in SSP side).

This confirm that is better to force the default hash on LDAP side, and not manage hash on SSP side.

[plewin]

Knowing that this is not possible in MSAD, the 2-step reset approach is better and should works for any LDAP server.

What is not possible ? using pwdHistory or creating a service account in MSDA ? For the later I believe it is possible to delegage permissions so an other service account can manage users passwords but I would like an AD expert to confirm this.

So in my opinion, SSP don't need to manage hash on his side, if Openldap handled hash in LDAP side. So you can simply send the password from SSP without hash, because OpenLDAP will hash it for you

SSP follows the protocol which is old and pretty low level. If the LDAP server has that optionnal extension that can automatically and transparently hash passwords, good for it. Administrators are free to use the configuration that works for them. Up to them to choose between hashing locally or delegate the hashing to the server.

Here my feedback about the fact to use a "service account" wiht correct ACL to manage users instead of the manager.

Thank you a lot for this. I think we can safely assume that is the best practice and that should be written somewhere in the documentation.

[coudot]

When I use a "service account" with correct ACL to read/modify a user, I get "ldap extended error" when the ppolicy is not respected. But only if the userPassword is send in "clear" (no hash in SSP side).

This is linked to the configuration of ppolicy. Check the pwdCheckQuality attribute and see in slapo-ppolicy manpage how to configure it.

Anyway, you are right on the fact that if you have password policy on LDAP side, you must not HASH the password on SSP side. As @plewin said, it is just a configuration in SSP.

Password hashing in SSP is an interesting feature for LDAP directories that can't do hashing on the fly.

[plewin]

I am closing this issue because OP's problem has been solved.