<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 09/19/2016 03:51 PM, Giorgos Kafataridis wrote:<br>
<blockquote
cite="mid:e0ccc844-2988-192f-da8b-b8cfe79089f0@nelios.com"
type="cite">
<br>
<br>
On 09/16/2016 06:39 PM, Petr Vobornik wrote:
<br>
<blockquote type="cite">On 09/14/2016 07:26 PM, Giorgos
Kafataridis wrote:
<br>
<blockquote type="cite">
<br>
On 09/13/2016 10:36 PM, Endi Sukma Dewata wrote:
<br>
<blockquote type="cite">On 9/12/2016 9:35 PM, Endi Sukma
Dewata wrote:
<br>
<blockquote type="cite">On 9/9/2016 2:46 PM, Georgios
Kafataridis wrote:
<br>
<blockquote type="cite">I've tried that but still the same
result.
<br>
<br>
[root@ipa-server /]# ldapsearch -D "cn=directory
manager" -W -p 389 -h
<br>
localhost -b "uid=admin,ou=people,o=ipaca"
<br>
Enter LDAP Password:
<br>
# extended LDIF
<br>
#
<br>
# LDAPv3
<br>
# base <uid=admin,ou=people,o=ipaca> with scope
subtree
<br>
# filter: (objectclass=*)
<br>
# requesting: ALL
<br>
#
<br>
<br>
# search result
<br>
search: 2
<br>
result: 32 No such object
<br>
</blockquote>
Hi,
<br>
<br>
The master's logs indicate there's an authentication
issue.
<br>
<br>
Could you search the whole directory to find the admin
user?
<br>
$ ldapsearch ... -b "o=ipaca" "(uid=admin)"
<br>
<br>
Try also other suffixes that you have in the DS.
<br>
<br>
If you find it, try to authenticate against DS directly as
the admin
<br>
user. If the authentication fails, try resetting the
password.
<br>
</blockquote>
I believe there is actually another DS instance on CentOS
6.8 running on port
<br>
7389, so make sure you check that too. If the admin user is
indeed missing, it
<br>
will need to be recreated, assigned a password and
certificate, and added to
<br>
the appropriate groups.
<br>
<br>
See also: <a class="moz-txt-link-freetext" href="http://pki.fedoraproject.org/wiki/IPA_PKI_Users">http://pki.fedoraproject.org/wiki/IPA_PKI_Users</a>
<br>
<br>
</blockquote>
Sorry for the delay, crazy office days.
<br>
<br>
Ok, tried that and finally got a hit on the user. Indeed in
6.x you also have
<br>
7389 to look for.
<br>
<br>
*Master
<br>
<br>
*#ldapsearch -h localhost -p 7389 -b "o=ipaca" "(uid=admin)"
-x -W
<br>
Enter LDAP Password:
<br>
<br>
# extended LDIF
<br>
#
<br>
# LDAPv3
<br>
# base <o=ipaca> with scope subtree
<br>
# filter: (uid=admin)
<br>
# requesting: ALL
<br>
#
<br>
<br>
# admin, people, ipaca
<br>
dn: uid=admin,ou=people,o=ipaca
<br>
objectClass: top
<br>
objectClass: person
<br>
objectClass: organizationalPerson
<br>
objectClass: inetOrgPerson
<br>
objectClass: cmsuser
<br>
uid: admin
<br>
sn: admin
<br>
cn: admin
<br>
mail: root@localhost
<br>
usertype: adminType
<br>
userstate: 1
<br>
description: 2;6;CN=Certificate
Authority,O=NELIOS;CN=ipa-ca-agent,O=NELIOS
<br>
userCertificate::
MIIDaTCCAlGgAwIBAgIBBjANBgkqhkiG9w0BAQsFADAxMQ8wDQYDVQQKEwZO....
<br>
.
<br>
.
<br>
.
<br>
.
<br>
# search result
<br>
search: 2
<br>
result: 0 Success
<br>
<br>
# numResponses: 2
<br>
# numEntries: 1
<br>
<br>
<br>
*Replica Server*
<br>
<br>
[root@ipa2-server2 ~]# ldapsearch -h ipa-server.nelios -p 7389
-b "o=ipaca"
<br>
"(uid=admin)" -x -W
<br>
# extended LDIF
<br>
#
<br>
# LDAPv3
<br>
# base <o=ipaca> with scope subtree
<br>
# filter: (uid=admin)
<br>
# requesting: ALL
<br>
#
<br>
<br>
# admin, people, ipaca
<br>
dn: uid=admin,ou=people,o=ipaca
<br>
objectClass: top
<br>
objectClass: person
<br>
objectClass: organizationalPerson
<br>
objectClass: inetOrgPerson
<br>
objectClass: cmsuser
<br>
uid: admin
<br>
sn: admin
<br>
cn: admin
<br>
mail: root@localhost
<br>
usertype: adminType
<br>
userstate: 1
<br>
<br>
Password is valid in both cases.
<br>
<br>
So the user is there and can be retrieved from replica,
assuming that
<br>
ipa-replica-install also tries 7389 the only thing I can try
now is "ipa
<br>
cert-request --uid admin" to create a new certificate,
generate a new cacert.p12
<br>
and retry install ?
<br>
<br>
<br>
</blockquote>
In the other subthred there was a log from CentOS6 machine:
<br>
<br>
/var/log/pki-ca/system
<br>
<br>
5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [6] [6] Failed
to
<br>
authenticate as admin UID=admin. Error:
netscape.ldap.LDAPException:
<br>
error result (49)
<br>
5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [3] [3] Servlet
<br>
caGetCookie: Error getting servlet output stream when rendering
<br>
template. Error Invalid Credential..
<br>
<br>
Which to me looks like a wrong password. Which indicates my
original
<br>
theory that IPA admin user shared with CA admin user the same
password
<br>
but it got out of sync. During replica installation it uses IPA
admin
<br>
user for authenticating as PKI admin user.
<br>
<br>
If that is correct then changing PKI admin user's (
<br>
uid=admin,ou=people,o=ipaca ) password to IPA admin user's
password
<br>
might fix the issue.
<br>
<br>
</blockquote>
Thanks! Ok, I will look into that more. In any case, I'll keep you
posted.
<br>
<br>
</blockquote>
<br>
<p>I had to follow
<a class="moz-txt-link-freetext" href="https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password">https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password</a>
and do it in my master<br>
</p>
<p>and it worked at last<b> </b><b>"ipa.ipapython.install.cli.install_tool(Replica):
INFO The ipa-replica-install command was successful"!</b></p>
<div class="moz-signature"><!--Mail-->
<link
href="http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800&subset=latin,latin-ext"
rel="stylesheet" type="text/css">
</div>
</body>
</html>