[Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)

[Nevada Sanchez]

Okay, I ran it with debug on. The output is quite large. I'm not sure what
the etiquette is for posting large logs, so I threw it on gist here:
https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt<http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt>

Let me know if I should copy it into the thread instead.


On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson <rmeggins at redhat.com> wrote:

>  On 04/02/2014 11:45 AM, Nevada Sanchez wrote:
>
> My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged
> user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now
> works just fine (same result as the one that worked). SSL seems to not be
> the issue. Also, I haven't change the SSL certs since I first set up the
> master.
>
>  I have been doing the replica side things from scratch (even so far as
> starting with a new machine). For the master side, I have just been
> re-preparing the replica. I hope I don't have to start from scratch with
> the master replica.
>
>
> I guess the next step would be to do the ipa-replica-install using -ddd
> and review the extra debug information that comes out.
>
>
>
>
> On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden <rcritten at redhat.com>wrote:
>
>> Rich Megginson wrote:
>>
>>>  On 04/02/2014 09:20 AM, Nevada Sanchez wrote:
>>>
>>>>  Okay, we might be on to something:
>>>>
>>>> ipa -> ipa2
>>>> ================================
>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ
>>>>  -h ipa2.example.com <http://ipa2.example.com> -s base -b ""
>>>>
>>>> 'objectclass=*' vendorVersion
>>>> dn:
>>>> vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751
>>>> ================================
>>>>
>>>> ipa2 -> ipa
>>>> ================================
>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ
>>>>  -h ipa.example.com <http://ipa.example.com> -s base -b ""
>>>>
>>>> 'objectclass=*' vendorVersion
>>>> ldap_start_tls: Connect error (-11)
>>>> additional info: TLS error -8172:Peer's certificate issuer has been
>>>> marked as not trusted by the user.
>>>> ================================
>>>>
>>>> The original IPA trusts the replica (since it signed the cert, I
>>>> assume), but the replica doesn't trust the main IPA server. I guess
>>>> the ZZ option would have shown me the failure that I missed in my
>>>> initial ldapsearch tests.
>>>>
>>>          -Z[Z]  Issue StartTLS (Transport Layer Security) extended
>>> operation. If
>>>                you  use  -ZZ, the command will require the operation to
>>> be suc-
>>>                cessful.
>>>
>>> i.e. use SSL, and force a successful handshake
>>>
>>>
>>>> Anyway, what's the best way to remedy this in a way that makes IPA
>>>> happy? (I've found that LDAP can have different requirements on which
>>>> certs go where).
>>>>
>>>
>>> I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install
>>> is supposed to take care of installing the CA cert properly for you. If
>>> you try to hack it and install the CA cert manually, you will probably
>>> miss something else that ipa install did not do.
>>>
>>> I think the only way to ensure that you have a properly configured ipa
>>> server + replicas is to get all of the ipa commands completing
>>> successfully.
>>>
>>> Which means going back to the drawing board and starting over from
>>> scratch.
>>>
>>
>> You can compare the certs that each side is using with:
>>
>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM
>>
>> Did you by chance replace the SSL server certs that IPA uses on your
>> working master?
>>
>> rob
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140402/5361d09b/attachment.htm>