[Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Giorgos Kafataridis]

On 09/16/2016 06:39 PM, Petr Vobornik wrote:
> On 09/14/2016 07:26 PM, Giorgos Kafataridis wrote:
>>
>> On 09/13/2016 10:36 PM, Endi Sukma Dewata wrote:
>>> On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote:
>>>> On 9/9/2016 2:46 PM, Georgios Kafataridis wrote:
>>>>> I've tried that but still the same result.
>>>>>
>>>>> [root at ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h
>>>>> localhost -b "uid=admin,ou=people,o=ipaca"
>>>>> Enter LDAP Password:
>>>>> # extended LDIF
>>>>> #
>>>>> # LDAPv3
>>>>> # base <uid=admin,ou=people,o=ipaca> with scope subtree
>>>>> # filter: (objectclass=*)
>>>>> # requesting: ALL
>>>>> #
>>>>>
>>>>> # search result
>>>>> search: 2
>>>>> result: 32 No such object
>>>> Hi,
>>>>
>>>> The master's logs indicate there's an authentication issue.
>>>>
>>>> Could you search the whole directory to find the admin user?
>>>> $ ldapsearch ... -b "o=ipaca" "(uid=admin)"
>>>>
>>>> Try also other suffixes that you have in the DS.
>>>>
>>>> If you find it, try to authenticate against DS directly as the admin
>>>> user. If the authentication fails, try resetting the password.
>>> I believe there is actually another DS instance on CentOS 6.8 running on port
>>> 7389, so make sure you check that too. If the admin user is indeed missing, it
>>> will need to be recreated, assigned a password and certificate, and added to
>>> the appropriate groups.
>>>
>>> See also: http://pki.fedoraproject.org/wiki/IPA_PKI_Users
>>>
>> Sorry for the delay, crazy office days.
>>
>> Ok, tried that and finally got a hit on the user. Indeed in 6.x you also have
>> 7389 to look for.
>>
>> *Master
>>
>> *#ldapsearch -h localhost -p 7389 -b "o=ipaca" "(uid=admin)" -x -W
>> Enter LDAP Password:
>>
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <o=ipaca> with scope subtree
>> # filter: (uid=admin)
>> # requesting: ALL
>> #
>>
>> # admin, people, ipaca
>> dn: uid=admin,ou=people,o=ipaca
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: inetOrgPerson
>> objectClass: cmsuser
>> uid: admin
>> sn: admin
>> cn: admin
>> mail: root at localhost
>> usertype: adminType
>> userstate: 1
>> description: 2;6;CN=Certificate Authority,O=NELIOS;CN=ipa-ca-agent,O=NELIOS
>> userCertificate:: MIIDaTCCAlGgAwIBAgIBBjANBgkqhkiG9w0BAQsFADAxMQ8wDQYDVQQKEwZO....
>> .
>> .
>> .
>> .
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>>
>> *Replica Server*
>>
>> [root at ipa2-server2 ~]# ldapsearch -h ipa-server.nelios -p 7389 -b "o=ipaca"
>> "(uid=admin)" -x -W
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <o=ipaca> with scope subtree
>> # filter: (uid=admin)
>> # requesting: ALL
>> #
>>
>> # admin, people, ipaca
>> dn: uid=admin,ou=people,o=ipaca
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: inetOrgPerson
>> objectClass: cmsuser
>> uid: admin
>> sn: admin
>> cn: admin
>> mail: root at localhost
>> usertype: adminType
>> userstate: 1
>>
>> Password is valid in both cases.
>>
>> So the user is there and can be retrieved from replica, assuming that
>> ipa-replica-install also tries 7389 the only thing I can try now is "ipa
>> cert-request --uid admin" to create a new certificate, generate a new cacert.p12
>> and retry install ?
>>
>>
> In the other subthred there was a log from CentOS6 machine:
>
> /var/log/pki-ca/system
>
> 5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [6] [6] Failed to
> authenticate as admin UID=admin. Error: netscape.ldap.LDAPException:
> error result (49)
> 5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [3] [3] Servlet
> caGetCookie: Error getting servlet output stream when rendering
> template. Error Invalid Credential..
>
> Which to me looks like a wrong password. Which indicates my original
> theory that IPA admin user shared with CA admin user the same password
> but it got out of sync. During replica installation it uses IPA admin
> user for authenticating as PKI admin user.
>
> If that is correct then changing PKI admin user's (
> uid=admin,ou=people,o=ipaca ) password to IPA admin user's password
> might fix the issue.
>
Thanks! Ok, I will look into that more. In any case, I'll keep you posted.