Go Premium for a chance to win a PS4. Enter to Win


Kerberos Authentication

Posted on 2008-06-10
Medium Priority
Last Modified: 2013-12-16
I've setup Kerberos authentication on a Linux box to authenticate users against an Active Directory domain.  It is working, however, for each domain user that authenticates I get the following in /var/log/secure:

Jun 10 08:58:27 dev sshd[8532]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.456.789.123  user=bjones
Jun 10 08:58:27 dev sshd[8532]: pam_krb5[8532]: authentication succeeds for 'bjones' (bjones@CORP.DOMAIN.LAN)
Jun 10 08:58:27 dev sshd[8532]: Accepted password for bjones from 123.456.789.123 port 2716 ssh2
Jun 10 08:58:27 dev sshd[8532]: pam_unix(sshd:session): session opened for user bjones by (uid=0)

The problem I have with this is the 'authentication failure' log for all of the domain users (because it is failing to authenticate locally).  So I edited /etc/pam.d/system-auth and changed:

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


auth        required      pam_env.so
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

Which works, however, now I present myself with another problem that I need to restrict domain authentication to user IDs 500 and above.  With the above change, users such as 'root' in the domain will authenticate with credentials from active directory.  So I switched it back to the original (moved "auth        sufficient    pam_krb5.so use_first_pass" back down).  I also changed the "... >= 500 quiet" to "... >= 700 quiet" so that I could still create ~200 local users that would not authenticate via the domain (i.e. 3rd party software accounts... like 'oracle').

So my question is...  can I control which users authenticate via Kerberos/domain (i.e. users with an ID of 700 or above) AND can I specify which pam module to use (i.e. domain accounts should skip pam_unix and use pam_krb5) so that I do not get a 'authentication failure' log for the filed pam modules?
Question by:josh2780
  • 4
  • 2
LVL 23

Expert Comment

ID: 21756667
I suggest using thie   minimum_uid  option with pam_krb5?

auth        required      pam_env.so
auth        sufficient    pam_krb5.so use_first_pass minimum_uid=500  validate
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

See 'man pam_krb5'

Or  create an empty  .k5login  file in root's  home directory, so that no Kerberos principals
are listed as allowed to authenticate as that user.


Author Comment

ID: 21760140
I get the following error in /var/log/secure after logging in:

pam_krb5[4823]: error reading keytab, not verifying TGT

/etc/krb5.keytab does not exist... I'm assuming that it should???
LVL 23

Accepted Solution

Mysidia earned 2000 total points
ID: 21786606
That's  probably a result of the "validate"  option, it sounds as if other parts of Kerberos haven't
 been setup correctly on the workstation.

Try testing without the "validate"  option and see if the authentication process seems to
work like what you want.

If you don't include the validate option, then pam_krb _ONLY_ attempts to obtain a TGT
from a KDC and decrypt it with the password you typed, it never actually gets a service
ticket and validates that the TGT  came from a legitimate KDC.

I.E. Without validation, nothing verifies that the Kerberos server  isn't being
spoofed by a fake kerberos server.   UDP packets are exceptionally easy to forge the
source address of, and there may be some risk if you just turn off "validate".

For instance, this isn't very secure compared to full kerberos authentication.

Without service principals setup for the host (and each service), you will also be unable
to use ticket-based authentication.

"I.e.  kinit user@REALM.COM"  and then securely telnet to other hosts, using encrypted
telnet, or auth, without typing your secret password in.

With true kerberos auth: you run 'kinit' from your workstation, and you are never prompted by
a remote host to type your password  (this protects you against say a compromised SSH or Telnet
daemon that an attacker modified to capture passwords).

When you first add a server to a Kerberos realm, you create a host principal to the server.
In fact, even the Kerberos server itself should have a host principal in /etc/krb5.keytab,
and possibly some keys for other service principals in other keytab files.

The /etc/krb5.keytab file should be unique and different on every server.
It's a very secret file that contains that host's encrypion key(s)

Adding a host is much like making a user, except its name is  "host/<client-machine-hostname>"

Once you created the principal, you copy its secret key to the client machine and store
it in /etc/krb5.keytab

/etc/krb5.keytab is a binary file in a special format, so you need to use the 'kadmin'
tool to generate suitable output.

i.e. in MIT Kerberos' kadmin (running on the KDC) you  might login as your admin user
and do     "ank host/myhost.example.com"

Then run 'kadmin -p host/myhost.example.com' on the client machine and   'ktadd host/myhost.example.com'

An alternative is to use 'ktadd' on the KDC server to create a temporary file somewhere else.

kadmin> ank -randkey host/test3.example.com
kadmin> ktadd -k /root/test3.temp.keytab

Then move "/root/test3.temp.keytab" to  "/etc/krb5.keytab" on the destination server, to finish the key setup.

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

LVL 23

Expert Comment

ID: 21786627
It bears mentioning that for 'validate' to work, several other important conditions must also be true
for most implementations of Kerberos:

* The KDC clock must be synced (within 5 minutes) of every server's clock.  This is normally done by running NTP.      If clock skew exceeds 5 minutes, kerberos auth starts to fail.
(Usually, you can change this by editing /etc/krb5.conf  but allowing clock skew may allow
a replay attack, where an attacker sniffs packets generated by the Kerberos KDC or
a workstation and replays them to authenticate later)

* The hosts' hostnames must be fully qualified.

* Forward DNS of the fully qualified hostname must match the source ip of the request.

* Reverse DNS of the source ip must match the fully qualified domain name.
(Usually you can change this by editing /etc/krb5.conf,  if absolutely necessary)
LVL 23

Expert Comment

ID: 21786685
To generate kerberos principals for UNIX hosts on a Windows AD on Windows 2003 R2, create a normal user for the host somewhere in your directory structure to map the principle onto.

(The server username does not need to have interactive login rights, but does need to be able to auth,
server's "password" should be set to never expire.    Once you run "KTPASS", the serverr's
password should  be highly  convoluted.)

Use whatever username is good for your directory;  I suggest placing such users in a separate OU.

And you need the "KTPASS" tool which you use to create a keytab file like this:
(KTPASS and SETUPSPN are part of the Windows support tools
http://go.microsoft.com/fwlink/?LinkId=62270 )

C:\>ktpass -princ host/myhost.example.com@EXAMPLE.COM -mapuser specifythechosenusernamehere -crypto rc4-hmac-nt -ptype KRB5_NT_SRV_HST -pass (type a very long password here) -out C:\tempfile.keytab

For more information on ktpass:



Author Comment

ID: 21793251
Hi Mysidia,

Thanks for the great suggestions and information.  I'm out of the office this week so I will be giving all of this a shot next week and let you know the results.  Thanks!

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you have a server on collocation with the super-fast CPU, that doesn't mean that you get it running at full power. Here is a preamble. When doing inventory of Linux servers, that I'm administering, I've found that some of them are running on l…
Linux users are sometimes dumbfounded by the severe lack of documentation on a topic. Sometimes, the documentation is copious, but other times, you end up with some obscure "it varies depending on your distribution" over and over when searching for …
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
Suggested Courses
Course of the Month7 days, 7 hours left to enroll

824 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question