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

Tue Nov 17 19:28:34 UTC 2009

On Mon, Nov 16, 2009 at 10:16 AM, Rich Megginson <rmeggins at redhat.com> wrote:
> Sam Hartsfield wrote:
>>
>> On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson <rmeggins at 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 at 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
>>
>
>

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?

Thanks,
Sam Hartsfield