John A. Sullivan III wrote:
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.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: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.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.<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 - JohnOops! 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
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
