Our organization’s security policies impose several constraints on password changes. There is a complexity requirement, and a ban on reuse of old passwords. I’ve gotten all of these requirements worked into the 389 server, but when the constraints aren’t met, the error message is very misleading and opaque:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
This results in a lot of support requests about the inability to change passwords. Is there any way to make the error messages a little more descriptive? We’re using pam_sss and sssd on Centos 7.x.
I am looking to cfg nsIdleTimeout attribute for a specific DS user, I tryed using 389-console and ldapmodify but I not successful, in 389-console this attribute is in grey when trying to add a value will not allowed , with ldapmodify nothing happened no prompt or error given back but ldapsearch will not display the attribute, what I am missing ?
I have a current 389 deployment that I need to duplicate to a new set of servers to be used at a different facility on a different network. I'm thinking that I could either do an import or use replication. My plan is to use replication to replicate the data to the new set of servers. That way they'll stay in sync until I move them. Is this a good method to use and are there any possible issues with this method?
I am a LDAP newbie and running into a problem with a simple LDAP supplier - consumer scenario. The topology is as follows:
One 389 DS instance is set up as a read-only replica, the second one as read-write supplier. The replication agreement is in place and any LDAP modifications to the consumer are getting the proper referral to the supplier. The modifications (immediate) are also properly replicated back to the consumer.
Question: If I issue a delete operation to a read-only replica, and the delete request ist properly resend to the actual supplier, can I expect (?) that an immediate read to the consumer does not find the deleted object? Or do I have to wait until the supplier initiated replication (immediate) has taken place?
The current behavior his that I still can read back the "deleted" object from the read-only replica until the replication is over. Is that correct behavior? Or can I 'tweak' things that even on a read-only replica a deleted object is immediately not available, even before replication starts.
Thanks in advance,