Need some tips on kerberizing our ENTIRE network

[Russ Allbery]

jay alvarez <kerber0sb0y at yahoo.com> writes:

> jabberd2 (by just looking at its config file, it
> definitely supports ldap, not sure with kerberos)

How to do GSSAPI is part of the Jabber protocol, but is not implemented by
any of the servers or clients so far as I know.

> Nagios server monitoring(I've heard some discussions
> regarding its ldap support, not sure with kerberos)

I'm not sure what aspect of Nagios you're thinking of here.

> rt3 TTS(also read some ldap support, not sure with
> kerberos)

Standard web application problem, see below.

> email (qmail or postfix) I just bumped into a document
> saying postfix supports sasl/gssapi, and qmail has a
> qmail-ldap version but not sure with qmail-kerberos.

I don't *think* there's a qmail-smtpd that supports GSSAPI authentication,
but I'm not sure.  Your problem here will be more on the client side
anyway; it's hard to find clients other than Eudora that support GSSAPI
authentication for SMTP.  You can, however, support Kerberos username and
password over SSL with any server that uses SASL (even though it's ugly
and ideally you don't want to do that).

> ssh (I saw its sshd_config and it has an option for
> kerberos authentication)

GSSAPI authentication is part of the standard code.  Additional patches
are needed for GSSAPI key exchange.

> Unix login (I'm also quite sure it supports being
> kerberized)

Yes.

> radius wifi login( ldap support, also not sure with
> kerberos)

You can get RADIUS to authenticate the username and password against
Kerberos fairly easily.  Getting the wifi login itself to use Kerberos is
a lot harder.

> ftp (although kerberos provides kerberized ftpd, we
> are currently using ProFTP, no idea if it supports
> kerberos authentication)

Probably not, but you're better off going to sftp anyway.  Even if you
have to use a username and password because not all SSH clients do GSSAPI
(yet), you can send it over an encrypted channel more easily than with the
various FTP solutions.

FTP is really an obsolete protocol at this point, as much as it's still in
use in various places.  If you're still running FTP for anything other
than anonymous FTP (and there, HTTP is more efficient for a lot of cases),
you want to be seriously thinking about your migration strategy.

> samba( we are using snap server. Its an appliance
> which if it doesn't support kerberos, there's no way
> to tweek it, I guess.)

Samba definitely supports Kerberos.  Kerberos is the native authentication
method for current versions of Windows.

> web apps( I've read some docs regarding apache modules
> for kerberos, some patches for some web browser to
> support kerberos authentication and also some rfcs
> which discusses adding kerberos mech to the SSL/TLS
> protocol.

There are basically three different ways of doing Kerberos authentication
to web applications:

 * Prompt for a username and password via HTTP basic auth over SSL and
   authenticate that username and password via Kerberos.  Ugly, but
   simple.  Apache modules exist.

 * Use some completely separate protocol for doing authentication that
   uses Kerberos under the hood.  Examples include WebAuth and Cosign.
   Apache modules exist.  IIS support exists for Cosign in a released
   state and WebAuth in a development state.

 * Use SPNEGO, which is basically negotiated GSSAPI over HTTP.  Apache
   modules exist, but requires client support.  Supported in current
   versions of Firefox, Mozilla, Safari, and IE, with varying degrees
   of configuration and bug workarounds required.  Client must have a
   ticket cache to authenticate to the web server, so this method won't
   work for travelling users using kiosk machines, whereas WebAuth and
   Cosign will.

In all cases, you have to convince the web application to trust Apache's
ability to authenticate the user rather than doing its own authentication
against its own username and password database.  The amount of work this
requires varies from none to rewriting the entire application, so you have
to evaluate each web application independently.

The worst offenders generally don't support *any* external authentication
mechanism, including LDAP, and insist on having the usernames and
passwords in some internal database table.

> openldap directory( it definitely supports kerberos)

Yup.

> My huge problem is, will it be achievable for those
> services I have mentioned above?  IMO, I don't see any
> sense on kerberizing some of the services while others
> are still authenticating through ldap, do you?

No.  You really do not want to have two password repositories that you
have to keep in sync.  You *can* get LDAP to refer its authentications to
Kerberos, but my understanding is that this is not the fastest thing in
the world to do.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>