[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapadd won't add entry via SASL/DIGEST-MD5
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. I am attempting
to force ldapadd into interactive mode with the -I
option. 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
SASL Interaction
Please enter your authorization name: root@localhost
Default: mail
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