Samba with Active Directory: getting bigger?
Posted Feb 5, 2010 15:04 UTC (Fri) by
drag (subscriber, #31333)
In reply to:
Samba with Active Directory: getting bigger? by cortana
Parent article:
Samba with Active Directory: getting closer
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)
(
Log in to post comments)
