[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapadd won't add entry via SASL/DIGEST-MD5
At 10:08 AM 2002-09-03, Gary C. New wrote:
>It seems that the -R option does not resolve the
>issue, either. As you can see below, I have the
>rootdn setup to reflect a SASL uid.
Not relevant to authentication. (Relevant to access
control, but you haven't gotten that far yet.)
>I am attempting
>to force ldapadd into interactive mode with the -I
>option.
First, get explicit arguments working. -I, especially
with ldap.conf(5)/.ldaprc, can cause some confusion.
>I then enter the author and authen names as I
>did successfully with the SASL sample client and
>server, but then get the user/secret not found error.
>It still seems as if the default realm is not being
>changed to localhost.
>
>slapd.conf
>rootdn "uid=root@localhost"
>
>ldapadd -U root -R localhost -I -f
>/home/openldap/mail.ldif -d -1
Try:
ldapadd -Y DIGEST-MD5 -U root -R localhost -f /home/openldap.ldif -d -1
Note: no authzid (-X)... that is, no proxy authorization.
>SASL Interaction
>Please enter your authorization name: root@localhost
>Default: mail
You actually want the authorization name to be empty.
Do you setting LDAP defaults in .ldaprc or environment?
>Please enter your authentication name: root@localhost
>Please enter your password:
>
>*SNIP*
> 0000: 30 82 01 3b 02 01 03 60 82 01 34 02 01 03 04
>00 0..;...`..4.....
> 0010: a3 82 01 2b 04 0a 44 49 47 45 53 54 2d 4d 44
>35 ...+..DIGEST-MD5
> 0020: 04 82 01 1b 75 73 65 72 6e 61 6d 65 3d 22 72
>6f ....username="ro
> 0030: 6f 74 40 6c 6f 63 61 6c 68 6f 73 74 22 2c 72
>65 ot@localhost",re
> 0040: 61 6c 6d 3d 22 67 6e 75 6d 61 69 6c 34 39 2e
>67 alm="mail.t
> 0050: 6e 75 6d 61 69 6c 2e 6f 72 67 22 2c 6e 6f 6e
>63 est.org",nonc
> 0060: 65 3d 22 70 33 74 70 68 67 4c 75 59 66 64 42
>56 e="p3tphgLuYfdBV
> 0070: 39 6c 31 6c 61 58 6f 43 2f 4e 50 49 65 49 2f
>4c 9l1laXoC/NPIeI/L
> 0080: 33 6b 2b 41 7a 49 55 46 79 66 6f 6e 39 6b 3d
>22 3k+AzIUFyfon9k="
> 0090: 2c 63 6e 6f 6e 63 65 3d 22 70 2f 62 64 56 6d
>4d ,cnonce="p/bdVmM
> 00a0: 51 56 6a 4e 4c 75 4d 75 7a 45 75 4d 76 31 74
>64 QVjNLuMuzEuMv1td
> 00b0: 46 32 69 47 6e 44 71 6f 56 61 72 33 6b 44 56
>58 F2iGnDqoVar3kDVX
> 00c0: 39 70 35 4d 3d 22 2c 6e 63 3d 30 30 30 30 30
>30 9p5M=",nc=000000
> 00d0: 30 31 2c 71 6f 70 3d 61 75 74 68 2d 63 6f 6e
>66 01,qop=auth-conf
> 00e0: 2c 63 69 70 68 65 72 3d 22 72 63 34 22 2c 64
>69 ,cipher="rc4",di
> 00f0: 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 70 2f
>67 gest-uri="ldap/m
> 0100: 6e 75 6d 61 69 6c 34 39 2e 67 6e 75 6d 61 69
>6c ail.test
> 0110: 2e 6f 72 67 22 2c 72 65 73 70 6f 6e 73 65 3d
>32 .org",response=2
> 0120: 31 33 66 64 39 38 61 34 36 66 39 66 36 31 31
>64 13fd98a46f9f611d
> 0130: 33 65 35 65 66 61 32 66 32 30 33 38 33 36 36
> 3e5efa2f2038366
>*SNIP*
>
>ldap_sasl_interactive_bind_s: Internal (implementation
>specific) error (80)
> additional info: SASL(-13): user not found: no secret
>in database
>
>Might I have the slapd.conf configured incorrectly? I
>don't understand why SASL author and authen work with
>the sample client and server, but not with ldapadd.
>The only explanation I can come to is the realm issue.
>
>I appreciate your input and assistance.
>
>Respectfully,
>
>
>Gary
>
>
>--- Howard Chu <hyc@symas.com> wrote:
>> > -----Original Message-----
>> > From: owner-openldap-software@OpenLDAP.org
>> > [mailto:owner-openldap-software@OpenLDAP.org]On
>> Behalf Of Gary C. New
>>
>> > I decided to open up the verboseness of ldapadd
>> and
>> > believe I've discovered what the fundamental
>> problem
>> > may be. It seems that ldapadd is trying to
>> > authenticate against the server's FQDN as the
>> realm,
>> > which is not associated with any of the users in
>> the
>> > sasldb. I tried specifying the authcid (-U) and
>> > authzid (-X) (i.e., root@localhost), but could
>> never
>> > get ldapadd to supply the correct realm
>> information.
>> > I am able to add ldap entries using simple
>> > authentication, but still no sasl.
>> >
>> > Any idea how I might be able to force ldapadd to
>> use
>> > the user specific realm information (i.e.,
>> localhost)?
>>
>> ldapadd -U root -R localhost
>>
>> Apparently the -R flag was omitted from the man
>> pages but it is listed in the
>> "usage" information for all of the commandline
>> tools.
>>
>> It's unfortunate that this problem occurs. The SASL
>> documentation specifies
>> that the default realm is the FQDN of the server,
>> but the Cyrus code doesn't
>> actually implement this specification, while
>> OpenLDAP does. The Cyrus code
>> takes whatever it gets from gethostname() which may
>> or may not be fully
>> qualified, and usually isn't. The OpenLDAP code uses
>> gethostbyname() to
>> retrieve the FQDN of the host, which is the
>> correct/standard method of
>> retrieving FQDNs. So, the Cyrus tools (like
>> saslpasswd) generate password
>> entries with incomplete realm specifiers by default,
>> and these specifiers
>> don't work (by default) with any software that
>> actually follows the SASL
>> docs. You can tell saslpasswd to use a specific
>> realm with the "-u" option
>> when setting the password.
>>
>> -- Howard Chu
>> Chief Architect, Symas Corp. Director,
>> Highland Sun
>> http://www.symas.com
>> http://highlandsun.com/hyc
>> Symas: Premier OpenSource Development and Support
>>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com