[389-users] AD2008 on 64 bit windows, 389 Directory Server passwords...

[Rich Megginson]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20091104/226249cb/attachment.bin>