On Mon, Nov 16, 2009 at 10:16 AM, Rich Megginson <rmegg...@redhat.com> wrote: > Sam Hartsfield wrote: >> >> On Thu, Nov 12, 2009 at 3:38 PM, Rich Megginson <rmegg...@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. >>> >>> [r...@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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users