[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