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.
