RE: Authentication & Login sessions

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of David Nugent
>
> I am currently working on a project to integrate LDAP directory
> functionality into the FreeBSD operating system. The directory server will
> be an integral part of the OS, providing a generic directory solution for
> system tables currently maintained in flat files or specialist databases
> (/etc/{master.}passwd, /etc/group, /etc/networks, /etc/protocols,
> /etc/services etc. etc). The idea is that ultimately, a UNIX box with an
> LDAP-based core will be easily configured as part of a cluster, by either
> pointing the system or parts thereof at an external LDAP server, or the
> machine's LDAP server is integrated into an existing DIT. There are other
> benefits as well stemming from the fact that access controls in the
> directory are independant from native UNIX credentials, so you may no
> longer require root access to a machine to, for example, create a user or
> change a password.

This is definitely an interesting idea. The guys at www.padl.org have
already done a lot of work in this area. We've done a lot of work in this
area at www.symas.com as well. You may want to look at RFC 2307 for a schema
for representing NIS databases in LDAP. I submitted several suggested
changes for this RFC to make it more generic, so that it would be usable for
AIX, HP and SCO's particular enhanced security databases but those changes
haven't gone anywhere. (Not surprising, since the primary force behind the
RFC is Sun. Oh well.) At any rate, the NIS-based schema is adequate for any
BSD-based OS.
>
> All of this solves the problems usually handled by NIS, but in a more
> elegant and generic way. However, there are a number of hurdles to get
> over first.
>
> The primary problem is authentication. All processes are owned by a user,
> as is the usual model in UNIX. Since authentication comes from the
> directory, login sessions can therefore be tied to the specific object
> against which the user was authenticated. The problem is, during that
> session, the user will be accessing the directory (albiet hidden under the
> libc API bonnet), and since we don't want to make the directory world
> readable, the user requires *authenticated* access to the directory until
> the login session terminates. However, I doubt whether reserving a tcp
> connection for the life of each session is desirable, so a connectionless
> protocol, or at least a pre-authenticated tcp network connection is
> needed.
>
> The problem can be solved using AF_UNIX type sockets instead of network
> transport, which solves a lot of issues so far as credentials go. This
> requires modification to the server to support of course, but this assumes
> that the server is running locally which it may not, so I do not consider
> this a viable option. I also looked at connectionless LDAP, but since it
> (understandably) does not support authenticated access, it too is not a
> suitable mechanism. The only option I can think of is to use kerberos, but
> before requiring kerberos as part of this equation I thought I'd ask to
> see if anyone has done any development along these lines, or perhaps
> someone has other helpful comments.
>
> Any thoughts or points will be appreciated.
>
> David

There is code for Unix-domain sockets in the development stream now. I'm not
sure that I'd want to use LDAP as my local lookup protocol, but it's an
available option. If you go this route, the solution is pretty
straightforward: Use AF_UNIX sockets for client access to a local slapd. In
addition, if you want a particular machine to use the auth database of a
remote slapd, use back-ldap on the local slapd as a proxy to communicate
with the remote slapd. I would use TLS on top of the proxy connection, of
course.
There's still an access control issue in this case - with the proxy, you
would have a single authenticated connection from the local slapd to the
remote. I believe it would be sufficient to place ACL clauses on the
back-ldap backend to control search results, but there is no ACL checking on
updates.

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