Problem using Kerberos for user authentication
Braden McDaniel
I've attempted to follow the instructions here:
http://aput.net/~jheiss/krbldap/howto.html
"kinit username/admin" appears to work. But I can't get system logins
to work. I've used the authconfig-tui utility to enable Kerberos for
authentication; /etc/pam.d/system-auth looks like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_krb5.so
I've tried both changing the password field for the user in /etc/shadow
to "*K*" (as mentioned in the howto) and removing the user's entry
in /etc/shadow altogether--in both cases login fails.
Any ideas what the problem might be? Or where else I should be looking
to find out?
--
Braden McDaniel <bra...@endoframe.com>
Ryan Lynch
> I'm trying to get off the ground setting up Kerberos on a Fedora 11 box.
> I've attempted to follow the instructions here:
> Any ideas what the problem might be? Or where else I should be looking
> to find out?
I set this up recently on a few F11 boxes. When I get a chance, later
today, I'll take a look at your configs and compare them with mine.
Also, are you trying to login locally at the console, or through
KDM/GDM/XDM, or via SSH, or what?
-Ryan
Javier Palacios
> I've attempted to follow the instructions here:
That is a pretty old howto (probably older than fedora).
> I've tried both changing the password field for the user in /etc/shadow
> to "*K*" (as mentioned in the howto) and removing the user's entry
> in /etc/shadow altogether--in both cases login fails.
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.
> Any ideas what the problem might be? Or where else I should be looking
> to find out?
Just in case, you need to be able to `kinit username` (without the /admin).
And for the pam_krb5 lines on system-auth, you can add 'debug' and
will get some extra info on syslog.
And following the question from Ryan, I recommend you to check first
with console, then with ssh and finally with any window based login.
Javier Palacios
Steve Glasser
assume your user accounts are kept in ldap. This may sound obvious,
but you need to create valid user accounts in either ldap or the local
passwd/shadow files (less working passwords, of course).
Check your logs on both the client and server for clues. Please post
any errors.
If you are following the sited howto, I assume you did test Kerberos
authentication separately and it is working, right?
Cheers,
Steve
On Wed, Nov 11, 2009 at 7:33 AM, Ryan Lynch <ryan.b...@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 04:46, Braden McDaniel <bra...@endoframe.com> wrote:
>> I'm trying to get off the ground setting up Kerberos on a Fedora 11 box.
>> I've attempted to follow the instructions here:
> ...
<snip>
--
Steve Glasser
sgla...@gmail.com
Douglas E. Engert
Javier Palacios wrote:
>> I'm trying to get off the ground setting up Kerberos on a Fedora 11 box.
>> I've attempted to follow the instructions here:
>> http://aput.net/~jheiss/krbldap/howto.html
>
> That is a pretty old howto (probably older than fedora).
>
>> I've tried both changing the password field for the user in /etc/shadow
>> to "*K*" (as mentioned in the howto) and removing the user's entry
>> in /etc/shadow altogether--in both cases login fails.
>
> 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.
if shadow has * it would be a locked account, and the pam account should not
allow login. Using NP i.e. no password works well as there is nopaswword
that can match NP. (When in LDAP, use {crypt}NP)
>
>> Any ideas what the problem might be? Or where else I should be looking
>> to find out?
>
> Just in case, you need to be able to `kinit username` (without the /admin).
>
> And for the pam_krb5 lines on system-auth, you can add 'debug' and
> will get some extra info on syslog.
>
> And following the question from Ryan, I recommend you to check first
> with console, then with ssh and finally with any window based login.
>
> Javier Palacios
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Ryan Lynch
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth required pam_env.so
> auth sufficient pam_unix.so nullok try_first_pass
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth sufficient pam_krb5.so use_first_pass
> auth required pam_deny.so
>
> account required pam_unix.so broken_shadow
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_krb5.so
> account required pam_permit.so
>
> password requisite pam_cracklib.so try_first_pass retry=3
> password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok
> password sufficient pam_krb5.so use_authtok
> password required pam_deny.so
>
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
> session required pam_unix.so
> session optional pam_krb5.so
>
For starters, here's my '/etc/pam.d/system_auth':
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so minimum_uid=9999 debug
auth required pam_deny.so
account required pam_access.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account sufficient pam_krb5.so minimum_uid=9999 debug
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so sha512 shadow nullok
try_first_pass use_authtok
password sufficient pam_krb5.so minimum_uid=9999 debug
password required pam_deny.so
#session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session sufficient pam_krb5.so minimum_uid=9999 debug
session required pam_unix.so
There are some differences between our setups. The biggest difference
appears to be that I'm using 'pam_krb5' in combination with
'nss_ldap', because my user/group accounts are stored in LDAP (on an
MS Active Directory DC). All accounts are either purely local (only
exist in /etc/passwd, group, and shadow), or purely AD (only exist in
Kerberos and LDAP)--there are no overlapping cases, where an account
has a local /etc/passwd entry and a Kerberos principal, as well.
So I don't think this will be very useful to you, after all. Sorry
about that. But I do want to suggest a couple of things that might
help:
- Authenticating SSH logins via Kerberos tokens requires some changes
to ssh_config, and possibly sshd_config, as well. If you haven't
modified either the client or server for GSS/Kerberos operations, and
you're not using any special command-line options, that may be part of
your problem.
- Can you post a copy of your /etc/krb5.conf file up here, as well?
In my experience, it's awfully hard to distinguish between errors in
the krb5.conf and pam.d/system_auth.
- I wanted to echo Javier's suggestion about using the 'debug'
parameter to 'pam_krb5'. You can activate it via the 'system_auth'
lines, or via your 'krb5.conf'. I could not have gotten my setup to
work without the debug messages.
-Ryan
Braden McDaniel
> > I'm trying to get off the ground setting up Kerberos on a Fedora 11 box.
> > I've attempted to follow the instructions here:
> > http://aput.net/~jheiss/krbldap/howto.html
>
> That is a pretty old howto (probably older than fedora).
I noticed that. I just haven't come across something of this nature
more recent.
> > I've tried both changing the password field for the user in /etc/shadow
> > to "*K*" (as mentioned in the howto) and removing the user's entry
> > in /etc/shadow altogether--in both cases login fails.
>
> 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.
Okay.
> > Any ideas what the problem might be? Or where else I should be looking
> > to find out?
>
> Just in case, you need to be able to `kinit username` (without the /admin).
Argh. I missed this line in the howto:
* Create additional username and username/admin principals as
necessary using kadmin
Having missed that, I made the incorrect assumption that adding
"braden/admin" would have the effect of making "braden" available for
system login.
Now that I've added "braden" principal and changed /etc/shadow to have
"NP" in the password field for this user (thanks, Douglas), login is
working.
Thanks, Javier and Steve, too. The feedback I've gotten here is bound
to help me with the next problem.
--
Braden McDaniel <bra...@endoframe.com>
Braden McDaniel
[snip]
> There are some differences between our setups. The biggest difference
> appears to be that I'm using 'pam_krb5' in combination with
> 'nss_ldap', because my user/group accounts are stored in LDAP (on an
> MS Active Directory DC). All accounts are either purely local (only
> exist in /etc/passwd, group, and shadow), or purely AD (only exist in
> Kerberos and LDAP)--there are no overlapping cases, where an account
> has a local /etc/passwd entry and a Kerberos principal, as well.
Getting LDAP up and running is the next step for me; in my case, the
directory will be hosted on this same machine. So I expect to be adding
those bits shortly.
> - Authenticating SSH logins via Kerberos tokens requires some changes
> to ssh_config, and possibly sshd_config, as well. If you haven't
> modified either the client or server for GSS/Kerberos operations, and
> you're not using any special command-line options, that may be part of
> your problem.
ssh appears to be working without me doing anything special in
sshd_config; my understanding is that once Kerberos is working with PAM,
the things that can use PAM will Just Work. I'm attributing successful
ssh logins to this.
> - I wanted to echo Javier's suggestion about using the 'debug'
> parameter to 'pam_krb5'. You can activate it via the 'system_auth'
> lines, or via your 'krb5.conf'. I could not have gotten my setup to
> work without the debug messages.
No doubt that will come in handy. Thanks...
--
Braden McDaniel e-mail: <bra...@endoframe.com>
<http://endoframe.com> Jabber: <bra...@jabber.org>
Jeffrey Watts
> 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.