Hi,
The password sync service between AD and Directory server appears to “can” passwords with extended characters. I’m working for a client in Belgium at the moment and they’re quite accent happy with passwords. Now, Active Directory happily accepts these passwords but I don’t even get a sniff of the password change attempt in the audit log from in 389-DS. Is this a bug or by design ? http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging Thanks Rich ( I don’t normally get access to windows logs J). 04/02/12 14:42:22: Modify password failed for remote entry: uid=<user>,ou=People,<blah> 04/02/12 14:42:22: Deferring password change for <user> 04/02/12 14:42:24: Ldap error in ModifyPassword 19: Constraint violation No problem, bit of digging around tells me that there is a 7 bit character constraint on passwords (7-bit check plugin). What I don’t understand is why there is nothing on the Linux side, surely: 04/02/12 14:42:24: Ldap error in ModifyPassword Means that the password change has been attempted and rejected by the server, so why am I not seeing anything in the logs on the server? Do you see any connections at all from the AD box in your directory server access log? /var/log/dirsrv/slapd-INSTANCE/access Yes, I’ve got this with a tome stamp matching when the user changed their AD password 14:42:21, and 2 seconds later 14:42:23 (there is more of the same every few seconds until it gives up): [02/Apr/2012:14:42:21 +0200] conn=14516 SSL 128-bit RC4 [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 BIND dn="cn=<sync id>,cn=config" method=128 version=3 [02/Apr/2012:14:42:21 +0200] conn=14516 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=<sync id>,cn=config" [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 SRCH base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)" attrs=ALL [02/Apr/2012:14:42:21 +0200] conn=14516 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2012:14:42:21 +0200] conn=14517 fd=106 slot=106 SSL connection from <AD Server IP> to <DS Server IP> [02/Apr/2012:14:42:21 +0200] conn=14517 SSL 128-bit RC4 [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 BIND dn="uid=<user id>,ou=People,<domain>" method=128 version=3 [02/Apr/2012:14:42:21 +0200] conn=14517 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 UNBIND [02/Apr/2012:14:42:21 +0200] conn=14517 op=1 fd=106 closed - U1 [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 MOD dn="uid=<user id>,ou=People,<domain>" [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103 nentries=0 etime=0 [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 UNBIND [02/Apr/2012:14:42:21 +0200] conn=14516 op=3 fd=103 closed - U1 [02/Apr/2012:14:42:23 +0200] conn=14518 fd=103 slot=103 SSL connection from <AD Server IP> to <DS Server IP> [02/Apr/2012:14:42:23 +0200] conn=14518 SSL 128-bit RC4 [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 BIND dn="cn=<sync id>,cn=config" method=128 version=3 [02/Apr/2012:14:42:23 +0200] conn=14518 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=<sync id>,cn=config" [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 SRCH base="ou=People,<domain>" scope=2 filter="(ntUserDomainId=<user id>)" attrs=ALL [02/Apr/2012:14:42:23 +0200] conn=14518 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2012:14:42:23 +0200] conn=14519 fd=106 slot=106 SSL connection from <AD Server IP> to <DS Server IP> [02/Apr/2012:14:42:23 +0200] conn=14519 SSL 128-bit RC4 [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 BIND dn="uid=<user id>,ou=People,<domain>" method=128 version=3 [02/Apr/2012:14:42:23 +0200] conn=14519 op=0 RESULT err=49 tag=97 nentries=0 etime=0 [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 UNBIND [02/Apr/2012:14:42:23 +0200] conn=14519 op=1 fd=106 closed - U1 [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 MOD dn="uid=<user id>,ou=People,<domain>" [02/Apr/2012:14:42:23 +0200] conn=14518 op=2 RESULT err=19 tag=103 nentries=0 etime=0 [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 UNBIND [02/Apr/2012:14:42:23 +0200] conn=14518 op=3 fd=103 closed - U1 Having seen the error logged on the AD Server I guess I should be looking for these entries (err=19) then?: [02/Apr/2012:14:42:21 +0200] conn=14516 op=2 RESULT err=19 tag=103 nentries=0 etime=0 Anyway to get these password failures logged to audit? Hmm - I guess failed modify operations are not logged to the audit log? Anyway, you have confirmed that the directory server doesn't like the passwords - err=19 means that either the password fails the 7-bit checking or fails password syntax checking. It would appear that I only have successful modifications logged in audit. And yes, for sure the problem is the 7-bit check as the guys are using (or trying to) accented characters in their passwords. Regards, Brett ------------------------------------------------------------------- This e-mail and any attachments, which may contain information that is confidential and/or protected by intellectual property rights, are intended for the exclusive use of the above-mentioned addressee(s). Any use (including reproduction, disclosure and whole or partial distribution in any form whatsoever) of their content is prohibited without prior authorization of NRB. If you have received this message by error, please contact the sender promptly by resending this e-mail back to him (her), or by calling the above number. Thank you for subsequently deleting this e-mail and any files attached thereto. -------------------------------------------------------------------
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
