Kerberos and LDAP Client on OpenBSD 7.3: Difference between revisions

From Unixcat.net Wiki
Jump to navigation Jump to search
Line 77: Line 77:
Install the LDAP client with GSSAPI support as follows:
Install the LDAP client with GSSAPI support as follows:


  openbsd# pkg_add -iv
  openbsd# pkg_add -iv openldap-client
 
Select the option for the package supporting GSSAPI and hit Enter.  Next, edit <code>/etc/openldap/openldap.conf</code>.  The uncommented lines should look something like this:
 
BASE            dc=example,dc=net
URI            ldap://krbldapsrv.example.net
SASL_MECH      GSSAPI
 
Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively

Revision as of 04:55, 15 May 2023

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.
  • The LDAP server configured with an SSL server certificate, and a client certificate for 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. Next, 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