John A. Sullivan III wrote: > On Mon, 2009-04-27 at 21:17 -0400, John A. Sullivan III wrote: > >> On Mon, 2009-04-27 at 19:07 -0600, Rich Megginson wrote: >> >>> John A. Sullivan III wrote: >>> >>>> Hello, all. This is a sequel to the last email on this subject now that >>>> we've resolved the shadowLastChange problem. Fixing that problem did >>>> not fix the DS 8.0 / AD password synchronization problem. To reiterate, >>>> the passwords synchronize if the change is made from idm-console or from >>>> AD. But they do not change when our Ubuntu/KDE users change their own >>>> passwords. It fails when changed from both the KDE password change >>>> interface and using passwd at the command line. >>>> >>>> >>> Take a look at the directory server access log - I think the change is >>> being rejected before it even gets into the replication code, which is >>> why the error log output below is not too helpful. >>> >> <snip> >> Ah, I forgot to mention that the password change is successful in DS. >> It just doesn't synchronize. Would that be the case if there was an >> access failure? I'll enable the access logs and give it a check - John >> > Oops! I forgot to mention that we had enabled the access logs and > followed them in case the change was being made by some ID other than > the user but the access logs look fine as far as we can tell. Here is > what we see: > > [27/Apr/2009:21:43:50 -0400] conn=359 fd=66 slot=66 connection from 172.29.32.12 to 172.30.10.48 > [27/Apr/2009:21:43:50 -0400] conn=359 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [27/Apr/2009:21:43:50 -0400] conn=359 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [27/Apr/2009:21:43:50 -0400] conn=359 SSL 256-bit AES > [27/Apr/2009:21:43:50 -0400] conn=359 op=1 BIND dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" method=128 version=3 > [27/Apr/2009:21:43:50 -0400] conn=359 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=b > [27/Apr/2009:21:43:50 -0400] conn=359 op=2 MOD dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" > [27/Apr/2009:21:43:50 -0400] conn=359 op=2 RESULT err=0 tag=103 nentries=0 etime=0 csn=49f65f56000000010000 > [27/Apr/2009:21:43:50 -0400] conn=359 op=3 UNBIND > [27/Apr/2009:21:43:50 -0400] conn=359 op=3 fd=66 closed - U1 > [27/Apr/2009:21:43:51 -0400] conn=360 fd=66 slot=66 connection from 172.29.32.12 to 172.30.10.48 > [27/Apr/2009:21:43:51 -0400] conn=360 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [27/Apr/2009:21:43:51 -0400] conn=360 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [27/Apr/2009:21:43:51 -0400] conn=360 SSL 256-bit AES > [27/Apr/2009:21:43:51 -0400] conn=360 op=1 BIND dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" method=128 version=3 > [27/Apr/2009:21:43:51 -0400] conn=360 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=b > [27/Apr/2009:21:43:51 -0400] conn=360 op=2 MOD dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" > [27/Apr/2009:21:43:51 -0400] conn=360 op=2 RESULT err=0 tag=103 nentries=0 etime=0 csn=49f65f57000000010000 > [27/Apr/2009:21:43:51 -0400] conn=360 op=3 UNBIND > [27/Apr/2009:21:43:51 -0400] conn=360 op=3 fd=66 closed - U1 > > I'm assuming this shows success and an entry into the Change log. Is > that correct? If so, where do we look next to solve this problem? Thanks > - John > I suppose you could try to enable the audit log - see what attribute it is modifying, and what value. nss_ldap/pam_ldap (e.g. the interface that the passwd command uses) can be configured to store a pre-hashed password which will not work with winsync. You must have the clear text password in order to sync it to AD. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090428/aec28e77/attachment.bin