Quoting "Bryan J. Smith <b.j.smith@xxxxxxxx>" <thebs413@xxxxxxxxxxxxx>:
> 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@REALM"
>> intopassword attribute. OpenLDAP would than use saslauthd to check
>> the password(passing it user@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@xxxxxxxxxxxxxxx The {SASL} at the
begining of the string triggers it to connect to saslauthd and passes
joe.the.big.guy@xxxxxxxxxxxxxx and user supplied password
4) saslauthd (configured to use kerberos5 backend) checks password against
joe.the.big.guy@xxxxxxxxxxxxxx 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.
