Quoting "Bryan J. Smith b.j.smith@ieee.org" thebs413@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@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@BLUE.MYORG.COM. The {SASL} at the begining of the string triggers it to connect to saslauthd and passes joe.the.big.guy@BLUE.MYORG.COM and user supplied password
4) saslauthd (configured to use kerberos5 backend) checks password against joe.the.big.guy@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.