Hello,
I am trying to build a form where a user enters a new password. The password should be checked "live" against the AD password policy, but will be set at a later point.
I couldn't find a way to just get password policy info and validate a password against them, without sending some form of modify request. I just want some true/false info if the password matches the policy.
Is there some way to do that? Or is this just not possible through the UnboundID SDK or Active Directory?
Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is something that would require some level of server-side support, and I don’t believe that Active Directory offers anything like that. Examples of the kinds of server-side support that would help in doing this include:
The ability to determine what requirements a proposed password is expected to satisfy so that you can programmatically evaluate them (at least, to the extent possible; for example, there may be something like a server-side password history or a dictionary of forbidden passwords that the client wouldn’t have access to). In the Ping Identity Directory Server, we provide support for a “get password quality requirements” extended request that you can use to retrieve requirements in both a human-readable and machine-parsable format, but that’s a proprietary operation that we’ve developed and I don’t believe that Active Directory offers anything like that.
The ability to submit a password to the server for evaluation without actually changing the password. In the Ping Identity Directory Server, we support the LDAP no-operation control that allows you attempt to attempt a write operation and have the server reject it if it would have failed for some reason, but won’t actually apply the change if it would have succeeded. We also offer a password validation details request control that you can include in an attempt to change a password (with or without the LDAP no-operation control) to indicate that the server should return information about the individual requirements that passwords are required to satisfy and whether the proposed password satisfied each requirement. I don’t believe that Active Directory offers anything like either of these, either.
One thing that the LDAP SDK could potentially offer is some degree of client-side support for password validation if you have some way of knowing what the requirements are. For example, it could provide a length validator, and if you know that passwords will need to satisfy certain length requirements, you could use that length validator to determine whether a proposed password satisfies the expected requirement. As noted above, you can’t necessarily perform all of the same validation on the client that the server might attempt, but you may be able to at least perform as much validation as possible and weed out known-weak passwords before attempting to send them to the server. This isn’t something that the LDAP SDK currently offers, but it is something that I could consider offering.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am trying to build a form where a user enters a new password. The password should be checked "live" against the AD password policy, but will be set at a later point.
I couldn't find a way to just get password policy info and validate a password against them, without sending some form of modify request. I just want some true/false info if the password matches the policy.
Is there some way to do that? Or is this just not possible through the UnboundID SDK or Active Directory?
Thanks in advance!
This is something that would require some level of server-side support, and I don’t believe that Active Directory offers anything like that. Examples of the kinds of server-side support that would help in doing this include:
The ability to determine what requirements a proposed password is expected to satisfy so that you can programmatically evaluate them (at least, to the extent possible; for example, there may be something like a server-side password history or a dictionary of forbidden passwords that the client wouldn’t have access to). In the Ping Identity Directory Server, we provide support for a “get password quality requirements” extended request that you can use to retrieve requirements in both a human-readable and machine-parsable format, but that’s a proprietary operation that we’ve developed and I don’t believe that Active Directory offers anything like that.
The ability to submit a password to the server for evaluation without actually changing the password. In the Ping Identity Directory Server, we support the LDAP no-operation control that allows you attempt to attempt a write operation and have the server reject it if it would have failed for some reason, but won’t actually apply the change if it would have succeeded. We also offer a password validation details request control that you can include in an attempt to change a password (with or without the LDAP no-operation control) to indicate that the server should return information about the individual requirements that passwords are required to satisfy and whether the proposed password satisfied each requirement. I don’t believe that Active Directory offers anything like either of these, either.
One thing that the LDAP SDK could potentially offer is some degree of client-side support for password validation if you have some way of knowing what the requirements are. For example, it could provide a length validator, and if you know that passwords will need to satisfy certain length requirements, you could use that length validator to determine whether a proposed password satisfies the expected requirement. As noted above, you can’t necessarily perform all of the same validation on the client that the server might attempt, but you may be able to at least perform as much validation as possible and weed out known-weak passwords before attempting to send them to the server. This isn’t something that the LDAP SDK currently offers, but it is something that I could consider offering.