Problem using Kerberos for user authentication

[Jeffrey Watts]

On Wed, Nov 11, 2009 at 9:46 AM, Javier Palacios <javiplx at gmail.com> wrote:

> The '*K*' thing is probably innacurate. I've never used, and had
> success in debian, fedora and RHEL. And removing the user entry in
> /etc/shadow (without changes in /etc/passwd) should produce a
> non-usable account, either with kerberos or whichever auth method.
>
>
I've just implemented Kerberos+LDAP on RHEL3-5 and HP-UX 11.11-11.31 using
AD as the backend.

Javier, creating an entry in /etc/passwd is a very useful tool for
troubleshooting pam_krb5, as long as you have "passwd files ldap" in
nsswitch.conf.  The dummy entry allows you to verify the Kerberos piece, as
the NSS lookup will hit the entry there.  I usually just make a point of
making it point to a different home directory so I can easily distinguish
which is being used.

Braden, please tell us more about your setup.  PAM is, to be honest, the
simplest part of the process.  The nss_ldap config (/etc/ldap) is the most
difficult piece.  Kerberos is one of the easiest, though until you've
learned the basic concepts of Kerberos and become familiar with the
terminology and tools it can be a bit mystifying.

One quick thing you must look at first, however, is your sshd_config.  The
stock F11 sshd setup is not compatible with pam_krb5.  The following two
options must be set:
ChallengeResponseAuthentication yes
UsePAM yes

The latter is set by default, but the former is not.  If
ChallengeResponseAuthentication is disabled, sshd will not use PAM for
authentication, which means pam_krb5 will never get invoked to handle the
auth.  You should also enable the two GSSAPI options so that sshd will take
tickets.

While I haven't done the integration work on Fedora11 (RHEL5 is the most
current that I've done it on), here are some pieces of advice:

1) nscd likes to behave very badly and cause strange intermittent issues
that will torment you.  I had nightmares getting it to work reliably.  Avoid
it (it's the local cache option in authconfig).
2) Use pam_mkhomedir.  It will make you happy.  Read the man page for
authconfig for the option, assuming you don't want to just add it directly.
3) 95% of the time a pam_krb5 problem isn't a pam_krb5 problem.  It's a
nss_ldap issue in getting the user information.  As others have said, use
the debug option to pam_krb5, and set debug to a non-zero number in
/etc/ldap.conf.
4) Group based access control (we use a Windows-like model of local admin
groups) can be accomplished by using pam_succeed_if.so or pam_access.so
(pam_access.so is fuller featured).
5) Post your krb5.conf and your ldap.conf.  Without those two key files
folks can't help you much.
6) 90% of the howtos out there on this are incomplete or worse, incorrect.
Pay attention to the date it was written, as there's a lot of outdated
information - especially for use with AD.  Keep in mind that you need to
tailor your ldap.conf to your individual setup.
7) If you're using AD as the backend, the version of Windows you are using
is a VERY IMPORTANT thing to know.  The key question you need to find out is
if the schema supports Unix attributes, and if so, which version?  There are
multiple Services For Unix extensions for older versions of AD (blech), and
there is also the RFC2307 compliant schema found in Windows2003R2 (not 2003)
and newer.  Keep in mind that someone's posted ldap.conf may not help you if
you're using a different backend.
8) I'd recommend using SASL and a credentials cache for securing your LDAP
connection.  krb5_ccname is your friend in ldap.conf.  It's a bit tricky to
set up (as it requires that you grasp the concepts and set up a cronjob to
get a fresh ticket periodically), but once it's set up it's very elegant.  I
use the Samba 'net' command to join the system to the domain (creates a
machine account) and to create the Kerberos keytab (since ktpass on the
Windows side is a POS).  If you're more comfortable using SSL/TLS, use that
then.

Anyhow, that should get you started.

Good luck,
Jeffrey.