On 04/03/2012 08:09 AM, MATON Brett wrote:
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.
Ok. You can turn off the 7-bit check plugin
shutdown 389
edit /etc/dirsrv/slapd-INST/dse.ldif - look for cn=7-bit
check,cn=plugins,cn=config - change the nsslapd-pluginenabled: off
start 389
Regards,
Brett
-------------------------------------------------------------------
*GreeNRB
*/NRB considers its environmental responsibility and goes for green IT./
/May we ask you to consider yours before printing this e-mail? /**
*NRB, daring to commit
*/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
