7:39 p.m.
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(a)panix.com http://www.panix.com/~kylet
---------------------------------------------
1:21 a.m.
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(a)uaznia.net
7:28 a.m.
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(a)panix.com http://www.panix.com/~kylet
---------------------------------------------
7:41 a.m.
> > 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(a)panix.com http://www.panix.com/~kylet
---------------------------------------------
7:58 a.m.
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(a)panix.com http://www.panix.com/~kylet
---------------------------------------------
10:55 a.m.
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.
11:57 a.m.
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(a)panix.com http://www.panix.com/~kylet
---------------------------------------------
6359
days inactive
6361
days old
389-users@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Kyle Tucker -
Michał Droździewicz -
Rich Megginson