• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3267
  • Last Modified:

Kerberos Authentication

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?
  • 4
  • 2
1 Solution
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.

josh2780Author Commented:
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???
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.

Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

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)
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:


josh2780Author Commented:
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!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now