Did you define the env variable $BASEDN before doing the ldapsearch? You
need to set it to the same value as basedn=.. in /etc/ipa/default.conf,
for instance:
export BASEDN=dc=domain,dc=com
flo
> On 19 Feb 2019, at 12:05, François Cami <fcami(a)redhat.com
> <mailto:fcami@redhat.com>> wrote:
>
> On Tue, Feb 19, 2019 at 11:02 AM Peter Zoltan Keresztes via
> FreeIPA-users <freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>
>> I have tried but I am getting the following
>>
>> root@vmfripa-1c:~# ldapsearch -D cn=directory\ manager -w Secret123
>> -b cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,$BASEDN -h
>> localhost -p 389 -LLL -o ldif-wrap=no
>> ldap_bind: Invalid credentials (49)
>
> This indicates that your directory manager password is not Secret123.
>
>>> On 19 Feb 2019, at 11:56, Florence Blanc-Renaud <flo(a)redhat.com
>>> <mailto:flo@redhat.com>> wrote:
>>>
>>> On 2/19/19 8:51 AM, Peter Zoltan Keresztes via FreeIPA-users wrote:
>>>> Yes, I have installed the node using ipa-client-install then I have
>>>> executed spa-replica-install. Not sure if it has anything to do the
>>>> other two nodes are using 4.3.1 while the new node is using 4.7.0
>>>> all running on ubuntu. I did not provide any option to the
>>>> ipa-replica-install. It has only asked me for the admin password.
>>>> Regards,
>>>> Peter
>>>>> On 19 Feb 2019, at 09:42, Florence Blanc-Renaud <flo(a)redhat.com
>>>>> <mailto:flo@redhat.com> <mailto:flo@redhat.com>>
wrote:
>>>>>
>>>>> I would like to reproduce your issue and need the full steps that
>>>>> you followed. Did you first install the node as a client with
>>>>> ipa-client-install then promote to replica with
>>>>> ipa-replica-install, or did you use a single step with
>>>>> ipa-replica-install? Which options did you provide to
>>>>> ipa-replica-install, or which answers did you provide in
>>>>> interactive mode?
>>>> _______________________________________________
>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>> To unsubscribe send an email to
>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
>>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>> Hi,
>>>
>>> can you check on your master if there is an entry
>>> cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,$BASEDN and
>>> cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,$BASEDN?
>>>
>>> $ ldapsearch -D cn=directory\ manager -w Secret123 -b
>>> cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,$BASEDN -h localhost -p
>>> 389 -LLL -o ldif-wrap=no
>>> should return one entry
>>> $ ldapsearch -D cn=directory\ manager -w Secret123 -b
>>> cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,$BASEDN -h
>>> localhost -p 389 -LLL -o ldif-wrap=no
>>>
>>> If the entry is missing, this is the root cause (but I have no idea
>>> how it got removed).
>>>
>>> If the entry is present, we need to check why the replica didn't
>>> find it. On the replica, have a look at the 389-ds access logs in
>>> /var/log/dirsrv/slapd-DOMAIN/access. The goal is to find which user
>>> is performing the search during the replica install:
>>> - Look for a SRCH op with
>>> base="cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,...", note the
>>> value for conn=<x> and op=<y>:
>>> [...] conn=2 op=10 SRCH
>>> base="cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=domain,dc=com"
>>> scope=0 filter="(objectClass=*)" attrs="memberPrincipal"
>>>
>>> - Look for the SEARCH RESULT, it will be in a line containing
>>> conn=<x> op=<y> RESULT. You should see something like:
>>> [...] conn=2 op=10 RESULT err=0 tag=101 nentries=1 etime=0.1369466833
>>> In my case nentries=1, meaning that the entry was found and err=0
>>> for success. In your case it will probably be different.
>>>
>>> - Then look for a line with conn=<same value> and BIND that will be
>>> present before the SEARCH. In my case:
>>> [...] conn=2 op=0 BIND dn="cn=Directory Manager" method=128
version=3
>>> which means that the op was done as Directory Manager. Is it the
>>> same in your case?
>>>
>>> flo
>> _______________________________________________
>> FreeIPA-users mailing list --freeipa-users(a)lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> To unsubscribe send an email
>> tofreeipa-users-leave(a)lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> Fedora Code of
Conduct:https://getfedora.org/code-of-conduct.html
>> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
>>
Archives:https://lists.fedorahosted.org/archives/list/freeipa-users@lists...
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...