Has anyone ever come across this error:
[15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Received error [0000216C: AtrErr: DSID-031D0AC0, #1: 0:0000216C: DSID-031D0AC0, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd) ] when attempting to modify entry [<GUID=e873f710d5b9394db14c701cf5f11821>]: Please correct the attribute specified in the error message. Refer to the Windows Active Directory docs for more information. [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): windows_replay_update: update password returned 1 [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Consumer failed to replay change (uniqueid 3783a101-1dd211b2-802fd24c-a4ed0000, CSN 4492399a000000010000): Constraint violation. Skipping.
I used ldapmodify to change the password. This is the ldif file that I used:
dn: uid=user,ou=people,dc=server,dc=example,dc=com changetype: modify replace: userpassword userpassword:: e2NyeXB0fSQxJHREb0RZV3JxJFE5UDVmMmVnSzc4NHAvVXVKVldnTS4=
It successfully changes the password in FDS, but not in AD
Thanks, Jeff
Jeff Gamsby wrote:
Has anyone ever come across this error:
[15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Received error [0000216C: AtrErr: DSID-031D0AC0, #1: 0:0000216C: DSID-031D0AC0, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd) ] when attempting to modify entry [<GUID=e873f710d5b9394db14c701cf5f11821>]: Please correct the attribute specified in the error message. Refer to the Windows Active Directory docs for more information. [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): windows_replay_update: update password returned 1 [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Consumer failed to replay change (uniqueid 3783a101-1dd211b2-802fd24c-a4ed0000, CSN 4492399a000000010000): Constraint violation. Skipping.
The obvious first guess would be that the password fails the AD password policy check.
What happens if you try to change that same user's password to the same value on the AD side ? Does it work ?
David Boreham wrote:
Jeff Gamsby wrote:
Has anyone ever come across this error:
[15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Received error [0000216C: AtrErr: DSID-031D0AC0, #1: 0:0000216C: DSID-031D0AC0, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd) ] when attempting to modify entry [<GUID=e873f710d5b9394db14c701cf5f11821>]: Please correct the attribute specified in the error message. Refer to the Windows Active Directory docs for more information. [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): windows_replay_update: update password returned 1 [15/Jun/2006:21:54:25 -0700] NSMMReplicationPlugin - agmt="cn=AD" (ad:636): Consumer failed to replay change (uniqueid 3783a101-1dd211b2-802fd24c-a4ed0000, CSN 4492399a000000010000): Constraint violation. Skipping.
The obvious first guess would be that the password fails the AD password policy check.
What happens if you try to change that same user's password to the same value on the AD side ? Does it work ?
Yes.
I think what is happening is that when the user account's userpassword attribute gets imported into FDS, it gets base64 encoded, which the FDS understands but AD does not. I have an OpenLDAP server that I am migrating from and when I export the database, add some attributes, then upload into FDS, some attributes get base64 encoded, including userpassword. It happens to some attributes like "cn", so those users don't get synced into AD ( I guess AD gets confused ). If I just retype the "cn" attribute, then it gets synced just fine, but I'm not sure what to do about userpassword. In my OpenLDAP server the passwords are {SSHA}, and I think FDS supports this, I just have to figure out how to format that attribute.
I verified this by adding a user via the admin console, and it seems to work fine.
I tried the LdapImport perl script, but that didn't work. I also tried the other script on the OpenLDAP migration Howto, but that didn't work either.
Thanks
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
So, one thing to know : sync'ing of passwords depends on having access to the plaintext. So importing pre-hashed password values from another DS will never work, ever.
The users' passwords will all need to be reset (on either side) in order for the values to be updated and consistent on both sides.
389-users@lists.fedoraproject.org