Single Master Replication Authentication Issues

[Thaddeus Brown]

First, i am a noob to ldap and directory server. I have been at this for
30+ days in various scenarios to move off of directory server 8.2 to 11. In
my latest iteration I am just trying to step through the major upgrades
os/ds one at time to get to my end result.
I am trying to replicate databases from directory server 8.2 to 9. I have
followed the redhat documentation but still struggling. On the consumer, I
am getting the error message,
slapi_ldap_bind - error: could not bind id [cn=replication
manager,cn=config] mech [SIMPLE]: error 48 (inappropriate authentication)
errno 0 (Success)

I have changed the password do it wouldn't be too simple. Made sure that
supplier dn is cn=replication manager,cn=config as well as simple bind
userid. How can I check if security and what type is on supplier?

[William Brown]

>  On 20 Feb 2020, at 07:35, Thaddeus Brown
> <thadbrownsc(a)gmail.com&gt; wrote:
>  
>  First, i am a noob to ldap and directory server. 
All good, happy to have you here! 

>  I have been at this for 30+ days in various scenarios to move off of
> directory server 8.2 to 11. In my latest iteration I am just trying to step through the
> major upgrades os/ds one at time to get to my end result.
>  I am trying to replicate databases from directory server 8.2 to 9. I have followed the
> redhat documentation but still struggling. On the consumer, I am getting the error
> message, 
>  slapi_ldap_bind - error: could not bind id [cn=replication manager,cn=config] mech
> [SIMPLE]: error 48 (inappropriate authentication) errno 0 (Success)
>  
>  I have changed the password do it wouldn't be too simple. Made sure that supplier dn
> is cn=replication manager,cn=config as well as simple bind userid. How can I check if
> security and what type is on supplier? 
On the consumer, you should check the cn=replication manager,cn=config exists, and you can
do an ldapwhoami -H ldaps://consumer.ldap.example.com -D "cn=replication
manager,cn=config" -w -x 


On the supplier you need to look for the replication agreements, you can use ldapsearch -H
ldaps://supplier.ldap.example.com -D 'cn=Directory Manager' -b cn=config -x -w
'(objectClass=nsds5ReplicationAgreement)' to show these. You need to check the
bind method is SIMPLE, the bind dn is correct, and the nsds5replicacredentials is correct
password. It's also worth checking the port and hostnames too.

For replication logging you can set the error log level to 8192 in cn=config as well. 

As always, if possible create a "staging" or "development" environment
that matches your production, and try things out there too.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/9....

Hope that helps, if you have more questions, please let us know! 



>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[thierry bordaz]

On 2/19/20 10:35 PM, Thaddeus Brown wrote:
>  First, i am a noob to ldap and directory server. I have been at this
>
>  for 30+ days in various scenarios to move off of directory server 8.2 
>  to 11. In my latest iteration I am just trying to step through the 
>  major upgrades os/ds one at time to get to my end result.
>  I am trying to replicate databases from directory server 8.2 to 9. I 
>  have followed the redhat documentation but still struggling. On the 
>  consumer, I am getting the error message,
>  slapi_ldap_bind - error: could not bind id [cn=replication 
>  manager,cn=config] mech [SIMPLE]: error 48 (inappropriate 
>  authentication) errno 0 (Success) 
Hi,

the supplier fails to authenticate on the consumer. It tries to 
authenticate with 'cn=replication manager,cn=config" using simple 
authentication. Does 'cn=replication manager,cn=config" entry exist ? 
does it contain a userpassword ?

best regards
thierry
>  I have changed the password do it wouldn't be too simple. Made sure 
>  that supplier dn is cn=replication manager,cn=config as well as simple 
>  bind userid. How can I check if security and what type is on supplier?
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Thad]

Ok. Thanks William and Thierry. I took a look back at the entry in dse.ldif and somehow my
userPassword entry didn't save. I put it back and carefully put in a new complex (not
too much) password and restarted everything. It is working now so it was missing field in
the dse file and a password issue. 

Now I have and issue with replication. Specifically "Replication error acquiring
replica. replica busy error code 1."  This is in the Consumer initialization status
area. in the Status field last update message is "Replica acquired successfully.
Incremental update succeeded." This for both NetscapeRoot and userRoot.

However I think I see the issue. When setting up the replication agreement the FQDN for
the supplier is automatically given. Since both servers are named the same thing (based on
the documentation) shouldn't this cause an issue?

[Thad]

I just re-read the documentation again...like I said newbie here. It seems I put the
agreement on the consumer and I should have created it on the supplier server to push the
data to the consumer. The flow of instructions here wasn't crystal clear to me. So now
I am configuring the agreement on the the supplier. The error message I am receiving now
is "Consumer server unreachable or invalid credentials supplied. Unable to perform
subtree duplication verification." And I think have figured it out, the supplier can
reach out to consumer but the traffic isn't coming back. So going to add an entry to
the consumer /etc/hosts file and get back with the results.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/9....

[William Brown]

>  On 21 Feb 2020, at 00:28, Thad <thadbrownsc(a)gmail.com&gt; wrote:
>  
>  Ok. Thanks William and Thierry. I took a look back at the entry in dse.ldif and somehow
> my userPassword entry didn't save. I put it back and carefully put in a new complex
> (not too much) password and restarted everything. It is working now so it was missing
> field in the dse file and a password issue.  
dse.ldif is written by the server on shutdown. So you either need to ldapmodify via
cn=config while the server is running, or stop dirsrv, change dse.ldif, and the start it
again. If you make a change to dse.ldif wile the server is running, it's "blown
away" on shutdown as we write out the consistent in memory dse.ldif. That could be
why the change disappeared. 

>  
>  Now I have and issue with replication. Specifically "Replication error acquiring
> replica. replica busy error code 1."  This is in the Consumer initialization status
> area. in the Status field last update message is "Replica acquired successfully.
> Incremental update succeeded." This for both NetscapeRoot and userRoot.
>  
>  However I think I see the issue. When setting up the replication agreement the FQDN for
> the supplier is automatically given. Since both servers are named the same thing (based on
> the documentation) shouldn't this cause an issue? 
>  
>  
>  I just re-read the documentation again...like I said newbie here. It seems I put the
> agreement on the consumer and I should have created it on the supplier server to push the
> data to the consumer. The flow of instructions here wasn't crystal clear to me. So now
> I am configuring the agreement on the the supplier. The error message I am receiving now
> is "Consumer server unreachable or invalid credentials supplied. Unable to perform
> subtree duplication verification." And I think have figured it out, the supplier can
> reach out to consumer but the traffic isn't coming back. So going to add an entry to
> the consumer /etc/hosts file and get back with the results. 

I'd say look at the DS 10 and DS 11 docs. 

We did a lot of work through DS 10 and 11 with the docs and we have documented a lot more
on the lifecycles such as removal of a replica in a topology. This in mind, ds 11 has a
new CLI suite so the commands may not match what you have, so DS 10 could be better to
look at.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...


>  
>  Glad to say replication is working now. It looks like all of the entries have been
> replicated. I will keep checking for any errors. Once I got the replication agreement on
> the correct side I ran into some LDAP issues but worked through them. Not sure why the
> userPassword field on the replication manager entry kept disappearing but had to edit
> dse.ldif and enter it again. Next up is decommissioning the master server and repeating
> the whole process a few more times until I am on a current version. So pretty sure you
> will be hearing from me again if I can't find any good decommission documentation of
> master/replica setup. 

See above - you need to stop dirsrv, edit dse.ldif, then start it OR use ldapmodify on
cn=config.

Hope that helps! 

>  
>  Thanks for the help.  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Thad]

Glad to say replication is working now. It looks like all of the entries have been
replicated. I will keep checking for any errors. Once I got the replication agreement on
the correct side I ran into some LDAP issues but worked through them. Not sure why the
userPassword field on the replication manager entry kept disappearing but had to edit
dse.ldif and enter it again. Next up is decommissioning the master server and repeating
the whole process a few more times until I am on a current version. So pretty sure you
will be hearing from me again if I can't find any good decommission documentation of
master/replica setup.

Thanks for the help.