Anne Cross wrote: > Rich Megginson wrote: >> Anne Cross wrote: >>> I'm trying to sync passwords from 389 to Active Directory. >>> >>> If we import users from AD, then try to change their passwords, the >>> replication locks up. >> Can you be more specific? Have you tried the replication log level >> (which also logs winsync data) - >> http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > I turned on replication logging through the GUI, which set it to 8192, > much as the ldapmodify would have. > > What we see on the AD side is that the replication manager says, > effectively, "Change the password," and then it *appears* that the > replication manager account attempts to change users to the become to > the user whose password is being changed; then, the software attempts > to change the password, which fails. the bad password attempt counter > increments, and the replication manager account appears to log out. > > On the Directory Server side, we see everything connect, the user is > resolved on both sides, and then after about 15 minutes, the > connection disconnects due to idleness. > > This is the log of the user add using a cleartext password on the ldap > side: > > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Looking > at add operation local > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > (ours,user,not group) > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking > for AD entry for DS > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > guid="(null)" > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking > for AD entry for DS > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > username="juniper" > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: entry > not found - rc 0 > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: > Processing add operation local > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > remote dn="cn=Juniper > Cross,ou=Employees,ou=Users,ou=People,dc=corp,dc=itasoftware,dc=com" > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): process_replay_add: > dn="cn=Juniper > Cross,ou=Employees,ou=Users,ou=People,dc=corp,dc=itasoftware,dc=com" > (not present,add allowed) > [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): Received result code 0 () for > add operation > > That's it, until ten minutes later when I tried to change the password: > > [22/Oct/2009:11:16:02 -0400] agmt="cn=ita4windc2" (ita4windc2:636) - > load next: anchorcsn=4ae073560000104d0000 > [22/Oct/2009:11:16:02 -0400] agmt="cn=ita4windc2" (ita4windc2:636) - > load=3 rec=7 csn=4ae075280000104d0000 > [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Looking > at modify operation local > dn="uid=juniper,ou=employees,ou=users,ou=people,dc=itasoftware,dc=com" > (ours,user,not group) > [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking > for AD entry for DS > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > guid="(null)" > [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking > for AD entry for DS > dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" > username="juniper" > [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: found AD > entry dn="CN=Juniper > Cross,OU=Employees,OU=Users,OU=People,DC=corp,DC=itasoftware,DC=com" > [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - > agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: > Processing modify operation local > dn="uid=juniper,ou=employees,ou=users,ou=people,dc=itasoftware,dc=com" > remote dn="CN=Juniper > Cross,OU=Employees,OU=Users,OU=People,DC=corp,DC=itasoftware,DC=com" > > Nada. The badPwdCounter just increments, and the password remains unset. > >>> If we create the users on 389, and sync them back to AD, the >>> password field passed back is blank in Windows. >> When you create the users on 389, are you using the clear text >> password in the userPassword field? > We were not. I created a test user with a cleartext password this > morning, and the result has been functionally identical - the > badPwdCounter increments, and the user password remains blank on the > AD side of things. > >>> >>> Passsync isn't going to work because we're running 64bit Windows, so >>> we can't sync the passwords *from* AD. I got this working earlier, >>> but that was with FDS in a test instance several months ago, and I >>> didn't write down what I did. (And I am kicking myself over that.) >>> We can live without people changing their passwords on AD as long as >>> we *can* sync passwords down from 389. >> We are working on 64-bit Windows support. > Oh, hurrah! Are you also going to change it so that passsync doesn't > store the password in cleartext in the registry? Our Windows admin > just about took my head off when he found that. :/ I'll see if I can > get him to let me use the administrator account on Windows to test > with, though. 64-bit Windows Server 2008 PassSync is now available - version 1.1.2 - http://directory.fedoraproject.org/wiki/Release_Notes > > -- juniper > -------------- 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/20091104/226249cb/attachment.bin
