Does: Ldapsearch -y digest-md5 -U root -R tivo2 -W
Show anything diff. I havent used sasldb2 stuff in a while, however with digestmd5 when secrets are stored in the ldap dit, had to be clear text.
-----Original Message----- From: openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org [mailto:openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org] On Behalf Of lemons_terry@emc.com Sent: Monday, April 02, 2007 10:36 AM To: openldap-software@openldap.org Subject: DIGEST-MD5 returns 'user not found'
Hi
I'm trying to use DIGEST-MD5 authentication on a SLES 9 SP3 system running OpenLDAP 2.
tivo2:~ # ldapsearch SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
When I run 'ldapsearch -d 2', I see that 'username=root' and 'realm=tivo2.backup'.
I believe that I have the correct entry for 'root' in the SASL database:
sasldblistusers2 root@tivo2: userPassword
So why is SASL saying 'user not found'?
Thanks tl
Terry Lemons Backup Platforms Group EMC² where information lives 4400 Computer Drive, MS D239 Westboro MA 01580 Phone: 508 898 7312 Email: Lemons_Terry@emc.com
NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message.
Thanks, as ever, for the help, Kyle.
I started slapd in debug mode. When I executed the command you suggested, I see:
ldap_err2string <= ldap_dn2bv(uid=root,cn=digest-md5,cn=auth)=0 Success <<< dnNormalize: <uid=root,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=root,cn=digest-md5,cn=auth to a DN slap_sasl_regexp: converting SASL name uid=root,cn=digest-md5,cn=auth <==slap_sasl2dn: Converted SASL name to <nothing> SASL [conn=12] Failure: no secret in database
So, the good news is that "uid=root,cn=digest-md5,cn=auth" does look correct. But I then see "Converted SASL name to <nothing>". Here are the final lines in my /etc/openldap/slapd.conf:
# SASL options password-hash {cleartext} authz-regexp uid=(.*),cn=tivo2.backup,cn=digest-md5,cn=auth uid=tlemons authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=tlemons tivo2:~ #
I thought that the first authz-regexp line would have mapped any account to uid-tlemons, but this apparently didn't happen.
Also, when is the information in sasldb2 used? It looks to me like it isn't, and that authentication is occurring against entries that should be in the LDAP database itself?
Thanks tl
-----Original Message----- From: openldap-software-bounces+lemons_terry=emc.com@openldap.org [mailto:openldap-software-bounces+lemons_terry=emc.com@openldap.org] On Behalf Of Chapman, Kyle Sent: Monday, April 02, 2007 11:42 AM To: openldap-software@openldap.org Subject: RE: DIGEST-MD5 returns 'user not found'
Does: Ldapsearch -y digest-md5 -U root -R tivo2 -W
Show anything diff. I havent used sasldb2 stuff in a while, however with digestmd5 when secrets are stored in the ldap dit, had to be clear text.
-----Original Message----- From: openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org [mailto:openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org] On Behalf Of lemons_terry@emc.com Sent: Monday, April 02, 2007 10:36 AM To: openldap-software@openldap.org Subject: DIGEST-MD5 returns 'user not found'
Hi
I'm trying to use DIGEST-MD5 authentication on a SLES 9 SP3 system running OpenLDAP 2.
tivo2:~ # ldapsearch SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
When I run 'ldapsearch -d 2', I see that 'username=root' and 'realm=tivo2.backup'.
I believe that I have the correct entry for 'root' in the SASL database:
sasldblistusers2 root@tivo2: userPassword
So why is SASL saying 'user not found'?
Thanks tl
Terry Lemons Backup Platforms Group EMC² where information lives 4400 Computer Drive, MS D239 Westboro MA 01580 Phone: 508 898 7312 Email: Lemons_Terry@emc.com
NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message.
lemons_terry@emc.com wrote:
Thanks, as ever, for the help, Kyle.
I started slapd in debug mode. When I executed the command you suggested, I see:
ldap_err2string <= ldap_dn2bv(uid=root,cn=digest-md5,cn=auth)=0 Success <<< dnNormalize: <uid=root,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=root,cn=digest-md5,cn=auth to a DN slap_sasl_regexp: converting SASL name uid=root,cn=digest-md5,cn=auth <==slap_sasl2dn: Converted SASL name to <nothing> SASL [conn=12] Failure: no secret in database
So, the good news is that "uid=root,cn=digest-md5,cn=auth" does look correct. But I then see "Converted SASL name to <nothing>". Here are the final lines in my /etc/openldap/slapd.conf:
# SASL options password-hash {cleartext} authz-regexp uid=(.*),cn=tivo2.backup,cn=digest-md5,cn=auth uid=tlemons authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=tlemons tivo2:~ #
I thought that the first authz-regexp line would have mapped any account to uid-tlemons, but this apparently didn't happen.
Also, when is the information in sasldb2 used? It looks to me like it isn't, and that authentication is occurring against entries that should be in the LDAP database itself?
It is used as far as sasldb2 is populated as appropriate; please refer to Cyrus SASL documentation for instructions about populating it.
As soon as you get to authz-regexp mapping, credential are being looked up in the directory. Is "uid=tlemons" a valid DN in your DIT? I mean: does it resolve to an existing entry?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Thanks for the reply
It is used as far as sasldb2 is populated as appropriate; please refer to Cyrus SASL documentation for instructions about populating it.
Do you mean http://www.sendmail.org/~ca/email/cyrus/sysadmin.html? I've crawled around the CMU web site, and have Google'd , and haven't seen anything better than this. And, it refers to the older sasldb, not sasldb2.
As soon as you get to authz-regexp mapping, credential are being looked up in the directory. Is "uid=tlemons" a valid DN in your DIT? I mean: does it resolve to an existing entry?
Yes.
Thanks! tl
--On Monday, April 02, 2007 2:25 PM -0400 lemons_terry@emc.com wrote:
Thanks for the reply
It is used as far as sasldb2 is populated as appropriate; please refer to Cyrus SASL documentation for instructions about populating it.
Do you mean http://www.sendmail.org/~ca/email/cyrus/sysadmin.html? I've crawled around the CMU web site, and have Google'd , and haven't seen anything better than this. And, it refers to the older sasldb, not sasldb2.
As soon as you get to authz-regexp mapping, credential are being looked up in the directory. Is "uid=tlemons" a valid DN in your DIT? I mean: does it resolve to an existing entry?
Hm, it isn't something like:
uid=tlemons,dc=emc,dc=com
instead? You really have an entry that is:
dn: uid=tlemons
with nothing else to it?
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
lemons_terry@emc.com wrote:
Thanks, as ever, for the help, Kyle.
I started slapd in debug mode. When I executed the command you suggested, I see:
ldap_err2string <= ldap_dn2bv(uid=root,cn=digest-md5,cn=auth)=0 Success <<< dnNormalize: <uid=root,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=root,cn=digest-md5,cn=auth to a DN slap_sasl_regexp: converting SASL name uid=root,cn=digest-md5,cn=auth <==slap_sasl2dn: Converted SASL name to <nothing> SASL [conn=12] Failure: no secret in database
So, the good news is that "uid=root,cn=digest-md5,cn=auth" does look correct. But I then see "Converted SASL name to <nothing>". Here are the final lines in my /etc/openldap/slapd.conf:
# SASL options password-hash {cleartext} authz-regexp uid=(.*),cn=tivo2.backup,cn=digest-md5,cn=auth uid=tlemons authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=tlemons tivo2:~ #
I thought that the first authz-regexp line would have mapped any account to uid-tlemons, but this apparently didn't happen.
The important thing to note here is that the SASL library is omitting the realm name, which is its normal behavior when using the default realm.
Also, "uid=tlemons" is a pretty short DN. It seems to me you're missing some things, unless you happen to be using a very very small test database.
Also, when is the information in sasldb2 used? It looks to me like it isn't, and that authentication is occurring against entries that should be in the LDAP database itself?
The SASL library tries all available information sources. If there was a "root" user record in your sasldb2 file it would have been used. Since your sasldblistusers2 output shows "root@tivo2" I'd say you have the wrong realm info in your database, as that doesn't match either "root" or "root@tivo2.backup".
Thanks tl
-----Original Message----- From: openldap-software-bounces+lemons_terry=emc.com@openldap.org [mailto:openldap-software-bounces+lemons_terry=emc.com@openldap.org] On Behalf Of Chapman, Kyle Sent: Monday, April 02, 2007 11:42 AM To: openldap-software@openldap.org Subject: RE: DIGEST-MD5 returns 'user not found'
Does: Ldapsearch -y digest-md5 -U root -R tivo2 -W
Show anything diff. I havent used sasldb2 stuff in a while, however with digestmd5 when secrets are stored in the ldap dit, had to be clear text.
-----Original Message----- From: openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org [mailto:openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org] On Behalf Of lemons_terry@emc.com Sent: Monday, April 02, 2007 10:36 AM To: openldap-software@openldap.org Subject: DIGEST-MD5 returns 'user not found'
Hi
I'm trying to use DIGEST-MD5 authentication on a SLES 9 SP3 system running OpenLDAP 2.
tivo2:~ # ldapsearch SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
When I run 'ldapsearch -d 2', I see that 'username=root' and 'realm=tivo2.backup'.
I believe that I have the correct entry for 'root' in the SASL database:
sasldblistusers2 root@tivo2: userPassword
So why is SASL saying 'user not found'?
Thanks tl
Terry Lemons Backup Platforms Group EMC² where information lives 4400 Computer Drive, MS D239 Westboro MA 01580 Phone: 508 898 7312 Email: Lemons_Terry@emc.com
NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message.
Hi Howard
The SASL library tries all available information sources. If there was
a
"root" user record in your sasldb2 file it would have been used. Since your sasldblistusers2 output shows "root@tivo2" I'd say you have the wrong realm info in your database, as that doesn't match either "root" or "root@tivo2.backup".
And that was the problem. When I added "root@tivo2.backup" to the sasl database, ldapsearch worked! MANY thanks for this!
It's interesting (at least, to me) to note that I didn't need any of the authentication identity mapping entries (as described in section 11.2.4 of the "OpenLDAP Software 2.3 Administrator's Guide" to make this work (not even the "password-hash {cleartext}" entry that some resources said to add).
So what gives this SASL mechanism the authority to perform tasks via LDAP?
Thanks! tl
lemons_terry@emc.com wrote:
Hi Howard
The SASL library tries all available information sources. If there was
a
"root" user record in your sasldb2 file it would have been used. Since your sasldblistusers2 output shows "root@tivo2" I'd say you have the wrong realm info in your database, as that doesn't match either "root" or "root@tivo2.backup".
And that was the problem. When I added "root@tivo2.backup" to the sasl database, ldapsearch worked! MANY thanks for this!
It's interesting (at least, to me) to note that I didn't need any of the authentication identity mapping entries (as described in section 11.2.4 of the "OpenLDAP Software 2.3 Administrator's Guide" to make this work (not even the "password-hash {cleartext}" entry that some resources said to add).
Those config items are only needed if you intend to use entries in LDAP for the SASL authentication info, instead of sasldb. Generally, that is the best thing to do.
So what gives this SASL mechanism the authority to perform tasks via LDAP?
Authentication and authorization are two separate things. When you configure your server to support SASL, that means you want to trust SASL to authenticate users. Regardless of authentication mechanism, ACLs are used to grant authority to particular users to perform various tasks.
Thanks! tl
Thanks, Howard; I think I'm beginning to understand this.
So, the AUTHENTICATION piece is done by SASL using digest_md5, an 'external' connection to TLS, etc. But the AUTHORIZATION piece is handled by the rules defined in the access control policy section of slapd.conf, right?
Thanks tl
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Monday, April 02, 2007 3:36 PM To: Lemons, Terry Cc: Kyle_Chapman@g1.com; openldap-software@openldap.org Subject: Re: DIGEST-MD5 returns 'user not found'
lemons_terry@emc.com wrote:
Hi Howard
The SASL library tries all available information sources. If there
was
a
"root" user record in your sasldb2 file it would have been used.
Since
your sasldblistusers2 output shows "root@tivo2" I'd say you have the wrong realm info in your database, as that doesn't match either
"root"
or "root@tivo2.backup".
And that was the problem. When I added "root@tivo2.backup" to the
sasl
database, ldapsearch worked! MANY thanks for this!
It's interesting (at least, to me) to note that I didn't need any of
the
authentication identity mapping entries (as described in section
11.2.4
of the "OpenLDAP Software 2.3 Administrator's Guide" to make this work (not even the "password-hash {cleartext}" entry that some resources
said
to add).
Those config items are only needed if you intend to use entries in LDAP for the SASL authentication info, instead of sasldb. Generally, that is the best thing to do.
So what gives this SASL mechanism the authority to perform tasks via LDAP?
Authentication and authorization are two separate things. When you configure your server to support SASL, that means you want to trust SASL
to authenticate users. Regardless of authentication mechanism, ACLs are used to grant authority to particular users to perform various tasks.
Thanks! tl
lemons_terry@emc.com wrote:
Thanks, Howard; I think I'm beginning to understand this.
So, the AUTHENTICATION piece is done by SASL using digest_md5, an 'external' connection to TLS, etc. But the AUTHORIZATION piece is handled by the rules defined in the access control policy section of slapd.conf, right?
Yes, basic principles of computer security. Authentication (who are you?) is distinct from Authorization (what are you allowed to do?).
Thanks tl
openldap-software@openldap.org