[Freeipa-users] consulting?
Jimmy
g17jimmy at gmail.com
Tue Jan 24 21:51:05 UTC 2012
The cert I'm using both in the sync agreement and in the openssl command
has the serial number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27
(AD-server-cert.cer.) The serial number that shows in the pcap coming from
AD in both instances is 61:13:fd:30:00:00:00:00:00:04 (line 196 in the
fpaste)
OpenSSL command: openssl s_client -connect xxx-ad.xxx.xxx:636 -CAfile
/home/winsync/AD-server-cert.cer
OpenSSL output- http://fpaste.org/Zx5N/
Both the output of openssl and the pcap of the openssl session look
successful here.
Thanks for your help.
Jimmy
On Tue, Jan 24, 2012 at 4:20 PM, Rich Megginson <rmeggins at redhat.com> wrote:
> **
> On 01/24/2012 02:07 PM, Jimmy wrote:
>
> certutil output:
> http://fpaste.org/tJDW/
>
> pcap output (exported from Wireshark, looks messy):
> http://fpaste.org/M3Gr/
>
> hard to tell from the pcap output, but is
>
> Serial Number: 68:10:1c:98:3b:5c:e7:8d:43:ec:e3:e7:6a:e7:de:27
> Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
> Issuer: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx"
> Validity:
> Not Before: Thu Jan 19 17:52:07 2012
> Not After : Thu Jan 19 18:02:04 2017
> Subject: "CN=xxxad-xxx-AD-CA,DC=xxxad,DC=xxx,DC=xxx"
>
> the same cert as the cert from the pcap output that is called
> Distinguished Name:
> (id-at-commonName=xxxad-XXX-AD-CA,dc=xxxad,dc=xxx,dc=xxx)
>
> because this appears to be the AD CA cert sent over from AD as part of the
> SSL handshake
>
> There are a couple of good tools to use to diagnose/debug connection
> problems between 389 and AD before you attempt to use winsync with ssl.
>
> The first is openssl s_client
> openssl s_client -connect ADhost:636 -CAfile /path/to/adca.cer
>
> The second is mozldap ldapsearch:
> /usr/lib64/mozldap/ldapsearch -h ADHost -p 636 -Z -P
> /etc/dirsrv/slapd-INST/cert8.db -s base -b "" "objectclass=*"
>
> The third is openldap ldapsearch:
> LDAPTLS_CACERT=/path/to/adca.cer ldapsearch -x -h ADHost -p 636 -s base -b
> "" "objectclass=*"
>
> For the last you can add "-d 1" to get detailed SSL error messages
>
>
> On Tue, Jan 24, 2012 at 3:29 PM, Rich Megginson <rmeggins at redhat.com>wrote:
>
>> On 01/24/2012 01:26 PM, Jimmy wrote:
>>
>> The sync is still not working so I was going back through the docs to see
>> what I missed. I know this is from an older version of IPA but I was
>> looking here:
>> 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#sect-Installation_and_Deployment_Guide-Prerequisites-Setting_up_Active_Directory
>>
>> and used this method to get the AD certificate server cert.
>>
>> You mean "CA cert" not "server cert", right?
>>
>>
>> 1. Navigate to My Network Places and drill down to the CA
>> distribution point. On Windows 2003 Server this is typically
>> C:\WINDOWS\system32\certsrv\CertEnroll\
>> 2. Double-click the security certificate file (.crt file) to
>> display the *Certificate* dialog box.
>> 3. On the *Details* tab, click *Copy to File* to start the *Certificate
>> Export Wizard*.
>> 4. Click *Next*, select *Base-64 encoded X.509 (.CER)* and then
>> click *Next*.
>> 5. Specify a suitable directory and file name for the exported
>> file. The file name is not important. Click *Next* to export the
>> certificate, and then click *Finish*. You should receive a message
>> stating that the export was successful.
>> 6. Click *OK* to exit the wizard.
>>
>> But when I run the command to create the sync agreement(pointing to the
>> cert I got in the step above) the ssl connection fails and if I look at
>> tcpdump of the connection I see that the AD server is not sending the cert
>> that I have imported with the sync agreement. I have used certutil to
>> verify that I have the same cert(same serial number and same public key) in
>> the 389 server as the one in the AD server ( C:\WINDOWS\system32\
>> certsrv\CertEnroll\). The AD server is sending a completely different
>> cert, and I have been unable to find the cert in the certificate stores on
>> the AD server so I'm not sure where the bogus cert is coming from. Before I
>> added the certificate services role the certsrv\certenroll directory was
>> not present so I know this was created when I added that role to the AD
>> server.
>>
>> The pcap can be seen here:
>> http://www.pcapr.net/view/g17jimmy/2012/0/2/11/ldaps3.pcap.html (sorry,
>> registration required on that site, I didn't have anywhere else to put it.)
>>
>> Can you try fpaste.org?
>>
>>
>> Any idea why AD would be sending me the wrong cert and where it's
>> coming from? Yes, I know this isn't MS just trying to get these 2 systems
>> to talk ;).
>>
>> On Tue, Jan 24, 2012 at 1:18 PM, Rich Megginson <rmeggins at redhat.com>wrote:
>>
>>> On 01/24/2012 11:03 AM, Jimmy wrote:
>>>
>>> Ok, I just realized that I only have passsync and not winsync, stupid
>>> oversight, but now that I know it I need to get winsync. Is there a
>>> location to download binaries or must I compile from source? I see the
>>> binaries for passsync on the directory server project downloads but I don't
>>> see the same for winsync.
>>>
>>> winsync is built-in to 389 - there isn't any additional component that
>>> you need to install.
>>>
>>>
>>> Thanks,
>>> Jim
>>>
>>> On Mon, Jan 23, 2012 at 1:33 PM, Rich Megginson <rmeggins at redhat.com>wrote:
>>>
>>>> On 01/23/2012 11:34 AM, Jimmy wrote:
>>>>
>>>> I did create the winsync user and it is an admin.
>>>>
>>>> I will fix the ip address(change to hostname,) I only did it that was
>>>> because this is currently a test system so I can figure out how to get it
>>>> all working.
>>>>
>>>> ok - once you do that, you can check the 389 errors log at
>>>> /var/log/dirsrv/slapd-INST/errors to see if winsync is logging any errors
>>>>
>>>>
>>>> On Mon, Jan 23, 2012 at 1:06 PM, Rich Megginson <rmeggins at redhat.com>wrote:
>>>>
>>>>> On 01/23/2012 10:52 AM, Jimmy wrote:
>>>>>
>>>>> That's what I was thinking, and what I did, but it still doesn't
>>>>> replicate new users. This is the command I used:
>>>>>
>>>>> ipa-replica-manage connect --passsync --binddn
>>>>> cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp --bindpw=******** --cacert
>>>>> /home/winsync/AD-server-cert.cer 192.168.201.150 -v
>>>>>
>>>>>
>>>>> Did you create the user cn=winsync,cn=Users,dc=cspad,dc=pdh,dc=csp?
>>>>> And does this user have the rights to perform sync? (e.g. has to have
>>>>> replicator rights, or be some sort of admin) - see
>>>>> http://msdn.microsoft.com/en-us/library/ms677626%28VS.85%29.aspx -
>>>>> the AD user must have replication rights and write rights.
>>>>>
>>>>> In addition, since this process uses SSL, you cannot use an IP
>>>>> address, you must use a hostname, or the SSL cert hostname checking (for
>>>>> MITM) will fail.
>>>>>
>>>>>
>>>>> On Mon, Jan 23, 2012 at 12:30 PM, Rich Megginson <rmeggins at redhat.com
>>>>> > wrote:
>>>>>
>>>>>> On 01/23/2012 10:19 AM, Jimmy wrote:
>>>>>>
>>>>>> Here's what I found in the DS admin guide. Is this all that's needed
>>>>>> to create the sync agreement?
>>>>>>
>>>>>> Not with ipa - you should use the ipa-replica-manage command
>>>>>> instead
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> add sync agreement:
>>>>>> ldapmodify -x -D "cn=Directory Manager" -W
>>>>>> Enter LDAP Password: *******
>>>>>> dn: cn=ExampleSyncAgreement,cn=sync
>>>>>> replica,cn=dc=example\,dc=com,cn=mapping tree,cn=config
>>>>>>
>>>>>> it should be cn=replica, not cn=sync replica - does it use the
>>>>>> latter in the Admin Guide?
>>>>>>
>>>>>> changetype: add
>>>>>> objectclass: top
>>>>>> objectclass: nsDSWindowsReplicationAgreement
>>>>>> cn: ExampleSyncAgreement
>>>>>> nsds7WindowsReplicaSubtree: cn=Users,dc=ad1
>>>>>> nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com
>>>>>>
>>>>>> nsds7NewWinUserSyncEnabled: on
>>>>>> nsds7NewWinGroupSyncEnabled: on
>>>>>> nsds7WindowsDomain: ad1
>>>>>> nsDS5ReplicaRoot: dc=example,dc=com
>>>>>> nsDS5ReplicaHost: ad1.windows-server.com
>>>>>> nsDS5ReplicaPort: 389
>>>>>> nsDS5ReplicaBindDN: cn=sync user,cn=config
>>>>>> nsDS5ReplicaBindCredentials: {DES}ffGad646dT0nnsT8nJOaMA==
>>>>>> nsDS5ReplicaTransportInfo: TLS
>>>>>> winSyncInterval: 1200
>>>>>>
>>>>>> On Fri, Jan 20, 2012 at 3:28 PM, Rich Megginson <rmeggins at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> On 01/20/2012 01:08 PM, Jimmy wrote:
>>>>>>>
>>>>>>> That was it! I have passwords syncing, *BUT*(at the risk of sounding
>>>>>>> stupid)-- is it not possible to also sync(add) the users from AD to DS?
>>>>>>>
>>>>>>> Yes, it is. Just configure IPA Windows Sync
>>>>>>>
>>>>>>> I created a new user in AD and it doesn't propogate to DS, just
>>>>>>> says:
>>>>>>>
>>>>>>> attempting to sync password for testuser3
>>>>>>> searching for (ntuserdomainid=testuser3)
>>>>>>> There are no entries that match: testuser3
>>>>>>> deferring password change for testuser3
>>>>>>>
>>>>>>> On Fri, Jan 20, 2012 at 2:46 PM, Rich Megginson <
>>>>>>> rmeggins at redhat.com> wrote:
>>>>>>>
>>>>>>>> On 01/20/2012 12:46 PM, Jimmy wrote:
>>>>>>>>
>>>>>>>> Getting close here... Now I see this message in the sync log file:
>>>>>>>>
>>>>>>>> attempting to sync password for testuser
>>>>>>>> searching for (ntuserdomainid=testuser)
>>>>>>>> ldap error in queryusername
>>>>>>>> 32: no such object
>>>>>>>> deferring password change for testuser
>>>>>>>>
>>>>>>>> This usually means the search base is incorrect or not found.
>>>>>>>> You can look at the 389 access log to see what it was using as the search
>>>>>>>> criteria.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 20, 2012 at 12:23 PM, Rich Megginson <
>>>>>>>> rmeggins at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> On 01/20/2012 10:23 AM, Jimmy wrote:
>>>>>>>>>
>>>>>>>>> You are correct. I had installed as an Enterprise root, but the
>>>>>>>>> doc I was reading(original link) seemed to say that I had to do the certreq
>>>>>>>>> manually, my bad. I think I'm getting closer I can establish an openssl
>>>>>>>>> connection from DS to AD but I get these errors:
>>>>>>>>>
>>>>>>>>> openssl s_client -connect 192.168.201.150:636 -showcerts
>>>>>>>>> -CAfile dsca.crt
>>>>>>>>> CONNECTED(00000003)
>>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp
>>>>>>>>> verify error:num=20:unable to get local issuer certificate
>>>>>>>>> verify return:1
>>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp
>>>>>>>>> verify error:num=27:certificate not trusted
>>>>>>>>> verify return:1
>>>>>>>>> depth=0 CN = csp-ad.cspad.pdh.csp
>>>>>>>>> verify error:num=21:unable to verify the first certificate
>>>>>>>>> verify return:1
>>>>>>>>>
>>>>>>>>> I thought I had imported the cert from AD but it doesn't seem
>>>>>>>>> so. I'm still researching but if you guys have a suggestion let me know.
>>>>>>>>>
>>>>>>>>> Is dsca.crt the CA that issued the DS server cert? If so, that
>>>>>>>>> won't work. You need the CA cert from the CA that issued the AD server
>>>>>>>>> cert (i.e. the CA cert from the MS Enterprise Root CA).
>>>>>>>>>
>>>>>>>>> -J
>>>>>>>>>
>>>>>>>>> On Thu, Jan 19, 2012 at 5:04 PM, Rich Megginson <
>>>>>>>>> rmeggins at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 01/19/2012 02:59 PM, Jimmy wrote:
>>>>>>>>>>
>>>>>>>>>> ok. I started from scratch this week on this and I think I've got
>>>>>>>>>> the right doc and understand better where this is going. My problem now is
>>>>>>>>>> that when configuring SSL on the AD server (step c in this url:
>>>>>>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Install_and_Configure_the_Password_Sync_Service )
>>>>>>>>>>
>>>>>>>>>> I get this error:
>>>>>>>>>>
>>>>>>>>>> certreq -submit request.req certnew.cer
>>>>>>>>>> Active Directory Enrollment Policy
>>>>>>>>>> {25DDA1E7-3A99-4893-BA32-9955AC9EAC42}
>>>>>>>>>> ldap:
>>>>>>>>>> RequestId: 3
>>>>>>>>>> RequestId: "3"
>>>>>>>>>> Certificate not issued (Denied) Denied by Policy Module
>>>>>>>>>> 0x80094801, The request does not contain a certificate template extension
>>>>>>>>>> or the CertificateTemplate request attribute.
>>>>>>>>>> The request contains no certificate template information.
>>>>>>>>>> 0x80094801 (-2146875391)
>>>>>>>>>> Certificate Request Processor: The request contains no
>>>>>>>>>> certificate template information. 0x80094801 (-2146875391)
>>>>>>>>>> Denied by Policy Module 0x80094801, The request does not
>>>>>>>>>> contain a certificate template extension or the CertificateTemplate request
>>>>>>>>>> attribute.
>>>>>>>>>>
>>>>>>>>>> The RH doc says to use the browser if an error occurs and IIS
>>>>>>>>>> is running but I'm not running IIS. I researched that error but didn't find
>>>>>>>>>> anything that helps with FreeIPA and passsync.
>>>>>>>>>>
>>>>>>>>>> Hmm - try installing Microsoft Certificate Authority in
>>>>>>>>>> Enterprise Root CA mode - it will usually automatically create and install
>>>>>>>>>> the AD server cert.
>>>>>>>>>> http://directory.fedoraproject.org/wiki/Howto:WindowsSync
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jimmy
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 11, 2012 at 3:32 PM, Rich Megginson <
>>>>>>>>>> rmeggins at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 01/11/2012 11:22 AM, Jimmy wrote:
>>>>>>>>>>>
>>>>>>>>>>> We need to be able to replicate user/pass between Windows 2008
>>>>>>>>>>> AD and FreeIPA.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That's what IPA Windows Sync is supposed to do.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have followed many different documents and posted here about
>>>>>>>>>>> it and from what I've read and procedures I've followed we are unable to
>>>>>>>>>>> accomplish this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What have you tried, and what problems have you run into?
>>>>>>>>>>>
>>>>>>>>>>> It doesn't need to be a full trust.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 10, 2012 at 3:03 AM, Jan Zelený <jzeleny at redhat.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> > Just wondering if there was anyone listening on the list
>>>>>>>>>>>> that might be
>>>>>>>>>>>> > available for little work integrating FreeIPA with Active
>>>>>>>>>>>> Directory
>>>>>>>>>>>> > (preferrably in the south east US.) I hope this isn't against
>>>>>>>>>>>> the list
>>>>>>>>>>>> > rules, I just thought one of you guys could help or point me
>>>>>>>>>>>> in the right
>>>>>>>>>>>> > direction.
>>>>>>>>>>>>
>>>>>>>>>>>> If you want some help, it is certainly not against list
>>>>>>>>>>>> rules ;-) But in that
>>>>>>>>>>>> case, it would be much better if you asked what exactly do you
>>>>>>>>>>>> need.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not an AD expert, but a couple tips: If you are looking for
>>>>>>>>>>>> cross-domain
>>>>>>>>>>>> (cross-realm) trust, then you might be a bit disappointed, it
>>>>>>>>>>>> is still in
>>>>>>>>>>>> development, so it probably won't be 100% functional at this
>>>>>>>>>>>> moment.
>>>>>>>>>>>>
>>>>>>>>>>>> If you are looking for something else, could you be a little
>>>>>>>>>>>> more specific what
>>>>>>>>>>>> it is?
>>>>>>>>>>>>
>>>>>>>>>>>> I also recommend starting with reading some doc:
>>>>>>>>>>>> http://freeipa.org/page/DocumentationPortal
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120124/f3967b24/attachment.htm>
More information about the Freeipa-users
mailing list