Sam Hartsfield wrote:
On Mon, Nov 16, 2009 at 10:16 AM, Rich Megginson <> wrote:
Sam Hartsfield wrote:
On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson <>

Sam Hartsfield wrote:

I am using FreeIPA 1.2.2 and trying to synchronize with AD on Windows
Server 2003.

Are password changes in FreeIPA supposed to be synced to Active


I couldn't find any reference to this specific in the
documentation, but on my test setup passwords are not being changed in
AD (using the ipa-passwd command; I also tried the Windows XP password
change dialog). Password changes in AD /are/ properly reflected in

You could try using the replication error log level to debug winsync
problems -

When I the run command to add the sync (I'm using Administrator just
for testing purposes):

ipa-replica-manage add --winsync --binddn
CN=Administrator,CN=Users,DC=prism,DC=internal --bindpw password
--cacert /home/samh/prism_ad.cer prism_ad.prism.internal -v --passsync

I get this:

INFO:root:Added CA certificate /home/samh/prism_ad.cer to certificate
database for ipaserver.prism.internal
INFO:root:Restarted directory server ipaserver.prism.internal
INFO:root:Could not validate connection to remote server
prism_ad.prism.internal:636 - continuing
INFO:root:The error was: {'info': 'error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed',
'desc': "Can't contact LDAP server"}

indicating a certificate problem,

This just means the script could not open and verify the connection.
is due to a "bug" in python-ldap or openldap, in that if you have already
specified a CA cert, it will not let you specify another one.  This is
usually ok and can be ignored.

Good to know.

and there are similar connection
errors in the dirsrv error log.

That's not so good.  That usually means the CA cert from AD was not
installed in the directory server cert db.

What errors do you see?

Hmm... I did see some errors, but not really anymore. I was seeing
this, but maybe it was just when I was rebooting the AD server or

[09/Nov/2009:12:30:46 -0500] slapi_ldap_bind - Error: could not send
bind request for id [CN=Administrator,CN=Users,DC=prism,DC=internal]
mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP
connection reset by peer.) 115 (Operation now in progress)

You would see this if you were rebooting the AD machine.  If you see it
otherwise, it could be a problem.
I also see a few of these:

[13/Nov/2009:14:50:53 -0500] NSMMReplicationPlugin - failed to send
dirsync search request: 2

This is benign and will be fixed in the next release.
Okay, I looked at the FAQ you linked above and changed the log level
to 8192. Here's one of the messages I see after using ipa-passwd:
[13/Nov/2009:19:05:34 -0500] NSMMReplicationPlugin -
agmt="cn=meToprism_ad.prism.internal636" (prism_ad:636): AD already
has the current password for CN=Sam
Hartsfield,CN=Users,DC=prism,DC=internal. Not sending password modify
to AD.

I'm attaching a longer portion of the log. As far as I can tell, the
password has not been changed on the AD side, only in IPA (using a
Windows XP client attached to the domain, the new password does not
allow me to log in).

Windows 2003 or 2008?  32-bit or 64-bit?
However, I was able to connect with
the ldapsearch command after adding a line for that same file to my
".ldaprc" ("TLS_CACERT /home/samh/prism_ad.cer"):

     ldapsearch -x -D CN=Administrator,CN=Users,DC=prism,DC=internal -w
password -H ldaps://prism_ad.prism.internal -b "dc=prism,dc=internal"

Ok.  Try this:
certutil -d /etc/dirsrv/slapd-YOUR-INSTANCE-HERE -L
you should see an entry for your MS CA - if you do, then try this
/usr/lib/mozldap/ldapsearch -h adhostname -p 636 -Z -P
/etc/dirsrv/slapd-YOUR-INSTANCE-HERE/cert8.db -D
"CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base -b

I'm guessing "Imported CA" might be the AD certificate:

[r...@ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L
Certificate Nickname                                         Trust


CA certificate                                               CTu,u,Cu
Imported CA                                                  CT,,C
Server-Cert                                                  u,u,u

I was wondering where that version of ldapsearch was. I ran this, and
got the expected output (all my attributes):

/usr/lib/mozldap/ldapsearch -h prism_ad.prism.internal -p 636 -Z -P
/etc/dirsrv/slapd-PRISM-INTERNAL/cert8.db -D
"CN=Administrator,CN=Users,DC=prism,DC=internal" -w password -s base
-b "" sAMAccountname=samh

As expected, it did not run without the -P option ("SSL initialization
failed: error -8174 (security library: bad database.)").

Right.  mozldap uses NSS for crypto, just like the directory server, so
that's how you can test the cert db.

This would seem to indicate that you have the correct MS CA cert in your
cert db.
 I exported the certificate using the directions,
and the file is readable by all users.

This seems to be similar to Jeff Moody's problem earlier this year in
the topic "IPA Windows Sync - Windows 2003 R2 SP2 and Fedora 10". I
also created an "Enterprise root CA", but he didn't specify how he
finally found the correct certificate, just that it wasn't easy! I've
searched the computer, and the only ".crt" file is the one I used. In
the "Certification Authority" tool, I see that there are two
certificates in the chain, but if I export the other one,
ipa-replica-manage says "could not add certificate to token or
database: Error adding certificate to database."

Does anyone have any idea what might be going wrong?

If you are able to successfully use openldap ldapsearch with that ca
then either it's not a problem with the CA cert, or you have no TLS/SSL
checking whatsoever in your ldap configuration.

It certainly seems to be checking; it failed to work over SSL until I
added that TLS_CACERT line.

Thanks for your comments and suggestions, Rich. I'll continue working
on this next week, and also try to set up a new sync agreement from
scratch with two new machines.

Sam Hartsfield

I haven't seen anymore of the errors I mentioned, so I'm guessing that
was just from a reboot.

The AD server is Windows Server 2003, 32-bit.

It sounds like the certificate is okay, but passwords still don't seem
to be sent back to AD. I've been checking the dirsrv error log as I
mentioned, and I don't see anything that looks like an error; I can
attach another excerpt if that would help. Is there anything else I
should be looking at?
I don't know. Other people in the 389 community have reported problems sync'ing password changes from DS to AD. I'm not sure what's going on. It seems that MS made some changes to the default AD password policies in 2003 SP1 and later (including 2008). One change is that AD allows you to use your old password for up to 1 hour after changing it - see - there may be other changes that cause problems.
Sam Hartsfield

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Freeipa-users mailing list

Reply via email to