Fedora directory users - Nov 2006 - Replication credentials issue

Hi all,
	I''ve been all day trying to get simple single master 
to one consumer going on a pair of 1.0.4 FDS systems and I 
can''t get past the authentication credentials. I''ve gone over 
this 20 times today from scratch, and it won''t go. I''ve even
redone my procedures on my test boxes and they work fine.
Both the replication wizard and the consumer initialization
fail (if I force the wizard to accept and go on). There is
no firewall issue and tcpdump and ldapsearch gets to the 
consumer machine. Consumer is RHEL 4. Here''s my LDIF''s I
used. Can I use ldapsearch to test binding to this netry
to try an debug what''s up? On an aside, the Redhat/Fedora
documents for adding this entry are very vague and don''t
have any information about most of these attributes. It
didn''t appear one could even get this working *without*
using LDIF files. Anyway, any help would be great. Thanks.

dn: cn=replica, cn="dc=acme,dc=com", cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
cn: replica
nsDS5ReplicaBindDN: cn=Replication Manager, cn=config
nsDS5ReplicaRoot: dc=acme,dc=com
nsDS5Flags: 0
nsDS5ReplicaType: 2
nsDS5ReplicaId: 1

dn: cn=Replication Manager, cn=config
changetype: add
cn: Replication Manager
sn: replication
objectClass: top
objectClass: person
userPassword: xxxxx


-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

Kyle Tucker, dnia 2006-11-25 02:39 napisal:
> dn: cn=Replication Manager, cn=config
> changetype: add
> cn: Replication Manager
> sn: replication
> objectClass: top
> objectClass: person
> userPassword: xxxxx
''userPassword'' field should be clear text. So considering that
you
entered ''xxxxx'' in this example, in the wizard you should
provide
''xxxxx'' as a password. Easiest way to do it: stop your
replica, edit
dse.ldif (can be found in ./slapd-hostname/config/) and type password in
there in the userPassword. Start replica and run replication agreement
wizard on the master. Initialization should go on without any problems.

-- 
email/xmpp: koniczynek@uaznia.net

> Kyle Tucker, dnia 2006-11-25 02:39 napisal:
> > dn: cn=Replication Manager, cn=config
> > changetype: add
> > cn: Replication Manager
> > sn: replication
> > objectClass: top
> > objectClass: person
> > userPassword: xxxxx
> ''userPassword'' field should be clear text. So considering
that you
> entered ''xxxxx'' in this example, in the wizard you should
provide
> ''xxxxx'' as a password. Easiest way to do it: stop your
replica, edit
> dse.ldif (can be found in ./slapd-hostname/config/) and type password in
> there in the userPassword. Start replica and run replication agreement
> wizard on the master. Initialization should go on without any problems.
I put xxxxx in this just as an example. Oddly, on my working test 
servers (1.0.3 on FC5), I used a {SSHA} password in my LDIF and it
worked without a hitch all 3 times I''ve set replication there. I 
did put in clear text in the non-working production sets. If it''s
of any help, here''s the entries in the access logs, although
I''d
guess there''s nothing revelational here.

[24/Nov/2006:17:26:56 -0800] conn=23 fd=64 slot=64 connection from 10.1.100.186
to 10.1.109.203
[24/Nov/2006:17:26:56 -0800] conn=23 op=0 BIND dn="cn=Replication
Manager,cn=config" method=128 version=3
[24/Nov/2006:17:26:56 -0800] conn=23 op=0 RESULT err=49 tag=97 nentries=0
etime=0
[24/Nov/2006:17:26:56 -0800] conn=23 op=1 UNBIND
[24/Nov/2006:17:26:56 -0800] conn=23 op=1 fd=64 closed - U1


-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

> > > userPassword: xxxxx
> > ''userPassword'' field should be clear text. So
considering that you
> > entered ''xxxxx'' in this example, in the wizard you
should provide
> > ''xxxxx'' as a password. Easiest way to do it: stop
your replica, edit
> > dse.ldif (can be found in ./slapd-hostname/config/) and type password
in
> > there in the userPassword. Start replica and run replication agreement
> > wizard on the master. Initialization should go on without any
problems.
I stopped the service, edited the password in clear in userPassword
field, reinput the password on the master and same errors. The error
from the initialize consumer action is:

The consumer initialization has unsuccessfully completed.
The error received by the replica is: ''49 - LDAP error: Invalid
credentials''.

Corresponding log entry is the same:

[25/Nov/2006:05:37:17 -0800] conn=1 op=0 BIND dn="cn=Replication
Manager,cn=config" method=128 version=3
[25/Nov/2006:05:37:17 -0800] conn=1 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[25/Nov/2006:05:37:17 -0800] conn=1 op=1 UNBIND
[25/Nov/2006:05:37:17 -0800] conn=1 op=1 fd=64 closed - U1

So how to debug this is the next step it seems. Thanks.

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

> I stopped the service, edited the password in clear in userPassword
> field, reinput the password on the master and same errors. The error
> from the initialize consumer action is:
For grins, I stopped the master as well, edited its dse.ldif and
changed it to clear (it was in DES method) and voila - it all took
off and synched up. I checked my working test master and consumer
and they were in DES and SSHA respectively, again always working
from the onset. I''ll leave it to the developers to take anything from
this. Thanks for the pointer to dse.ldif.

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

Kyle Tucker wrote:
>> I stopped the service, edited the password in clear in userPassword
>> field, reinput the password on the master and same errors. The error
>> from the initialize consumer action is:
>>     
>
> For grins, I stopped the master as well, edited its dse.ldif and
> changed it to clear (it was in DES method) and voila - it all took
> off and synched up. I checked my working test master and consumer
> and they were in DES and SSHA respectively, again always working
> from the onset. I''ll leave it to the developers to take anything
from
> this. Thanks for the pointer to dse.ldif.
>   
The consumer should have the cn=Repl Manager user with userPassword as 
an SSHA hash (or some other secure hash), not cleartext.  The supplier 
should store the repl manager credentials with the {DES} reversible 
password encryption type so that it can send the clear text password to 
the consumer in the BIND request (as is done in the normal LDAP simple 
BIND request).  You can always test this by using the ldapsearch command 
line tool to attempt to bind using -D "cn=replication
manager,cn=config"
and the password to the consumer to test the bind and credentials.

> Kyle Tucker wrote:
> >> I stopped the service, edited the password in clear in
userPassword
> >> field, reinput the password on the master and same errors. The
error
> >> from the initialize consumer action is:
> >>     
> >
> > For grins, I stopped the master as well, edited its dse.ldif and
> > changed it to clear (it was in DES method) and voila - it all took
> > off and synched up. I checked my working test master and consumer
> > and they were in DES and SSHA respectively, again always working
> > from the onset. I''ll leave it to the developers to take
anything from
> > this. Thanks for the pointer to dse.ldif.
> >   
> The consumer should have the cn=Repl Manager user with userPassword as 
> an SSHA hash (or some other secure hash), not cleartext.  The supplier 
> should store the repl manager credentials with the {DES} reversible 
> password encryption type so that it can send the clear text password to 
> the consumer in the BIND request (as is done in the normal LDAP simple 
> BIND request).  You can always test this by using the ldapsearch command 
> line tool to attempt to bind using -D "cn=replication
manager,cn=config"
> and the password to the consumer to test the bind and credentials.
Yes, but it wouldn''t work in this configuration using DES->SSHA with
1.0.4
on RHEL, whereas it did in several tests on 1.0.3 on FC5. It wouldn''t
even
work DES->clear. I did not try clear->SSHA. I have to set up 2 more
consumers,
so I will try all possible combinations when I do those and follow up.

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------