Integrating Kerberos Authentication on Red Hat and Ubuntu Hosts


Table of Contents

Follow the instructions below to enable Kerberos authentication on Red Hat and Ubuntu hosts. For simplicity, these instructions assume:

  1. You’re starting from a clean install.
  2. The host is connected to a network and can minimally reach a Kerberos key distribution center (KDC).
  3. You already have a local user created and elevated privileges on the host.
  4. You will be using your local /etc/password files for identity information (name, UID, home directory, etc).

An account’s local username must match the user’s UMD Directory ID for Kerberos authentication to succeed. If you have users with local accounts that do not match their UMD Directory IDs, their local username will need to be updated or a new local account created that does match their UMD Directory ID.

These instructions are meant as a starting point. You may need to customize these instructions to suit your specific host configuration.

Configuring Kerberos Authentication

The instructions on this page have been tested with the following Linux distributions:

The instructions may work for other distributions or versions.

Prerequisites

Both Red Hat and Ubuntu

If you haven’t already, submit a request to create principals and keytabs by following the instructions in the “Requesting Permission to Create Keytabs” section below.

Red Hat

No Prerequisites

Ubuntu

All of the commands to configure Kerberos authentication require elevated privileges. While following the instructions below, assume all commands are prefixed with “sudo” or elevate to the root account before starting e.g. “sudo su -l”.

If you are using a desktop variant of Ubuntu, please install the SSH package on the host before starting: apt install ssh

Kerberos Authentication on Red Hat and Ubuntu

Follow the instructions below to configure Kerberos authentication.

  1. Connect to the host to be “kerberized” via SSH or the console. 
    ssh <DIR_ID>@<FQDN>
    Where DIR_ID is your directory ID (or the username for the account you have on the host) and FQDN is the fully-qualified domain name of the host to be updated e.g. linuxrocks.umd.edu.
  2. If it doesn't already exist, create a local user that matches your directory ID.
    useradd -m -U <DIR_ID>
  3. Follow the instructions in the “Creating a Host Principal and Keytab File” section below to create a host principal and keytab file and upload the keytab file to the current host.
  4. Move the keytab to /etc/krb5.keytab and adjust permissions (keytab file assumed to be located in /tmp):
    mv /tmp/<FQDN>.keytab /etc/krb5.keytab 
    chown root:root /etc/krb5.keytab 
    chmod 400 /etc/krb5.keytab
  5. Follow the instructions in the “Configuring Kerberos” section to enable the host to communicate with our Kerberos servers.
  6. Follow the instructions in the ”Configuring and Enabling SSSD” section to setup SSSD.
  7. Follow the instructions in the “Enabling Kerberos Authentication in SSHD” section to configure Kerberos support in the SSH daemon.
  8. Test and confirm you are able to log into your host via the console and SSH using your University credentials (not your local account password!).
  9. If your test above was successful, lock the passwords for all local user accounts.
    passwd -l <USER>
    NOTE: The idea here is to force users to use their Directory ID credentials to log in. This can be done in different ways. Locking the password of the local account is one way. You may also update the PAM stack appropriately and remove the pam_unix module.

Script and Ansible Playbooks

A script that implements the steps above as well as two Ansible playbooks are attached to this page (see the attachments banner at the top of the page).

Top

Prerequisites

Please review the instructions in the “Kerberos Authentication on Red Hat and Ubuntu” section above and the script itself before running it. Also, please be sure you’ve created the host principal and uploaded and placed the keytab file on the host as well. Please note that the script does not disable local passwords.

Running the Script and Playbooks

To run the script:

  1. Upload the script to the host you'd like to "kerberize."
  2. Make the script executable
    chmod +x setup_kerb_auth.sh
  3. Elevate your priveliges via su or sudo.
  4. Run the script:
    ./setup_kerb_auth.sh
  5. If successful, pick up the instructions in the “Kerberos Authentication on Red Hat and Ubuntu” section at step #8. Test your access and disable local passwords.

The Ansible playbooks are fairly simple and just run the above setup_kerb_auth.sh script.

To run the playbook:

  1. Copy the playbook(s) and the setup_kerb_auth.sh script into the same directory.
  2. Run Ansible and specify the host you’d like to “kerberize”.
    For Ubuntu hosts:
    ansible-playbook -i <HOST>, setup_kerb_auth.ubuntu.yml --ask-become-pass
    And for RHEL hosts:
    ansible-playbook -i <HOST>, setup_kerb_auth.redhat.yml --ask-become-pass
    where <HOST> is the target host. In both cases, Ansible will prompt for the password to use to elevate its privileges.
  3. Confirm the Ansible run was success via the “PLAY RECAP” output. See below for an example of successful output:
    avw-unix-jump2:it-20$ ansible-playbook -i 10.125.28.78, setup_kerb_auth.ubuntu.yml --ask-pass --ask-become-pass 
    SSH password:
    BECOME password[defaults to SSH password]:
    PLAY [Enable Kerberos authentication on Ubuntu] ****************************************************
    TASK [Gathering Facts] *****************************************************************************
    ok: [10.125.28.78]
    TASK [run setup_kerb_auth script] ******************************************************************
    changed: [10.125.28.78]
    PLAY RECAP ***************************************************************************************** 
    10.125.28.78 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
  4. If successful, pick up the instructions in the “Kerberos Authentication on Red Hat and Ubuntu” section at step #8. Test your access and disable local passwords.

Top

Subtasks

Requesting Permission to Create Keytabs

Not everyone can create Kerberos principals and keytabs. Please email request@umd.edu with your request to create Kerberos principals and keytabs for your department. Please include, if applicable, the subdomain e.g. cs.umd.edu or naming pattern e.g. engr-blahblah.umd.edu you use for your hosts. Please also include any other folks on your team that would need to be able to create or delete principals for your department.

Once your request is approved and implemented, you’re ready to move to the next step!

Creating a Host Principal and Keytab File

No matter which distribution you use, you must create a host principal and keytab for each host you’d like to  “kerberize”. Follow the instructions below to create a principal and keytab for a host.

  1. If you haven’t already, submit a request to create principals and keytabs by following the instructions in the “Requesting Permission to Create Keytabs” section above.
  2. Log in via SSH to glue.umd.edu:
    ssh <DIR_ID>@glue.umd.edu
    where <DIR_ID> is  your University ID. You will be prompted for your UMD Directory ID password and may also have to authenticate via Duo (2FA).
  3. Create a keytab and host principal via the dept_mk_keytab script. Substitute your fully qualified domain name (e.g. linuxrocks.umd.edu) for <FQDN> below:
    /usr/glue/scripts/dept_mk_keytab -f ~/<FQDN>.keytab -n host -i <FQDN> -y
  4. Copy the keytab created in the previous step from glue.umd.edu to your host:
    # On glue.umd.edu: 
    scp ~/<FQDN>.keytab <FQDN>:/tmp/
    NOTE: If it’s easier, you can also download the keytab from glue.umd.edu to your host:
    # On your host: 
    scp glue.umd.edu:~/<FQDN>.keytab /tmp/
  5. Once the keytab has been successfully transferred to its host, you should delete the keytab from your home directory:
    rm -f ~/<FQDN>.keytab
  6. Log out of glue.umd.edu.
    exit

Configuring Kerberos

Follow the instructions below to configure Kerberos on your host.

  1. Install the required packages. On RHEL hosts, install the krb5-workstation and krb5-libs packages:
    yum install krb5-libs krb5-workstation
    On Ubuntu hosts, install the krb5-user package:
    apt install krb5-user
  2. Replace content in /etc/krb5.conf with the following:
    [libdefaults]
    default_realm = UMD.EDU
    forwardable = true
    rdns = false
  3. At this point, you should be able to authenticate to your Kerberos account e.g. cbettenh@UMD.EDU.
    [root@rhel9-test1 cbettenh]# kinit cbettenh@UMD.EDU
    Password for cbettenh@UMD.EDU:<DIRECTORY_ID_PASSWORD>
    Warning: Your password will expire in 362 days on Tue 24 Mar 2026 09:57:36 AM EDT
    [root@rhel9-test1 cbettenh]# klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: cbettenh@UMD.EDU
    Valid starting   Expires          Service principal
    03/26/2025 22:18:13  03/27/2025 22:18:09  krbtgt/UMD.EDU@UMD.EDU

Top

Configuring and Enabling SSSD

SSSD is the “System Security Services Daemon” and allows hosts to access remote directories and authentication mechanisms. SSSD supports multiple identity and authentication providers, such as:

SSSD in concert with a PAM (Pluggable Authentication Modules) module (pam_sss) allows the identity and authentication providers above to be inserted into the PAM stack.

To configure SSSD on your Linux host, follow the instructions below:

  1. Install SSSD-related packages.
    On RHEL hosts, install sssd-proxy and sssd-krb5:
    yum install sssd-proxy sssd-krb5
    On Ubuntu hosts, only sssd-krb5 is needed:
    apt install sssd-krb5
    NOTE: If your PAM configuration files have been customized, you may need to run "pam-auth-update --force" on Ubuntu hosts in order for it to add the pam_sss entry to your PAM stack (required for Kerberos auth). Libpam-sss will not overwrite customized files. Be sure to back up all files in /etc/pam.d beforehand in case you need to revert back!
  2. Create the file /etc/sssd/sssd.conf with the following contents:
    [sssd]
    domains = umd.edu
    services = pam
    config_file_version = 2
    [domain/umd.edu]
    id_provider = proxy
    proxy_lib_name = files
    auth_provider = krb5
    krb5_realm = UMD.EDU 
    krb5_use_kdcinfo = false
    If you are setting up a laptop or other device that may not have constant network connectivity, you should also enable credential caching to allow users to log in even if the host does not have network access. To do so, add the following line in the [domain/umd.edu] section above:
    cache_credentials = true
    And add a [pam] section to the bottom of /etc/sssd/sssd.conf as follows:
    [pam]
    # Allow credentials to be cached for 1 day
    offline_credentials_expiration = 1
  3. Adjust the ownership and permissions on /etc/sssd/sssd.confsssd.conf file:
    chown root:root /etc/sssd/sssd.conf 
    chmod 600 /etc/sssd/sssd.conf
  4. On RHEL hosts, enable SSS via authselect:
    authselect select sssd --force
    NOTE: The --force parameter is required. authselect will not overwrite files e.g. PAM files if they already exist.
    No action is needed on Ubuntu hosts. 
  5. Enable and start sssd:
    systemctl enable sssd --now

Enabling Kerberos Authentication in SSHD

In most cases, Kerberos authentication is not supported by the default SSH configuration. Follow the instructions below to allow SSH to support Kerberos authentication:

  1. Edit the /etc/ssh/sshd_config file and enable the GSSAPIAuthentication and GSSAPICleanupCredentials parameters:
    [...] 
    # GSSAPI options
    GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes
  2. Restart ssh to load your latest configuration changes:
    systemctl restart sshd
    On Ubuntu hosts:
    systemctl restart ssh

Top