Kerberos - Basic Workstation Authentication
This section covers configuring a Linux system as a Kerberos client. This will allow access to any kerberized services once a user has successfully logged into the system.
Note that Kerberos alone is not enough for a user to exist in a Linux system. Meaning, we cannot just point the system at a kerberos server and expect all the kerberos principals to be able to login on the linux system, simply because these users do not exist locally. Kerberos only provides authentication: it doesn’t know about user groups, Linux uids and gids, home directories, etc. Normally another network source is used for this information, such as an LDAP or Windows server, and, in the old days, NIS was used for that as well.
Installation
If you have local users matching the principals in a Kerberos realm, and just want to switch the authentication from local to remote using Kerberos, you can follow this section. This is not a very usual scenario, but serves to highlight the separation between user authentication and user information (full name, uid, gid, home directory, groups, etc). If you just want to be able to grab tickets and use them, it’s enough to install krb5-user and run kinit.
We are going to use sssd with a trick so that it will fetch the user information from the local system files, instead of a remote source which is the common case.
To install the packages enter the following in a terminal prompt:
$ sudo apt install krb5-user sssd-krb5
You will be prompted for the addresses of your KDCs and admin servers. If you have been following this chapter so far, the KDCs will be: kdc01.example.com kdc02.example.com (space separated)
And the admin server will be: kdc01.example.com. Remember that kdc02 is a read-only copy of the primary KDC, so it doesn’t run an admin server.
Note
If you have added the appropriate SRV records to DNS, none of those prompts will need answering.
Configuration
If you missed the questions earlier, you can reconfigure the package to fill them in again: sudo dpkg-reconfigure krb5-config.
You can test the kerberos configuration by requesting a ticket using the kinit utility. For example:
$ kinit ubuntu
Password for ubuntu@EXAMPLE.COM:
Note
kinitdoesn’t need for the principal to exist as a local user in the system. In fact, you cankinitany principal you want. If you don’t specify one, then the tool will use the username of whoever is runningkinit.
The only remaining configuration now is for sssd. Create the file /etc/sssd/sssd.conf with the following content:
[sssd]
config_file_version = 2
services = pam
domains = example.com
[pam]
[domain/example.com]
id_provider = proxy
proxy_lib_name = files
auth_provider = krb5
krb5_server = kdc01.example.com,kdc02.example.com
krb5_kpasswd = kdc01.example.com
krb5_realm = EXAMPLE.COM
The above configuration will use kerberos for authentication (auth_provider), but will use the local system users for user and group information (id_provider).
Adjust the permissions of the config file and start sssd:
$ sudo chown root:root /etc/sssd/sssd.conf
$ sudo chmod 0600 /etc/sssd/sssd.conf
$ sudo systemctl start sssd
Just by having installed sssd and its dependencies, PAM will already have been configured to use sssd, with a fallback to local user authentication. To try it out, if this is a workstation, simply switch users (in the GUI), or open a login terminal (CTRL-ALT-<number>), or spawn a login shell with sudo login, and try logging in using the name of a kerberos principal. Remember that this user must already exist on the local system:
$ sudo login
focal-krb5-client login: ubuntu
Password:
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-21-generic x86_64)
(...)
Last login: Thu Apr 9 21:23:50 UTC 2020 from 10.20.20.1 on pts/0
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_NlfnSX
Default principal: ubuntu@EXAMPLE.COM
Valid starting Expires Service principal
04/09/20 21:36:12 04/10/20 07:36:12 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 04/10/20 21:36:12
And you will have a Kerberos ticket already right after login.