[Freeipa-users] Sync IPA and AD while using external CA

Mon Nov 2 12:21:45 UTC 2015

Hello,
This is the approach I have followed till now:
I edited /etc/openldap/ldap.conf as follow:
TLS_REQCERT allow
after restarting of dirsrv and using Active directoy's CA file in --cacert
switch it procceded making Sync agreement but failed to do update with this
error:

NSMMReplicationPlugin - agmt="cn=meToad-sercer.local.dc" (ad-server:389) :
Replication bind with SIMPLE auth failed: LDAP error -11 (connect error)
(TLS error -8174:security library: bad database.)

slapi_ldap_bind - Error: could not send startTLS request: error -11
(connect error) errno 0 (Success)

I would be glad if anyone could help me to resolve the error.

On Sat, Oct 31, 2015 at 11:37 AM, mitra dehghan <mitra.dehghan at gmail.com>
wrote:

> Dear Rob,
> Thanks for your response:
>
>
> > Yes but which cert did you provider, the root CA contoso.com or the
> subordinate CA local.dc?
> Actually I was using active directory's certificate with --cacert switch
> in ipa-replica-manage
> Thanks to info you gave me about NSS I changed the approach.
> first: using certutil, I manually added root CA (contoso.com) and
> subordinate(local.dc) certificates in /etc/dirsrv/slapd-REALM database
> # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "contoso.com CA" -t CT,,
> -a -i /path/to/contoso.pem
> # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "local.dc CA" -t CT,, -a
> -i /path/to/localdc.pem
>
> then, following same approach, I added Active directory's certificate to
> the same db.
> # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "active directory CA" -t
> ,, -a -i /path/to/ad.cer
> Note: since the original certificates were in .cer format and its same as
> .pem I just renamed certificates to .pem
>
> Now my db has 5 certificates in:
> a) root CA certificate (contoso.com)
> b) Subordinate CA (local.dc): issued to local.dc by contoso.com
> c) Active directory CA (ad): issued to active directory by local.dc
> d)IPA certificate:issued to IPA server by local.dc
> e)localhost certificate: issued to localhost by IPA server 's internal CA.
>
> finally I ran ipa-replica-manage:
> - using contoso.com CA in --cacert it says TLS error -8179: Peer's
> Certificate issuer is not recognized
> -using local.dc CA in --cacert it says TLS error -8157: Certificate
> extension not found.
> -using Active Directory CA in --cacert it says TLS error -8179: Peer's
> Certificate issuer is not recognized
>
>  I would be glad if you help me more with this issue!
>
> On Fri, Oct 30, 2015 at 5:17 PM, Rob Crittenden <rcritten at redhat.com>
> wrote:
>
>> Please keep responses on the list
>>
>> mitra dehghan wrote:
>> > Thank you for your response.
>> > -First of all in section 15.5.1 of Red hat Enterprise Linux 6 Identity
>> > Management guide it says to copy both ad and IPA certificates in
>> > /etc/openldap/certs and i did the same. of course it worked when i was
>> > using internal CAs.
>>
>> Ok, it doesn't hurt anything, but for the purposes of ipa-replica-manage
>> it is a no-op.
>>
>>
>> > - I pass ad certificate in ipa-replica-manage command via --cacert
>> switch.
>>
>> Yes but which cert did you provider, the root CA contoso.com or the
>> subordinate CA local.dc?
>>
>> > - After all I would be glad if you could give me more info about NSS
>> > database. Is that kind of substitute for /etc/openldap/certs? would you
>> > please give me more details about configurations needed for that?
>>
>> The crypto library that 389-ds uses is NSS. This uses a database to
>> store certificates and keys rather than discrete files. The certutil
>> tool is used to manage this file (there is a brief man page).
>>
>> ipa-replica-manage will add the AD cert to 389-ds for you, but you can
>> add certs manually and I think it might help in this case:
>>
>> # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "contoso.com CA" -t
>> CT,, -a -i /path/to/contoso.pem
>> # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "local.dc CA" -t CT,,
>> -a -i /path/to/localdc.pem
>>
>> The -n option specifies a "nickname" to use for the certificate. You can
>> use pretty much anything you want but being descriptive helps.
>>
>> rob
>>
>> >
>> >
>> >
>> > On Wed, Oct 28, 2015 at 5:20 PM, Rob Crittenden <rcritten at redhat.com
>> > <mailto:rcritten at redhat.com>> wrote:
>> >
>> >     mitra dehghan wrote:
>> >     > hello,
>> >     > I want to implement and IPA server and Sync it with my 2012 ms ad.
>> >     While
>> >     > things go well using an internal CA in each server, I came across
>> kind
>> >     > of problem when I want integrate solution with my PKI which is
>> already
>> >     > serving the AD server.
>> >     > I can install IPA with --external-ca switch. but when it comes to
>> >     Sync.
>> >     > agreement it says "TLS error -8179:Peer's Certificate issuer is
>> not
>> >     > recognized."
>> >     >
>> >     > The architecture is:
>> >     > - There is a root CA named contoso.com <http://contoso.com>
>> >     <http://contoso.com>
>> >     > - There is a subordinate CA named local.dc
>> >     > - The certificates of AD and IPA server are both issued by
>> local.dc
>> >     > - IPA's certificate is issued  based on the CSR file generated by
>> >     > ipa-server-install
>> >     > - I have copied both certificates in /etc/openldap/certs
>> directory and
>> >     > the rest was same as what i did in the internal CA scenario.
>> >     >
>> >     > while the FreeIPA docs say both servers must have internal CA's i
>> need
>> >     > to integrate solution with available PKI.
>> >     > I would be glad hear suggestions if this scenario is applicable
>> >     and what
>> >     > is wrong there.
>> >     > thank you
>> >
>> >     389-ds doesn't use /etc/openldap/certs.
>> >
>> >     What cert are you passing in when creating the winsync agreement
>> using
>> >     ipa-replica-manage?
>> >
>> >     You may need/want to add these certs to the IPA 389-ds NSS database
>> >     prior to setting up the agreement.
>> >
>> >     rob
>> >
>> >
>> >
>> >
>> > --
>> > m-dehghan
>>
>>
>
>
> --
> m-dehghan
>

-- 
m-dehghan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20151102/178a1efc/attachment.htm>