[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-users] IPA to AD sync, certificate verify failed



Sam Hartsfield wrote:
On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson <rmeggins redhat com> wrote:
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
Directory?
Yes.
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
FreeIPA.

You could try using the replication error log level to debug winsync
problems - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
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
password

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.  This
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 properly
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
something:

[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:
Yes.
[root ipaserver samh]# certutil -d /etc/dirsrv/slapd-PRISM-INTERNAL/ -L
Certificate Nickname                                         Trust Attributes
                                                            SSL,S/MIME,JAR/XPI

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

http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Prerequisites.html,
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 cert,
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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]