Fedora directory users - Oct 2009 - [389-users] AD2008 on 64 bit windows, 389 Directory Server passwords...

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.
If we create the users on 389, and sync them back to AD, the password 
field passed back is blank in Windows.

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.

The replication manager account on AD has full Directory Admin privs, so 
it *does* have the ability to update passwords.

What am I missing?  Our logs are showing us a lot of things that are not 
helpful; I will be happy to attach further logs if people can tell me 
what to look for, but we''ve been trying this for two days now, and
we''re
not any closer than we were when we started.

-- 
,___,
{o,o}  Anne "Juniper" Cross
(___)  Senior Linux Systems Engineer and Extropic Crusader
-"-"-- Information Technology, ITA Software
/^^^

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
> 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?
>
> 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.
>
> The replication manager account on AD has full Directory Admin privs, 
> so it *does* have the ability to update passwords.
Try it with cn=administrator,cn=users,dc=yourdomain,dc=com to rule out 
any permissions issues.
>
> What am I missing?  Our logs are showing us a lot of things that are 
> not helpful; I will be happy to attach further logs if people can tell 
> me what to look for, but we''ve been trying this for two days now,
and
> we''re not any closer than we were when we started.
>

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.

    -- juniper

-- 
,___,
{o,o}  Anne "Juniper" Cross
(___)  Senior Linux Systems Engineer and Extropic Crusader
-"-"-- Information Technology, ITA Software
/^^^

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
>