kerberos and smartphone clients

[Luke Scharf]

Nikolay Shopik wrote:
> You mean PAM on client? This won't work for me most clients running 
> Windows and few Mac OS X. And I use virtual users so they don't show 
> up in getent passwd.
>
> So for now I have only one option run plain text password db along 
> with Kerberos for users who wish login into mail server using their 
> smartphone.

I meant to suggest configuring PAM this way on the e-mail server.  Then 
your e-mail client uses a plaintext login, the e-mail server daemon 
hands the password off to PAM (just like sshd would), and then PAM 
Kerberos module uses Kerberos to say "yay" or "nay" to the password.

The e-mail client doesn't know or care how this is implemented -- 
they're just doing a normal plaintext login, like every e-mail client 
does, so the machinations on the back end are invisible to it.  Since 
the password really does need to be transmitted from the server to the 
client, I would recommend  using TLS/SSL (and using plaintext within the 
encrypted connection).  This also means that CHAP style authentication 
won't work, since Kerberos won't reveal the password over the network to 
the e-mail server.  With SSL or TLS, though, this method is secure 
enough for most environments.

Then for e-mail clients that do support Kerberos, they can present their 
ticket and provide super-secure passwordless login -- which is what I 
gather you've already configured.

If you're using virtual users on the e-mail server, then saslauthd can 
be configured to attempt to log in to Kerberos to see if the password is 
valid instead of PAM.  This is an application-level way to check 
credentials, as opposed to a system-level method like PAM -- so if your 
users don't show up in getent, then saslauthd is the way to go.  But 
your e-mail server-daemon needs to be aware of how to use saslauthd -- 
most popular e-mail servers are, and if your e-mail server is flexible 
enough to use GSSAPI, it would probably can use SASL, too.

-Luke