[Date Prev][Date Next]
Re: LDAP and SASL...
Tobias Rice wrote:
-a gives the backend saslauthd should use but saslautd itself can only
be used with PLAIN and LOGIN (in case of email).
-----BEGIN PGP SIGNED MESSAGE-----
...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
Maybe I'm confusing some things. Is this differant than the mech you
give it upon starting it? (i.e. saslauthd -a kerberos5)
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.
| 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
2004-10-22T06:07:41 AS-REQ tobias@PLAYGROUND.NET from IPv4:192.168.44.12
2004-10-22T06:07:41 Using des3-cbc-sha1/des3-cbc-sha1
2004-10-22T06:07:41 sending 605 bytes to IPv4:192.168.44.12
2004-10-22T06:07:41 TGS-REQ tobias@PLAYGROUND.NET from
IPv4:192.168.44.12 for host/swiss.playground.net@PLAYGROUND.NET
2004-10-22T06:07:41 sending 620 bytes to IPv4:192.168.44.12
...so thats why I thought it was working against kerberos. I didn't
think it was hitting ldap.
That will work. "user -> pam (pam_ldap) -> slapd -> saslauthd ->
kerberos". but what you are doing here are just simple binds.
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).
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.