[389-users] Re: Update userpassword from consummer
> On 27 Feb 2019, at 19:25, wodel youchi wrote:
>
> Hi,
>
> What do you mean by : enable password-migration mode? can you elaborate,
> where do I have to enable it? on the master on the slave?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-allow-hashed-passwords
This is the setting I am referring to.
>
> In my previous post I did test changing the password using both clear an
> pre-hashed password, and it didn't work.
>
> 2) Modify userPassword from the slave using clear text password
> ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special
> users,dc=example,dc=com" -w pass -x < dn: uid=adam,ou=people,dc=example,dc=com
> changetype: modify
> replace: userPassword
> userPassword: password
> EOF
> modifying entry "uid=adam,ou=people,dc=example,dc=com"
> ldap_modify: Constraint violation (19)
> additional info: database configuration error - please contact the
> system administrator
>
>
> 3) Modify userPassword from the slave using encrypted password
> ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special
> users,dc=example,dc=com" -w wolverine -x < dn: uid=adam,ou=people,dc=example,dc=com
> changetype: modify
> replace: userPassword
> userPassword: {SSHA}gvg6KehxZNYcLnLrAJrI0TzWpQzXH0oe
> EOF
> modifying entry "uid=adam,ou=people,dc=example,dc=com"
> ldap_modify: Constraint violation (19)
> additional info: invalid password syntax - passwords with storage
> scheme are not allowed
>
Passwords have some special handling. Does a ldappasswd extended operation on
the replica work?
>
> Regards.
>
> Le mer. 27 févr. 2019 à 00:44, William Brown a écrit :
>
>
> > On 26 Feb 2019, at 00:23, wodel youchi wrote:
> >
> > 3) Modify userPassword from the slave using encrypted password
> > ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special
> > users,dc=example,dc=com" -w wolverine -x < > dn: uid=adam,ou=people,dc=example,dc=com
> > changetype: modify
> > replace: userPassword
> > userPassword: {SSHA}gvg6KehxZNYcLnLrAJrI0TzWpQzXH0oe
> > EOF
> > modifying entry "uid=adam,ou=people,dc=example,dc=com"
> > ldap_modify: Constraint violation (19)
> > additional info: invalid password syntax - passwords with storage
> > scheme are not allowed
>
>
> IIRC you aren’t able to set a password into the field that is pre-hashed. You
> either need to enable password-migration mode, or you should supply the
> plaintext password and the server hashes it for you. Does that fix the issue?
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
>
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: How to invalidate local cache after user changed their password
> On 28 Feb 2019, at 05:22, xinhuan zheng wrote: > > Hello, > > I have been struggling with this problem for a while. When a user changed > their password, our 389 directory servers received new password and saved > into directory server. However, when user tries to login to a server whose > authentication is using 389 directory server, their new password won't work > for the first few minutes. There is a local cache process, sssd, running on > the server the user tries to login. Apparently sssd is still using old > password information, and does not know password has changed on directory > servers. I have set sssd to keep cache information for 5 minutes only, and do > pre-fetch prior to cache information expiring. But I don't know how to tell > sssd to ignore cache completely when information has changed on 389 directory > server side. > > Is there a way to completely disable sssd local cache, and only use it when > 389 directory servers are not available? I’ve never seen SSSD behave like this - but I would also believe it to be true. My SSSD configuration has an extremely low cache timeout for avoiding this issue. [domain/blackhats.net.au] ignore_group_members = False entry_cache_group_timeout = 60 cache_credentials = True id_provider = ldap auth_provider = ldap access_provider = ldap chpass_provider = ldap ldap_referrals = False ldap_access_order = filter, expire [nss] memcache_timeout = 60 I’ve trimmed the config (obviously) for email. Can you provide your SSSD config to me to examine to see if I can spot any issues? > > Thank you, > > - Xinhuan > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: Referential Integrity and moving subtree to another parent fails
> On 27 Feb 2019, at 23:41, Alberto Viana wrote: > > I'm facing a very similar problem, my version: > 389-Directory/1.3.7.4.20170912git26a9426 > > So, it's probably you right, maybe It's a 1.3.x problem. It’s still a problem though. I just don’t have the setup to build/test 1.3.x anymore. Maybe Mark can help out here, I think he probably has a 1.3.x build around? The refint modrdn test case was merged in pagure, so maybe we could backport to 1.3.x and test? > > In my case, I disabled the plugin until I can upgrade my 389 version. > > On Fri, Feb 22, 2019 at 1:07 AM William Brown wrote: > Okay, I did this with a MMR of two masters, enabled memberOf and did a loop > of 20x, and still can’t reproduce this. :( > > Perhaps it’s a solved problem in 1.4.x, but exists in 1.3.x? > > > On 22 Feb 2019, at 10:18, William Brown wrote: > > > > Okay, I will enable memberOf in the test and try again. Thanks! > > > >> On 21 Feb 2019, at 23:28, Olivier JUDITH wrote: > >> > >> Hi , > >> > >> After several tests (disable replication /memeberof plugin activated on > >> member and uniquemember attributes) , the problem is not bound to the > >> number of entries . I encounter the same behavior when moving only one > >> account . the problem occurs when an entry is attached to a group (has > >> memberOf attribute). > >> ___ > >> 389-users mailing list -- 389-users@lists.fedoraproject.org > >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > ___ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] How to invalidate local cache after user changed their password
Hello, I have been struggling with this problem for a while. When a user changed their password, our 389 directory servers received new password and saved into directory server. However, when user tries to login to a server whose authentication is using 389 directory server, their new password won't work for the first few minutes. There is a local cache process, sssd, running on the server the user tries to login. Apparently sssd is still using old password information, and does not know password has changed on directory servers. I have set sssd to keep cache information for 5 minutes only, and do pre-fetch prior to cache information expiring. But I don't know how to tell sssd to ignore cache completely when information has changed on 389 directory server side. Is there a way to completely disable sssd local cache, and only use it when 389 directory servers are not available? Thank you, - Xinhuan___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: Referential Integrity and moving subtree to another parent fails
I'm facing a very similar problem, my version: 389-Directory/1.3.7.4.20170912git26a9426 So, it's probably you right, maybe It's a 1.3.x problem. In my case, I disabled the plugin until I can upgrade my 389 version. On Fri, Feb 22, 2019 at 1:07 AM William Brown wrote: > Okay, I did this with a MMR of two masters, enabled memberOf and did a > loop of 20x, and still can’t reproduce this. :( > > Perhaps it’s a solved problem in 1.4.x, but exists in 1.3.x? > > > On 22 Feb 2019, at 10:18, William Brown wrote: > > > > Okay, I will enable memberOf in the test and try again. Thanks! > > > >> On 21 Feb 2019, at 23:28, Olivier JUDITH wrote: > >> > >> Hi , > >> > >> After several tests (disable replication /memeberof plugin activated on > member and uniquemember attributes) , the problem is not bound to the > number of entries . I encounter the same behavior when moving only one > account . the problem occurs when an entry is attached to a group (has > memberOf attribute). > >> ___ > >> 389-users mailing list -- 389-users@lists.fedoraproject.org > >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > ___ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: Update userpassword from consummer
Hi,
What do you mean by : enable password-migration mode? can you elaborate,
where do I have to enable it? on the master on the slave?
In my previous post I did test changing the password using both clear an
pre-hashed password, and it didn't work.
2) Modify userPassword from the slave using* clear text password*
ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special
users,dc=example,dc=com" -w pass -x < a écrit :
>
>
> > On 26 Feb 2019, at 00:23, wodel youchi wrote:
> >
> > 3) Modify userPassword from the slave using encrypted password
> > ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special
> users,dc=example,dc=com" -w wolverine -x < > dn: uid=adam,ou=people,dc=example,dc=com
> > changetype: modify
> > replace: userPassword
> > userPassword: {SSHA}gvg6KehxZNYcLnLrAJrI0TzWpQzXH0oe
> > EOF
> > modifying entry "uid=adam,ou=people,dc=example,dc=com"
> > ldap_modify: Constraint violation (19)
> > additional info: invalid password syntax - passwords with
> storage scheme are not allowed
>
>
> IIRC you aren’t able to set a password into the field that is pre-hashed.
> You either need to enable password-migration mode, or you should supply the
> plaintext password and the server hashes it for you. Does that fix the
> issue?
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
