Sam Hartsfield wrote:
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.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#TroubleshootingWhen 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: 2This 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,uI 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 HartsfieldI 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
