Problem using Kerberos for user authentication

[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

"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 <braden@...>

________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Ryan B. Lynch]

On Wed, Nov 11, 2009 at 04:46, Braden McDaniel <braden@...> 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:
...
> 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
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Javier Palacios-2]

> 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.

> 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           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Steve Glasser-2]

Where are your user accounts held?  The instructions you site above
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.lynch@...> wrote:
> On Wed, Nov 11, 2009 at 04:46, Braden McDaniel <braden@...> 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
sgla9347@...
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[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           Kerberos@...
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

--

  Douglas E. Engert  <DEEngert@...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  [phone]
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Ryan B. Lynch]

On Wed, Nov 11, 2009 at 04:46, Braden McDaniel <braden@...> wrote:

>        #%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
>

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

________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Braden McDaniel]

On Wed, 2009-11-11 at 16:46 +0100, 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 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 <braden@...>

________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Braden McDaniel]

Ryan Lynch wrote:

[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: <braden@...>
<http://endoframe.com>               Jabber: <braden@...>
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Jeffrey Watts-2]

On Wed, Nov 11, 2009 at 9:46 AM, Javier Palacios <javiplx@...> 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.
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos