The version of 389-ds-base is 1.3.7.5-24.

The below snippet appears to be the full sequence from the access log on my 
LDAP server. I have a Linux client using SSSD to bind to the directory 
(account: mybindacct). I SSH into my client as johndoe and change my password 
with the usual passwd command.

[15/Oct/2018:09:26:11.609685215 -0400] conn=206895 TLS1.2 256-bit AES-GCM
[15/Oct/2018:09:26:11.612881217 -0400] conn=206895 op=0 SRCH base="" scope=0 
filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl 
supportedExtension supportedFeatures supportedLDAPVersion 
supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext 
lastusn highestcommittedusn aci"
[15/Oct/2018:09:26:11.613707013 -0400] conn=206895 op=0 RESULT err=0 tag=101 
nentries=1 etime=0.0011199684
[15/Oct/2018:09:26:11.615468995 -0400] conn=206895 op=1 BIND 
dn="uid=mybindacct,ou=Special Users,dc=example,dc=org" method=128 version=3
[15/Oct/2018:09:26:11.615687824 -0400] conn=206895 op=1 RESULT err=0 tag=97 
nentries=0 etime=0.0000260954 dn="uid=mybindacct,ou=special 
users,dc=example,dc=org"
[15/Oct/2018:09:26:11.616003685 -0400] conn=206895 op=2 BIND 
dn="uid=johndoe,ou=Test,ou=People,dc=example,dc=org" method=128 version=3
[15/Oct/2018:09:26:11.616327955 -0400] conn=206895 op=2 RESULT err=0 tag=97 
nentries=0 etime=0.0000365138 
dn="uid=johndoe,ou=test,ou=people,dc=example,dc=org"
[15/Oct/2018:09:26:11.624910413 -0400] conn=206895 op=3 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin"
[15/Oct/2018:09:26:11.627984160 -0400] conn=206895 op=3 RESULT err=0 tag=120 
nentries=0 etime=0.0003117005
[15/Oct/2018:09:26:11.630152739 -0400] conn=206895 op=4 UNBIND

One question is which account is actually doing the attribute change: is it my 
SSSD bind account the one updating the johndoe password attribute on behalf of 
the johndoe user?

Thanks,
Nick


From: Mark Reynolds <mreyno...@redhat.com>
Sent: Friday, October 12, 2018 12:32 PM
To: General discussion list for the 389 Directory server project. 
<389-users@lists.fedoraproject.org>; Nick W. Harrison 
<nwharri...@northcarolina.edu>
Subject: Re: [389-users] Password policy not working


That is the wrong package "389-ds", what is the version of "389-ds-base"?

Can you share what is in the server's access log when the password is changed 
(/var/log/dirsrv/slapd-YOUR_INSTACE/access)?  There should be a few operations 
that occur during the password change so please make sure to provide a full 
clip from the log.

Thanks,

Mark


On 10/12/18 12:05 PM, Nick W. Harrison wrote:
Hello -

I have a password policy on the OU that contains all of my user accounts. This 
password policy is set on the subtree and the "user may change password" option 
is deselected. However, I'm still able to change my password if I use passwd on 
a LDAP client.

I'm running an older version of 389-ds...v.1.2.2-6...and am wondering if there 
is anything additional I need to put in place to prevent users from changing 
their passwords. My accounts and passwords are replicated over from AD with a 
unidirectional relationship, and the clients are doing simple binds.

Thanks for any thoughts.



_______________________________________________

389-users mailing list -- 
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>

To unsubscribe send an email to 
389-users-le...@lists.fedoraproject.org<mailto: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

Reply via email to