[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP and SASL...

Tobias Rice wrote:
Hash: SHA1

...whoops, I meant to post back to the list, too. Sorry for the duplicate.

Thanks for your reply! You're right, I did mean to say testsaslauthd.

| Then you're suffering from the same misconception that I have been.
| saslauthd does nothing except auth mechs PLAIN and LOGIN (both
| plaintext).
Maybe I'm confusing some things. Is this differant than the mech you
give it upon starting it? (i.e. saslauthd -a kerberos5)
-a gives the backend saslauthd should use but saslautd itself can only be used with PLAIN and LOGIN (in case of email).

| That's not what that means. It means that plaintext authentication via | saslauthd is working (probably checking sasldb for the password). | That's all. It's not looking in your LDAP directory for the passwords | there or at your KDC. When I issues the 'testsaslauthd -u tobias -p passwd' I get this in my kerberos log: 2004-10-22T06:07:41 AS-REQ tobias@PLAYGROUND.NET from IPv4: for krbtgt/PLAYGROUND.NET@PLAYGROUND.NET 2004-10-22T06:07:41 Using des3-cbc-sha1/des3-cbc-sha1 2004-10-22T06:07:41 sending 605 bytes to IPv4: 2004-10-22T06:07:41 TGS-REQ tobias@PLAYGROUND.NET from IPv4: for host/swiss.playground.net@PLAYGROUND.NET 2004-10-22T06:07:41 sending 620 bytes to IPv4:

...so thats why I thought it was working against kerberos. I didn't
think it was hitting ldap.
Yes, it is working against kerberos but it doesn't really do kerberos. Saslauthd receives your *cleartext* password and tries to get a ticket with your Id and password. Thats not how kerberos is supposed to work since if you use any SASL enabled service such as email over the net your kerberos password will travel in the clear unless you do not use something like SSL/TLS.

So, is what I'm wanting to do even possible?
user -> some service -> pam (using pam_ldap.so) -> slapd (tries to auth
and continues to sasl) -> sasl -> kerberos(windows kdc).
That will work. "user -> pam (pam_ldap) -> slapd -> saslauthd -> kerberos". but what you are doing here are just simple binds.

The best solution is IMO to use kerberos directly i.e. getting a ticket from your KDC first and use SASL/GSSAPI to connect to your services, but that's another story and it requires your Client to understand kerberos.