[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Date: Wed, 21 Feb 2007 09:34:03 -0700
> From: Richard Megginson <rmeggins 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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]