[Freeipa-users] consulting?
Rich Megginson
rmeggins at redhat.com
Tue Jan 24 21:20:57 UTC 2012
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
> <mailto: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 <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>>>> <http://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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>>> <mailto: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
>>>>>>>>> <http://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
>>>>>>>>> <mailto: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
>>>>>>>>>> <tel:%28-2146875391>)
>>>>>>>>>> Certificate Request
>>>>>>>>>> Processor: The request
>>>>>>>>>> contains no certificate
>>>>>>>>>> template information.
>>>>>>>>>> 0x80094801 (-2146875391
>>>>>>>>>> <tel:%28-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
>>>>>>>>>> <mailto: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
>>>>>>>>>>> <mailto: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 list
>>>>>>>>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120124/ec88f59a/attachment.htm>
More information about the Freeipa-users
mailing list