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.
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
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.
If you have added the appropriate SRV records to DNS, none of those prompts will need answering.
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:
kinitdoesn’t need for the principal to exist as a local user in the system. In fact, you can
kinitany principal you want. If you don’t specify one, then the tool will use the username of whoever is running
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 (
Adjust the permissions of the config file and start
$ 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.