[Freeipa-users] IPA to AD sync, certificate verify failed
Rich Megginson
rmeggins at redhat.com
Tue Nov 17 20:13:55 UTC 2009
Sam Hartsfield wrote:
> 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?
>
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
http://support.microsoft.com/kb/906305/en-us - there may be other
changes that cause problems.
> Thanks,
> Sam Hartsfield
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20091117/ac7edd8e/attachment.bin>
More information about the Freeipa-users
mailing list