[Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets)

[Howard Chu]

> Date: Wed, 21 Feb 2007 09:34:03 -0700
 > From: Richard Megginson <rmeggins at redhat.com>
>> Andrew Bartlett wrote:
>> > On Tue, 2007-02-20 at 17:07 -0800, Howard Chu wrote:

>>> >> I'd be a little concerned about this "auto bind". In OpenLDAP the credentials 
>>> >> are only used if a SASL/EXTERNAL Bind is performed. In general I think it's 
>>> >> poor policy to do something "magic" without a user actually requesting it. 
>>> >> Especially where security is involved. Granted, a user could explicitly 
>>> >> perform a Bind if they need to override the auto bind, but that's not the 
>>> >> point. In typical LDAP use a session is anonymous until an explicit Bind has 
>>> >> succeeded. IMO this behavior should be true regardless of the type of URL 
>>> >> being used. E.g., with OpenLDAP right now, we can interchange ldap://, 
>>> >> ldaps://, and ldapi:// URLs at will and apps see consistent behavior.

>> > I agree.  Autobinding is a bad idea, as even for Samba I want that
>> > consistency:  we run as root, but unless I start passing credentials,
>> > I'm expecting the DB to be giving me anonymous access.

> Is it possible that in some cases you would want the DS to use the OS 
> credentials?  In a sense, when I login to the OS with my 
> username/password or other credentials, I am "bound" to my session, my 
> identity has been validated. 

Yes, this is precisely the use case for SASL/EXTERNAL, which is why we 
implemented it that way.

> Also, for Heimdal, I thought one of the benefits of using ldapi was that 
> you could have more privileged access to the LDAP data without having to 
> store authentication credentials and use them as would be used when 
> accessing over TCP.

Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to 
request this privilege. There is no assumption of automagic authorization.
Even though the credentials are available, the server will not inspect them 
unless it receives a SASL/EXTERNAL Bind request. If it receives such a 
request, then it will construct a SASL authentication DN of the form
gidNumber=GID+uidNumber=UID,cn=peercred,cn=external,cn=auth
which then drops into the usual SASL identity mapper for optional munging 
into some other DN and that DN becomes the identity bound to the session.

Note that RFC4513 section 4 states explicitly :
    Upon initial establishment of the LDAP session, the session has an
    anonymous authorization identity.

Section 2 also states
    LDAP server implementations MUST support the anonymous authentication
    mechanism of the simple Bind method (Section 5.1.1).

I think it's clear that an anonymous bind MUST actually give you an anonymous 
session state, not some other implicitly selected identity.
-- 
   -- 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/