Kerberos and LDAP Client on OpenBSD 7.3

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that user is always user on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

Overview

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

1. Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
2. Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
3. Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

Prerequisites

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

• A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
  • An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
  • A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
  • Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
• The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
• An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

Note: This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

Limitations

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the kadmin command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the ypldap program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

1. Kerberos Client

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running kinit. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open /etc/login.conf in a text editor, and look for the default block (begins with default:\). Add /usr/local/heimdal/bin to the path, so that at this point the block should look like this:

default:\
        :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
        :umask=022:\
        :datasize-max=1024M:\
        :datasize-cur=1024M:\
        :maxproc-max=256:\
        :maxproc-cur=128:\
        :openfiles-max=1024:\
        :openfiles-cur=512:\
        :stacksize-cur=4M:\
        :localcipher=blowfish,a:\
        :tc=auth-defaults:\
        :tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to /etc/rc.conf.local:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the kinit - in other words, it's in their path.

2. LDAP Client

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

Install the LDAP Client

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

Configuring the LDAP Client

Edit /etc/openldap/openldap.conf. The uncommented lines should look something like this:

BASE            dc=example,dc=net
URI             ldap://krbldapsrv.example.net

SASL_MECH       GSSAPI

Change dc=example,dc=net and krbldapsrv.example.net to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

Testing the LDAP Client

Log in with a KRB/LDAP user. Get a Kerberos ticket using kinit, entering the user's password when prompted. Next, verify that ticket exists using klist. You should then be able to access the LDAP server, for instance using the ldapwhoami program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password: 
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
        Principal: ben@EXAMPLE.NET

  Issued                Expires               Principal
May 15 12:57:30 2023  May 16 12:57:30 2023  krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

3. Configuring System Logins

The above sections allow a user to get a Kerberos ticket and use it to retrieve information from LDAP. Now, we need to allow the system to do this so that a user can actually log in at the console or via a display manager.

Kerberos Authentication

First, we need to configure the system to check passwords against Kerberos. Edit /etc/login.conf and look for the same default:\ block as in Section 1, and edit it to add the line :auth=-krb5-or-pwd:\ third from the bottom. The whole block should now look like this:

default:\
        :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
        :umask=022:\
        :datasize-max=1024M:\
        :datasize-cur=1024M:\
        :maxproc-max=256:\
        :maxproc-cur=128:\
        :openfiles-max=1024:\
        :openfiles-cur=512:\
        :stacksize-cur=4M:\
        :localcipher=blowfish,a:\
        :auth=-krb5-or-pwd:\
        :tc=auth-defaults:\
        :tc=auth-ftp-defaults:

LDAP Authorization

This allows the system to retrieve information from LDAP about users and groups. OpenBSD does not directly support doing this with LDAP, but it does support network information services (NIS), and provides a bridge called ypldap to interface with an LDAP server.