josh2780
asked on
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
to:
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?
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
to:
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?
ASKER
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???
pam_krb5[4823]: error reading keytab, not verifying TGT
/etc/krb5.keytab does not exist... I'm assuming that it should???
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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)
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@EX
For more information on ktpass:
http://technet2.microsoft.com/windowsserver/en/library/64042138-9A5A-4981-84E9-D576A8DB0D051033.mspx
http://technet2.microsoft.com/windowsserver/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true
(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@EX
For more information on ktpass:
http://technet2.microsoft.com/windowsserver/en/library/64042138-9A5A-4981-84E9-D576A8DB0D051033.mspx
http://technet2.microsoft.com/windowsserver/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true
ASKER
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!
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!
I.E.
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.