[CentOS] Directory Server for CentOS 4.1

Thu Jun 30 16:49:41 UTC 2005
alex at milivojevic.org <alex at milivojevic.org>

Quoting "Bryan J. Smith <b.j.smith at ieee.org>" <thebs413 at earthlink.net>:

> The SASL capability can interface with any GSSAPI solution IIRC.
> I _know_ that includes a _real_ KDC.

I'm not talking about LDAP server supporting SASL GSSAPI here.  This is
completely different.  I'm talking about LDAP server talking to saslauthd to
perform the authentication, passing it the string from userPassword attribute
as username/realm part.

>> What I'm talking about is putting something like "{SASL}user at REALM"
>> intopassword attribute.  OpenLDAP would than use saslauthd to check
>> the password(passing it user at REALM and whatever user entered as
>> password).  In my case saslauthd is configured to check passwords
>> using kerberos5 backend.
>> Basically, directory server does not store any passwords, passwords
>> are stored in Kerberos database
>
> That's _exactly_ how most enterprise have been running NsDS since the
> '90s, using Kerberos as the authentication end.

As I said above, it's not how they have been doing it.

They are using SASL GSSAPI.  I'm not.  My clients are not capable of 
it. Actually, they are not capable of SASL anything.  I'm lucky they 
are capable of
SSL/TLS so passwords do not fly around in cleartext.

What happens in my case is:

1) user joe connects to IMAP server (for example, or some other service), and
uses plaintext LOGIN to authenticate with his username (joe) and 
password (sex,
easy to remember and fast to type)

2) IMAP server is configured to check username/password against LDAP 
server, so
it attempts to perform simple bind as uid=joe,ou=smurfs,dc=myorg,dc=com

3) LDAP server finds that blah=joe,ou=smurfs,dc=myorg,dc=com has userPassword
attribute with value {SASL}joe.the.big.guy at BLUE.MYORG.COM.  The {SASL} at the
begining of the string triggers it to connect to saslauthd and passes
joe.the.big.guy at BLUE.MYORG.COM and user supplied password

4) saslauthd (configured to use kerberos5 backend) checks password against
joe.the.big.guy at BLUE.MYORG.COM principal in BLUE.MYORG.COM Kerberos domain and
returns "go" or "no go".

In this example, the LDAP server simply holds the mapping between user's
username on mail server and his Kerberos principal name (it holds other stuff
too, I haven't installed it just to get simple authentication working).  As I
said, there are multiple domains, so IMAP server can't simply slap @REALM to
the end of user supplied username and do the check directly.  For historical
reasons, IMAP server uses flat userspace (while in reality it is more
tree-like).  And nope, having users type the @REALM part during login is not
acceptable solution (most of them don't even know what @REALM should be, nor
should they be bothered with such details).


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.