Samba with Active Directory: getting bigger?

Posted Feb 5, 2010 15:04 UTC (Fri) by drag (subscriber, #31333) [Link]

PAM is not networkable. Your application needs to natively support Krb5 through GSSAPI or whatever to actually be useful in a networked domain environment.

Its pretty easy to understand why PAM sucks when you look at using it with telnet or ftp versus native kerberos support. As a part of the old normal Kerberos way of doing things kerberized versions of ftp, telnet and a couple other things were commonly supplied with it.

So if your using PAM + ftp then this is how things work:
* User logs in to their local computer. This works through a series of encrypted packets with the various krb services. They cache their credentials locally and they will be valid up to 8 hours or so (configurable)
* User runs the ftp client program to log into a remote ftp server.
* The user gets prompted for their username and password.
* the user supplies username and password.
* The server then uses PAM to do look-ups and effectively does a local login for that user.
* The user is granted access to the ftp server.


IF your using a ftp server with native Kerberos integration then:
* User logs in to their host, gets the credentials; caches them.
* User runs the ftp client program to log into the remote ftp server.
* User gets requests a ticket from the krb ticket granting service to get to the ftp server. Ftp server also supplies it's credentials as part of the kerberos protocol.
* User is granted access to the ftp server.


So you see with PAM + ftp the username and password are transmitted in plain text over the network. There is no proof that the server is the correct one either. You could be logging into one via DNS poisoning attack or some other thing. This makes it trivial for the attacker to gain access to your user's account. With SSO schemes and kerberos this makes the problem especially critical since you will be using the same username and password for _everything_.

However with the correct kerberos integration you have no password being transmitted over the network... in plain text or encryption. The protocol eliminates the need to ever transmit passwords over a network (except for the user to change a password or during the initial user setup). Also the ftp server identity itself is also confirmed. As part of the kerberos protocol each server itself has to be added to the domain and it has it's own credentials that get used as part of the authentication stuff. (of course ftp being plain text means that its trivial to intercept traffic after the fact, but whatever)

With properly encrypted services, like OpenSSH, it is more of a toss up whether you want to use Openssh's password challenge-response support or use it's native kerberos support. There is some flexibility lost in using full kerberos setup and it's ok to transmit passwords over the network as long as they are properly encrypted. However generally its probably a good thing to use native kerberos when its available. You can use kerberos to eliminate the possibility of brute force password attacks on your SSH server (although it does not prevent users from trying brute force by logging into the domain) and it can get rid of the need for OpenSSH's private/public keys which is inherently very difficult for administrators to properly manage and does not scale well. (as illustrated by successful malicious attacks the Debian and Fedora folks suffered in the past)