[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapadd won't add entry via SASL/DIGEST-MD5
Below is my SASL sample client/server test, which was
successful.
# ./server -s ldap
trying 10, 1, 6
socket: Address family not supported by protocol
trying 2, 1, 6
# ./client -s ldap localhost
receiving capability list... recv: {41}
LOGIN ANONYMOUS PLAIN DIGEST-MD5 CRAM-MD5
LOGIN ANONYMOUS PLAIN DIGEST-MD5 CRAM-MD5
send: {10}
DIGEST-MD5
send: {1}
N
recv: {114}
nonce="jBe4H+QWKMUq9adb6lSoV5rZ8Cczm3/ufrCfB8DCw/k=",realm="gnumail49",qop="auth",charset=utf-8,algorithm=md5-sess
please enter an authentication id: root@localhost
please enter an authorization id: root@localhost
Password:
send: {241}
username="root@localhost",realm="mail",nonce="jBe4H+QWKMUq9adb6lSoV5rZ8Cczm3/ufrCfB8DCw/k=",cnonce="/p1bRmNHIKo8J1YpebPM8xV986OFosmMR5XHgbp6LMo=",nc=00000001,qop=auth,digest-uri="ldap/localhost",response=dce4d0d5ced400f0484b1c13a0003762
recv: {40}
rspauth=d66451a5d583c62a0ab162879e1cda3f
send: {0}
successful authentication
closing connection
I also tried the latest ldapadd syntax you suggested
to me (below) and I still get the same error message.
The ldapadd debug (-d -1) messages still point to the
realm being supplied incorrectly. When I supply the
"-R localhost" option with ldapadd, the realm
continues to be passed as my hostname "mail."
ldapadd -Y DIGEST-MD5 -U root -R localhost -f
/home/openldap/sample.ldif
Any other ideas as to what might be causing the "user
not found: no secret in database" error?
Respectfully,
Gary
--- "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:
> 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
>
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com