Need help determining cause of login problem

[Jürgen Starek]

Hello everyone,

I am having trouble with authenticating users listed in an LDAP directory.

On my network, I set up an LDAP server and a client that tries to
authenticate using the server. Both machines run Debian Etch.

Client and Server setup are done according to tutorials on the net, and
where they contradicted themselves, O'Reilly's "LDAP System
Administration".

I have populated the database with a "users" group and a sample
posixAccount. The server works fine: I can connect to it from the client
using GQ and a simple bind for the rootdn. Also, calling ldapsearch -x
on the
client gives me the complete list of entries in the server's database.

A "getent passwd" on the client shows my sample account on the LDAP
directory
as if it were in the local passwd file, just as it's supposed to do.

However, I can't log in. My nsswitch.conf uses LDAP as a password data
source, and I see network traffic at each login attempt. Passwords are
stored as an MD5 hash in the LDAP database, but trying CRYPT or PLAIN
did not change anything. As mentioned above, binding to the server using
rootdn works fine. Only binding as a user does not seem to work...

Here's a log extract from /var/log/auth.log:

testbox login[3850]: pam_ldap: ldap_search_s No such object
testbox login[3850]: pam_ldap: ldap_search_s No such object
testbox login[3850]: (pam_unix) authentication failure; logname= uid=0
euid=0
                      tty=pts/0 ruser= rhost=  user=testuser
testbox login[3850]: FAILED LOGIN (1) auf "pts/0" FOR `testuser',
                      Authentication failure


Can anyone help me diagnose this problem further? Any help would be
appreciated.

Regards,

   Jürgen

[Tony Earnshaw-4]

Jürgen Starek skrev, on 16-02-2008 10:25:

> I am having trouble with authenticating users listed in an LDAP directory.
>
> On my network, I set up an LDAP server and a client that tries to
> authenticate using the server. Both machines run Debian Etch.
>
> Client and Server setup are done according to tutorials on the net, and
> where they contradicted themselves, O'Reilly's "LDAP System
> Administration".
>
> I have populated the database with a "users" group and a sample
> posixAccount. The server works fine: I can connect to it from the client
> using GQ and a simple bind for the rootdn. Also, calling ldapsearch -x
> on the
> client gives me the complete list of entries in the server's database.
>
> A "getent passwd" on the client shows my sample account on the LDAP
> directory
> as if it were in the local passwd file, just as it's supposed to do.
>
> However, I can't log in. My nsswitch.conf uses LDAP as a password data
> source, and I see network traffic at each login attempt. Passwords are
> stored as an MD5 hash in the LDAP database, but trying CRYPT or PLAIN
> did not change anything. As mentioned above, binding to the server using
> rootdn works fine. Only binding as a user does not seem to work...
>
> Here's a log extract from /var/log/auth.log:
>
> testbox login[3850]: pam_ldap: ldap_search_s No such object
> testbox login[3850]: pam_ldap: ldap_search_s No such object
> testbox login[3850]: (pam_unix) authentication failure; logname= uid=0
> euid=0
>                      tty=pts/0 ruser= rhost=  user=testuser
> testbox login[3850]: FAILED LOGIN (1) auf "pts/0" FOR `testuser',
>                      Authentication failure
>
>
> Can anyone help me diagnose this problem further? Any help would be
> appreciated.

 From what you describe above it'd seem you've got most simple bind
stuff working ok for OpenLDAP, as well as name service switch stuff for
nss_ldap. I'm a Red Hat person, not Debian; be that as it may, you need
a configuration file for pam_ldap. Googling tells me that for Debian
this should be /etc/pam_ldap.conf.

This in your log: "ldap_search_s No such object" (aka error 32) means it
can't find the directory suffix c.q. search base, which should be
configured (with a lot more things) in said pam_ldap.conf.

Again Googling, here's how Michael Hammer does it:

http://tugll.tugraz.at/88684/weblog/3682.html

Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Jürgen Starek]

Am Samstag, 16. Februar 2008 14:17:37 schrieb Tony Earnshaw:

> This in your log: "ldap_search_s No such object" (aka error 32) means it
> can't find the directory suffix c.q. search base, which should be
> configured (with a lot more things) in said pam_ldap.conf.

Thanks for the hint! That pointed me to a typing error in /etc/pam_ldap.conf
which caused pam_ldap to check a wrong search base...

Is there a list available anywhere that gives possible reasons for error
messages? Without your mail, I would not have guessed that sending pam_ldap
to look in a non-existing search base might lead to "No such object", "No
such search base" might have been more appropriate as the object /is/ in the
directory, albeit with a different dn...

> Again Googling, here's how Michael Hammer does it:
>
> http://tugll.tugraz.at/88684/weblog/3682.html

Well, I'm truly grateful for each tutorial or howto anyone puts on the web. I
just wish they'd explain the meaning of options used and some alternatives...
(Yes, I'll go and improve the howto on the Debian wiki once this is done.
Promise.)

Regards,

  Jürgen

[Tony Earnshaw-4]

Jürgen Starek skrev, on 16-02-2008 18:04:

> Is there a list available anywhere that gives possible reasons for error
> messages?

Apparently not, as far as OpenLDAP is concerned. This was "up" as late
as today in one of the 2/4 official OpenLDAP lists, with Pier-Angelo
Masarati asking Gavin Henry if he couldn't do anything about it.

As far as I'm concerned, recognizing these error numbers at OL log level
Stats level has been an ever-increasingly important factor as LDAP
continues to mean more and more to my sites. No where to go to get
values, just recognize. The importance has been highlighted by Red Hat
itself, who permits itself to charge US$ 15.000 per annum support for
each OL or RHDS master server installation and about the half for each
slave. If I charged the half for both, I'd long have had more money than
I do have.

> Without your mail, I would not have guessed that sending pam_ldap
> to look in a non-existing search base might lead to "No such object", "No
> such search base" might have been more appropriate as the object /is/ in the
> directory, albeit with a different dn...

That's what error 32 is about. Invariably it comes from people trying to
do things to a database/directory suffix that hasn't itself yet been
initiated.

>> Again Googling, here's how Michael Hammer does it:
>>
>> http://tugll.tugraz.at/88684/weblog/3682.html
>
> Well, I'm truly grateful for each tutorial or howto anyone puts on the web.

Watch out. People stuff the word HOWTO into everything, most often don't
date what they write and, most importantly, most of what they write is
trash anyway. I wouldn't have passed Michael Hammer's writeup to you if
I hadn't vetted it myself first and found it kosher.

> I
> just wish they'd explain the meaning of options used and some alternatives...
> (Yes, I'll go and improve the howto on the Debian wiki once this is done.
> Promise.)

*NEVER, NEVER* attempt to write any "HOWTO" about anything. A good
example is sexual seduction. *DO NOT*. Simply explain what worked for
you, and *ALWAYS* write the date and all software versions. *ALWAYS* the
best source of information is the software vendor's documentation and if
this doesn't suffice, your quarrel is with the vendor himself, not the
end user.

Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Howard Chu]

Tony Earnshaw wrote:
> Jürgen Starek skrev, on 16-02-2008 18:04:
>
>> Is there a list available anywhere that gives possible reasons for error
>> messages?
>
> Apparently not, as far as OpenLDAP is concerned.

Not quite. LDAP error codes are already documented in RFC4511.

> This was "up" as late
> as today in one of the 2/4 official OpenLDAP lists, with Pier-Angelo
> Masarati asking Gavin Henry if he couldn't do anything about it.

The question Pierangelo and Gavin were addressing was whether the specific
format of OpenLDAP log messages was explicitly documented anywhere. The answer
to that is no, and we occasionally reformat the log messages to make them more
uniform and perform other cleanups over time.
>
> As far as I'm concerned, recognizing these error numbers at OL log level
> Stats level has been an ever-increasingly important factor as LDAP
> continues to mean more and more to my sites. No where to go to get
> values, just recognize.

That is far overstating the situation. All of the relevant codes are already
documented in the LDAP RFCs.

> The importance has been highlighted by Red Hat
> itself, who permits itself to charge US$ 15.000 per annum support for
> each OL or RHDS master server installation and about the half for each
> slave. If I charged the half for both, I'd long have had more money than
> I do have.

Red Hat's practices are far from exemplary.

>> Without your mail, I would not have guessed that sending pam_ldap
>> to look in a non-existing search base might lead to "No such object", "No
>> such search base" might have been more appropriate as the object /is/ in the
>> directory, albeit with a different dn...
>
> That's what error 32 is about. Invariably it comes from people trying to
> do things to a database/directory suffix that hasn't itself yet been
> initiated.
>
>>> Again Googling, here's how Michael Hammer does it:
>>>
>>> http://tugll.tugraz.at/88684/weblog/3682.html
>> Well, I'm truly grateful for each tutorial or howto anyone puts on the web.
>
> Watch out. People stuff the word HOWTO into everything, most often don't
> date what they write and, most importantly, most of what they write is
> trash anyway. I wouldn't have passed Michael Hammer's writeup to you if
> I hadn't vetted it myself first and found it kosher.
>
>> I
>> just wish they'd explain the meaning of options used and some alternatives...
>> (Yes, I'll go and improve the howto on the Debian wiki once this is done.
>> Promise.)
>
> *NEVER, NEVER* attempt to write any "HOWTO" about anything. A good
> example is sexual seduction. *DO NOT*. Simply explain what worked for
> you, and *ALWAYS* write the date and all software versions. *ALWAYS* the
> best source of information is the software vendor's documentation and if
> this doesn't suffice, your quarrel is with the vendor himself, not the
> end user.

--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

[Tony Earnshaw-4]

Howard Chu skrev, on 17-02-2008 02:06:

>>> Is there a list available anywhere that gives possible reasons for error
>>> messages?
>>
>> Apparently not, as far as OpenLDAP is concerned.
>
> Not quite. LDAP error codes are already documented in RFC4511.

Ah. Well, this gives a subset (granted including 32) ... it's debatable
whether 97, 101, 103 are status codes or error codes - where are they?

1027 [tonni:tru.leerlingen] /usr/share/doc/openldap2.4-doc-2.4.7/rfc $
grep 103 *  <
rfc2247.txt:       STD 13, RFC 1034, November 1987.
rfc3088.txt:   LDAP directory services to leverage the existing DNS
[RFC1034]
rfc3088.txt:   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and
Facilities",
rfc3088.txt:              STD 13, RFC 1034, November 1987.
rfc4517.txt:         199412161032Z
rfc4518.txt:         0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
rfc4519.txt:   [RFC1034][RFC2181] naming a host [RFC1123].  That is, a
value of this
rfc4519.txt:   [RFC1034]  Mockapetris, P., "Domain names - concepts and
facilities",
rfc4519.txt:              STD 13, RFC 1034, November 1987.
rfc4524.txt:   The 'associatedDomain' attribute specifies DNS
[RFC1034][RFC2181]
rfc4524.txt:   organizational DIT associated with a DNS domain
[RFC1034][RFC2181].
rfc4524.txt:   [RFC1034]     Mockapetris, P., "Domain names - concepts and
rfc4524.txt:                 facilities", STD 13, RFC 1034, November 1987.

Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Howard Chu]

Tony Earnshaw wrote:
> Howard Chu skrev, on 17-02-2008 02:06:
>
>>>> Is there a list available anywhere that gives possible reasons for error
>>>> messages?
>>> Apparently not, as far as OpenLDAP is concerned.
>> Not quite. LDAP error codes are already documented in RFC4511.
>
> Ah. Well, this gives a subset (granted including 32) ... it's debatable
> whether 97, 101, 103 are status codes or error codes - where are they?

"tag=97" is not an error code or a status code. It is a message type tag. Look
in ldap.h for an overview of tag bits and definitions of all the tags used in
LDAP. They're defined in hex in ldap.h, which is why grepping for 97 won't
show it to you. 97 = 0x61, which is a Bind response. You won't find "97" in
the RFC either, instead you find the ASN.1:

         BindResponse ::= [APPLICATION 1] SEQUENCE {
              COMPONENTS OF LDAPResult,
              serverSaslCreds    [7] OCTET STRING OPTIONAL }

To really understand the correspondence you need to understand how ASN.1 is
encoded in BER. The "APPLICATION" corresponds to a specific bit (0x40). The
value "1" is simply OR'd in, yielding 0x41. The entity is a structure, not a
simple value, so it gets the Constructed bit, yielding 0x61.

I've often thought that these tags should be logged in hex instead of decimal.
Perhaps it's worth an ITS.

> 1027 [tonni:tru.leerlingen] /usr/share/doc/openldap2.4-doc-2.4.7/rfc $
> grep 103 *<

--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

[Tony Earnshaw-4]

Howard Chu skrev, on 17-02-2008 19:07:

[...]

>> Ah. Well, this gives a subset (granted including 32) ... it's debatable
>> whether 97, 101, 103 are status codes or error codes - where are they?
>
> "tag=97" is not an error code or a status code. It is a message type
> tag. Look in ldap.h for an overview of tag bits and definitions of all
> the tags used in LDAP. They're defined in hex in ldap.h, which is why
> grepping for 97 won't show it to you. 97 = 0x61, which is a Bind
> response. You won't find "97" in the RFC either, instead you find the
> ASN.1:
>
>         BindResponse ::= [APPLICATION 1] SEQUENCE {
>              COMPONENTS OF LDAPResult,
>              serverSaslCreds    [7] OCTET STRING OPTIONAL }
>
> To really understand the correspondence you need to understand how ASN.1
> is encoded in BER. The "APPLICATION" corresponds to a specific bit
> (0x40). The value "1" is simply OR'd in, yielding 0x41. The entity is a
> structure, not a simple value, so it gets the Constructed bit, yielding
> 0x61.
>
> I've often thought that these tags should be logged in hex instead of
> decimal. Perhaps it's worth an ITS.

Thanks a lot for all of this, Howard - much appreciated. I trust that OP
also feels the same.

Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Howard Chu]

Tony Earnshaw wrote:
> Howard Chu skrev, on 17-02-2008 19:07:
>> I've often thought that these tags should be logged in hex instead of
>> decimal. Perhaps it's worth an ITS.
>
> Thanks a lot for all of this, Howard - much appreciated. I trust that OP
> also feels the same.

Sure. Just remember, we're not making any of this stuff up, it's all standard
values defined by the RFC. As we've said many times before - it's not the
OpenLDAP Project's job to teach you the basics of LDAP; you're supposed to
know them already. You're supposed to know what's in the RFCs. We won't
duplicate the RFC content in our documentation, that's a waste of effort. Our
documentation's purpose is only to tell you how we've mapped LDAP into our code.

--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/