Ubuntu 22.04 | Configure LDAP/Kerberos Client Authentication
Adventures in the LXD Lab | Authentication Services
Now that I have a fancy new authentication system (Kerberos and LDAP) configured, I need to configure the clients on the network to use it for authentication. I am going to break this into 2 parts – in the event that you chose only to configure an LDAP server and did not add the Kerberos server to your environment. I am also performing this work on a machine called ‘template’ as I plan to create an LXD image that can be deployed repeatedly with this configuration in place.
Configuring LDAP Authentication
I will start with LDAP as it is the foundational component to the authentication in my lab, and honestly the only mechanism required. Adding Kerberos is not ‘required’ it just adds an additional level of security to the system (and complexity!) – but since this is a lab and all about learning – I added Kerberos to my environment. Lets start by spinning up the ‘template’ container and performing some basic configuration.
# Launch a new Ubuntu image to be my LDAP server
jason@lxd01:/$ lxc launch images:ubuntu/22.04 template
# Gain initial access the instance console
jason@apollo:/$ lxc exec template bash
# Install all available updates
root@template/: apt update; apt upgrade -y
# Install the packages that I use regularly on all of my machines
root@template:/# apt install nano net-tools landscape-client man mlocate openssh-server -y
# Configure the network interfaces to use my DNS server and DHCP
root@template:/# nano /etc/netplan/10-lxc.yaml
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp-identifier: mac
nameservers:
addresses: [172.16.2.4]
eth1:
dhcp4: true
dhcp-identifier: mac
nameservers:
addresses: [10.130.115.4]
# Install the required packages to enable LDAP authentication
root@template:/# apt install sssd-ldap ldap-utilsI have the base template configured and ready. At this point, I have to perform the configuration that will allow user to authenticate to the LDAP server – including installing the self-signed CA certificate from the LDAP server.
# Download the self-signed certificate from the LDAP server
root@template:/# scp [email protected]:/usr/local/share/ca-certificates/linfra-self-signed.crt .
# Move the certificate to the ca-certificates directory
root@template:/# mv linfra-self-signed.crt /usr/local/share/ca-certificates/
# Add the certificate to the ca-certificates trusted store
root@template:/# update-ca-certificates
# Enable the creation of home directories for LDAP users
root@template:/# pam-auth-update --enable mkhomedir
# Create the SSSD configuration file
root@template:/# nano /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
domains = linfra.loc
[domain/linfra.loc]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.linfra.loc
cache_credentials = True
ldap_search_base = dc=linfra,dc=loc
# Set the appropriate permissions on the sssd.conf file
root@template:/# chmod 0600 /etc/sssd/sssd.conf
# Edit the /etc/ldap/ldap.conf file to enable SSL
root@template:/# nano /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-provider.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
ssl start_tls
ssl on
TLS_CACERT /etc/ssl/certs/ca-certificates.crtThe machine should be ready to authenticate to the LDAP server over TLS/SSL. To test this, I can run a few commands.
# Test ability to connect to the LDAP server using StartTLS
root@template:/# ldapwhoami -x -ZZ -H ldap://ldap.linfra.loc
anonymous
# Test the ability to connect to the LDAP server using LDAPS
root@template:/# ldapwhoami -x -H ldaps://ldap.linfra.loc
anonymousIf both of the commands above resulted in ‘anonymous’, indicating that you connected anaonymously and that there was no issue with the connection or TLS/LDAPS configuration or certificate, you can test if authenticating as a user in your directory works as expected. This assumes that you have already created a user and group in your directory with a password for these purposes.
# Login to the template as an LDAP user
root@template:/# login
template login: testuser
password: ******
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 6.0.12-76060006-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Introducing Expanded Security Maintenance for Applications.
Receive updates to over 25,000 software packages with your
Ubuntu Pro subscription. Free for personal use.
https://ubuntu.com/pro
Last login: Fri Jan 27 17:35:18 UTC 2023 on pts/1Looking at the output above, I was successfully able to login to the console using the user ‘testuser’ which I had previously created in my LDAP directory for testing purposes. I now have properly configured LDAP authentication for the template machine, lets go ahead and configure Kerberos as well.
Add Kerberos
As mentioned in the intro to this article, I have also setup a Kerberos server in my lab. While LDAP authentication is great – I wanted to go all out on the security (and complexity) so I am able to learn how all of these components work together. Next, I will tackle configuring my template machine to also use Kerberos in conjunction with LDAP.
Before I am able to get any of this working, there are 2 prerequisites that have to happen in this order on the LDAP server and the Kerberos server respectively.
- Grant the Kerberos principals access to the OU in which the user(s) that you want to enable Kerberos for reside. This is done on the LDAP server.
- Add Kerberos attributes (including password) to the user in question. This is done on the Kerberos server.
#### OPERATION PERFORMED ON LDAP SERVER ###
# Create the LDIF file to set the appropriate permissions on the OU
jason@ldap:~$ vi krb5-update-acls-ou.ldif
dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {4}to dn.subtree="ou=users,dc=linfra,dc=loc"
by dn.exact="uid=kdc-service,dc=linfra,dc=loc" read
by dn.exact="uid=kadmin-service,dc=linfra,dc=loc" write
by * break
# Set the appropriate permissions on the OU for Kerberos accounts
jason@ldap:~$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f krb5-update-acls-ou.ldif
### OPERATION PERFORMED ON KERBEROS SERVER ###
jason@kdc:~$ sudo kadmin.local
kadmin.local: addprinc -x dn="uid=labmin,ou=users,dc=linfra,dc=loc" labmin
No policy specified for [email protected]; defaulting to no policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" created.It is time to turn our attention to the client as it is also going to require some configuration before it is able to authenticate against the LDAP server using Kerberos.
# Install the necessary packages and answer questions about Realm
root@template:~# apt install krb5-user sssd-krb5
# Add Kerberos information to the SSSD configuration
root@template:~# nano /etc/ssd/sssd.conf
[sssd]
config_file_version = 2
domains = linfra.loc
[domain/linfra.loc]
id_provider = ldap
auth_provider = krb5
ldap_uri = ldaps://ldap.linfra.loc
cache_credentials = True
ldap_search_base = dc=linfra,dc=loc
krb5_server = kdc.linfra.loc
krb5_passwd = kdc.linfra.loc
krb5_realm = LINFRA.LOC
cache_credentials = true
# Restart the SSSD service
root@template:~# systemctl restart sssd.service
# Test your configuration, ensuring you are able to login with Kerberos
root@template:~# login
template login: testuser
Password:
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 6.0.12-76060006-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Introducing Expanded Security Maintenance for Applications.
Receive updates to over 25,000 software packages with your
Ubuntu Pro subscription. Free for personal use.
https://ubuntu.com/pro
Last login: Fri Jan 27 19:40:49 UTC 2023 from 10.130.115.1 on pts/2If all went well with the above procedure, I will have a client leveraging either LDAP + Kerberos to authenticate. You will have to repeat the process to granting the Kerberos principals access to the OU where users reside on any new OU that you create for users in the future. You will also have to add the Kerberos attributes to each newly created user that you intend to have leverage Kerberos to authenticate.
Helpful Links
Building these configuration often requires reading documentation and finding other posts with useful information. I used some vendor resources and other documentation to get this configuration functioning properly.
