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
/^^^
--
389 users mailing list
389-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
