[389-users] Re: Update userpassword from consummer

[William Brown]

Okay. At this point I need to duplicate the configuration to diagnose the issue 
further, but I don’t have much time to do so.

An alternate, can you use a read only replica with referral’s enabled instead? 

> On 1 Mar 2019, at 00:13, wodel youchi  wrote:
> 
> Hi, 
> 
> I did a test using ldappasswd, and it didn't work, I didn't get any error 
> message from the CLI, and the $? variable returned 0, but the password has 
> not been changed. 
> After issuing the command I tried an ldapsearch with the Adam user using the 
> new-password and it didn't work "Invalid credentials", but using the old 
> password the ldapsearch worked.
> 
> 4) Modify userPassword from the slave using ldappasswd
> ldappasswd -D "uid=lnadmin,ou=special users,dc=example,dc=com" -W -p 389 -h 
> idm02.example.com -x -ZZ -S "uid=adam,ou=people,dc=example,dc=com"
> New password:
> Re-enter new password:
> Enter LDAP Password:
> 
> Result : echo $? returns 0 but the userPassword is not changed
> ldapsearch -h 127.0.0.1 -D "uid=adam,ou=people,dc=example,dc=com" -b 
> "ou=people,dc=example,dc=com" -x -w newpass
> ldap_bind: Invalid credentials (49)
> 
> Log from the slave :
> Access :
> [25/Feb/2019:15:08:09.356356670 +0100] conn=61 fd=67 slot=67 connection from 
> 192.168.40.102 to 192.168.40.102
> [25/Feb/2019:15:08:09.356588390 +0100] conn=61 op=0 EXT 
> oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
> [25/Feb/2019:15:08:09.356724270 +0100] conn=61 op=0 RESULT err=0 tag=120 
> nentries=0 etime=0.286023
> [25/Feb/2019:15:08:09.371819345 +0100] conn=61 TLS1.2 256-bit AES-GCM
> [25/Feb/2019:15:08:13.222914479 +0100] conn=61 op=2 BIND 
> dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3
> [25/Feb/2019:15:08:13.225541735 +0100] conn=61 op=2 RESULT err=0 tag=97 
> nentries=0 etime=0.0002835224 dn="uid=lnadmin,ou=special 
> users,dc=example,dc=com"
> [25/Feb/2019:15:08:13.225980566 +0100] conn=61 op=3 EXT 
> oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
> [25/Feb/2019:15:08:13.235729939 +0100] conn=61 op=3 RESULT err=0 tag=120 
> nentries=0 etime=0.0009925134
> [25/Feb/2019:15:08:13.236534952 +0100] conn=61 op=4 UNBIND
> [25/Feb/2019:15:08:13.236573244 +0100] conn=61 op=4 fd=67 closed - U1
> 
> Log from the master:
> Access :
> [25/Feb/2019:15:08:45.318668395 +0100] conn=31 fd=87 slot=87 SSL connection 
> from 192.168.40.102 to 192.168.40.101
> [25/Feb/2019:15:08:45.323871405 +0100] conn=31 TLS1.2 256-bit AES-GCM
> [25/Feb/2019:15:08:45.324437562 +0100] conn=31 op=0 BIND 
> dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3
> [25/Feb/2019:15:08:45.324636529 +0100] conn=31 op=0 RESULT err=0 tag=97 
> nentries=0 etime=0.0005924433 dn="uid=lnadmin,ou=special 
> users,dc=example,dc=com"
> 
> 
> Regards.
> 
> Le jeu. 28 févr. 2019 à 01:48, William Brown  a écrit :
> 
> 
> > 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

[389-users] Re: How to invalidate local cache after user changed their password

[William Brown]

> On 1 Mar 2019, at 01:15, xinhuan zheng  wrote:
> 
> Hello Mr. Brown,
> 
> Thanks for your input.
> 
> Here is my config after trim for public email:
> 
> [domain/MYLDAP]
> auth_provider = ldap
> cache_credentials = true
> 
> dns_resolver_timeout = 5
> entry_cache_timeout = 300

^ Turn this value down I think. The cache timeout only matters here when you 
are online, but it will keep using entries when you are “offline”. 

There is a similar memcache setting that I have in my config, which I also set 
to a low value to help with this issue too.

> enumerate = true
> id_provider = ldap
> ldap_id_use_start_tls = true
> 
> [domain/LOCAL]
> auth_provider = local
> enumerate = true
> id_provider = local
> 
> [nss]
> entry_cache_nowait_percentage = 75
> entry_cache_timeout = 300

^ Try turning this value down

> 
> reconnection_retries = 3
> 
> 
> [pam]
> debug_level = 5
> offline_credentials_expiration = 2

^ I think you probably don’t need this line, because when you do go offline it 
might cause you to fail to login.


Saying all this, it’s is one of the biggest challenges of SSSD that the config 
values are really hard to follow and “see” how they interact with the various 
tunings of the service which leads to problems like this :( 



> offline_failed_login_attempts = 3
> offline_failed_login_delay = 5
> reconnection_retries = 3
> 
> [sssd]
> config_file_version = 2
> debug_level = 5
> domains = LOCAL,MYLDAP
> reconnection_retries = 3
> sbus_timeout = 30
> services = nss,pam,ssh
> 
> 

—
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

[xinhuan zheng]

 Hello Mr. Brown,
Thanks for your input.
Here is my config after trim for public email:
[domain/MYLDAP]auth_provider = ldapcache_credentials = true
dns_resolver_timeout = 5entry_cache_timeout = 300enumerate = trueid_provider = 
ldapldap_id_use_start_tls = true
[domain/LOCAL]auth_provider = localenumerate = trueid_provider = local
[nss]entry_cache_nowait_percentage = 75entry_cache_timeout = 300
reconnection_retries = 3

[pam]debug_level = 5offline_credentials_expiration = 
2offline_failed_login_attempts = 3offline_failed_login_delay = 
5reconnection_retries = 3
[sssd]config_file_version = 2debug_level = 5domains = 
LOCAL,MYLDAPreconnection_retries = 3sbus_timeout = 30services = nss,pam,ssh
- Xinhuan
On Wednesday, February 27, 2019, 7:42:38 PM EST, William Brown 
 wrote:  
 
 

> 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 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

[wodel youchi]

Hi,

I did a test using ldappasswd, and it didn't work, I didn't get any error
message from the CLI, and the $? variable returned 0, but the password has
not been changed.
After issuing the command I tried an ldapsearch with the Adam user using
the new-password and it didn't work "Invalid credentials", but using the
old password the ldapsearch worked.

4) Modify userPassword from the slave using *ldappasswd*
*ldappasswd -D "uid=lnadmin,ou=special users,dc=example,dc=com" -W -p 389
-h idm02.example.com  -x -ZZ -S
"uid=adam,ou=people,dc=example,dc=com"*
New password:
Re-enter new password:
Enter LDAP Password:

Result : echo $? returns 0 but the userPassword is not changed
ldapsearch -h 127.0.0.1 -D "uid=adam,ou=people,dc=example,dc=com" -b
"ou=people,dc=example,dc=com" -x -w newpass
ldap_bind: Invalid credentials (49)

Log from the slave :
Access :
[25/Feb/2019:15:08:09.356356670 +0100] conn=61 fd=67 slot=67 connection
from 192.168.40.102 to 192.168.40.102
[25/Feb/2019:15:08:09.356588390 +0100] conn=61 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[25/Feb/2019:15:08:09.356724270 +0100] conn=61 op=0 RESULT err=0 tag=120
nentries=0 etime=0.286023
[25/Feb/2019:15:08:09.371819345 +0100] conn=61 TLS1.2 256-bit AES-GCM
[25/Feb/2019:15:08:13.222914479 +0100] conn=61 op=2 BIND
dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3
[25/Feb/2019:15:08:13.225541735 +0100] conn=61 op=2 RESULT err=0 tag=97
nentries=0 etime=0.0002835224 dn="uid=lnadmin,ou=special
users,dc=example,dc=com"
[25/Feb/2019:15:08:13.225980566 +0100] conn=61 op=3 EXT
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
[25/Feb/2019:15:08:13.235729939 +0100] conn=61 op=3 RESULT err=0 tag=120
nentries=0 etime=0.0009925134
[25/Feb/2019:15:08:13.236534952 +0100] conn=61 op=4 UNBIND
[25/Feb/2019:15:08:13.236573244 +0100] conn=61 op=4 fd=67 closed - U1

Log from the master:
Access :
[25/Feb/2019:15:08:45.318668395 +0100] conn=31 fd=87 slot=87 SSL connection
from 192.168.40.102 to 192.168.40.101
[25/Feb/2019:15:08:45.323871405 +0100] conn=31 TLS1.2 256-bit AES-GCM
[25/Feb/2019:15:08:45.324437562 +0100] conn=31 op=0 BIND
dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3
[25/Feb/2019:15:08:45.324636529 +0100] conn=31 op=0 RESULT err=0 tag=97
nentries=0 etime=0.0005924433 dn="uid=lnadmin,ou=special
users,dc=example,dc=com"


Regards.

Le jeu. 28 févr. 2019 à 01:48, William Brown  a écrit :

>
>
> > 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-hash