Hello,
I enabled password complexity constraints, password history and password expiration (1 days min, 70 days max).
When I use the command passwd to change a user's password, I get the error message:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
In the following cases:
Password was changed less than a days ago
Password does not match complexity constraints
Password is already in history
My question: would it be possible to give better information to the user ? To let him know that his password is not matching constraints, already in history or changed recently ?
I realize that some of this is related to sssd/pam, but I'd like to know if 389 server is at least able to tell this to sssd/pam.
Thanks,
Nicolas Martin
Directory Server has its own internal password policy that it manages itself. It does not communicate with other services. 389's password policy does say why it rejects passwords. But in IPA deployments IPA also has its own unique password policy plugin, and it does NOT use 389's password policy.
On 6/19/20 5:10 AM, Nicolas Martin wrote:
Hello,
I enabled password complexity constraints, password history and password expiration (1 days min, 70 days max).
When I use the command passwd to change a user's password, I get the error message:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
This is not how 389 responds to invalid passwords, so this must be how sssd/ipa responds to invalid passwords.
In the following cases:
Password was changed less than a days ago
Password does not match complexity constraints
Password is already in history
My question: would it be possible to give better information to the user ? To let him know that his password is not matching constraints, already in history or changed recently ?
I realize that some of this is related to sssd/pam, but I'd like to know if 389 server is at least able to tell this to sssd/pam.
Like I said sssd/pam do not use 389's password policies, so I would ask this question on freeipa-users@lists.fedorahosted.org
HTH,
Mark
Thanks,
Nicolas Martin
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 19 Jun 2020, at 23:15, Mark Reynolds mreynolds@redhat.com wrote:
Directory Server has its own internal password policy that it manages itself. It does not communicate with other services. 389's password policy does say why it rejects passwords. But in IPA deployments IPA also has its own unique password policy plugin, and it does NOT use 389's password policy.
To follow up what Mark said, can you confirm if this is 389 ds on it's own, or a FreeIPA installation?
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
I have installed 389 server on its own; I'm not using FreeIPA.
On Mon, Jun 22, 2020 at 4:26 PM William Brown wbrown@suse.de wrote:
On 19 Jun 2020, at 23:15, Mark Reynolds mreynolds@redhat.com wrote:
Directory Server has its own internal password policy that it manages
itself. It does not communicate with other services. 389's password policy does say why it rejects passwords. But in IPA deployments IPA also has its own unique password policy plugin, and it does NOT use 389's password policy.
To follow up what Mark said, can you confirm if this is 389 ds on it's own, or a FreeIPA installation?
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
I wonder if there is some sssd configuration issue going on? Honestly I'm not very experienced with this part of the code base and these interactions ...
On 23 Jun 2020, at 18:19, Nicolas Martin nico.martin@gmail.com wrote:
I have installed 389 server on its own; I'm not using FreeIPA.
On Mon, Jun 22, 2020 at 4:26 PM William Brown wbrown@suse.de wrote:
On 19 Jun 2020, at 23:15, Mark Reynolds mreynolds@redhat.com wrote:
Directory Server has its own internal password policy that it manages itself. It does not communicate with other services. 389's password policy does say why it rejects passwords. But in IPA deployments IPA also has its own unique password policy plugin, and it does NOT use 389's password policy.
To follow up what Mark said, can you confirm if this is 389 ds on it's own, or a FreeIPA installation?
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org