Kerberos and LDAP on OpenBSD 6.2

I recently started setting up Kerberos and LDAP for my home network.  While I don’t have a ton of users, it’s handy to be able to centralize account information and do single sign-on.  So far all I really have for clients are a server computer, laptop, and Raspberry Pi, but I find it quite handy even if it was kind of a pain to set up.

I have an older PC in the basement I use mostly when I need to work on the network or some other project and just need to quickly grab a web page or SSH into something.  I had been running Ubuntu Mate on this, since I like the Mate desktop and wanted to give this distro a try.  It ran, but not well.  The desktop was slow,  and it would take a minute to start something like Firefox.  This machine is 3 GHz Pentium 4 dual core with 1 GB of RAM.

I also use OpenBSD on and off, and like it a lot.  Since I was curious about how it does on the desktop I decided to give it a try, using the Lumina desktop environment.  It works well, and it feels noticeably faster than Ubuntu did on this hardware.  Initially I got it going just to get a quick desktop, but then I started thinking about getting it into my Kerberos realm.

This turned out to be a little tricky.  For one thing, OpenBSD uses Heimdal Kerberos, as opposed to MIT Kerberos, which the rest of my setup uses.  For another, doesn’t use PAM, like all (most?) GNU/Linux distros do, as well as FreeBSD.  RedHat’s SSSD is also not present, which has been a godsend on the other platforms.  OpenBSD can authenticate to sources such as Kerberos and LDAP, however, though there isn’t a whole lot floating around online about it (though of course the man pages help out a lot).  There’s also no support for authorization (eg, group information, UID number) for anything besides local files and NIS, which presents a further challenge.

A Quick Little Guide

I thought I’d post this here in cases it helps someone down the line, or in case I have to do this again myself.  🙂  I’ve pieced this together from information found online, as well as man pages.  Note that this doesn’t cover setting up the Kerberos/LDAP server(s), which is another topic on which there are other guides.  I used a combination of this guide for Debian, and this one for Ubuntu (even though my KDC runs Debian).  At the moment the exact details of the setup aren’t terribly important, but you should have some kind of Kerberos/LDAP implementation that authenticates users.

I just want to point out here, that although Active Directory is in fact one Kerberos/LDAP implementation, I don’t really have much experience with it, and this guide will not directly concern it or any peculiarities it may have.  In theory a lot of what you see here should be applicable, and hopefully it will be helpful.  In my travels I found this, which may be helpful if that’s what you’re trying to do.

Aside from the server, you should obviously have an OpenBSD system you want to have as your authentication/authorization client.  Have some test users kicking around helps too, both some local users on your OpenBSD system as well as a couple configured in Kerberos/LDAP to test authentication there.

I’m using OpenBSD 6.2, i386, but I think this should work on other platforms as well(?), particularly amd64.  Now a word of caution: this guide requires modifying some system files.  I myself screwed up at one point, causing my system to boot but not allow anyone to log in.  I recommend not only making backups of relevant files, but also reading a bit about single user mode.  Take a look at the root password reset guide in the OpenBSD handbook; you can also use single user mode to fix system files.  For running an editor, you may also want to take a look at this if you get any errors in single user mode.


First, we’ll install Kerberos, which will handle authentication.  That is, this will check a user’s password and verify they are who they say they are.  I assume that you have a realm, EXAMPLE.COM, with a KDC/admin server

Note that in this guide, in a code snippet meant to be run at the command line, # indicates the root prompt.  However, in a file, # will indicate a comment.

To start, we’ll need to install some packages.  From the command prompt:

# pkg_add heimdal heimdal-libs login_krb5

Next, you’ll want to modify your path so that you actually have access to the different Kerberos tools.  In .profile, look for that PATH line and add /usr/local/heimdal/bin like this:


You may want to make the same modification in /etc/skel/.profile, so that it’s propagated to new users.  Next, modify /etc/rc.conf.local and add teh shlib_dirs line.  I had made other modifications in setting up my desktop, so for me that file now looks like this:


The reason for that is that Heimdal is installed under /usr/local/heimdal, which is also where its shared libraries are.  This tells the rest of the system where they are.  (You may have to reboot after saving this change.)

Next, we’ll start putting in some Kerberos details.  In the file /etc/kerberos/krb5.conf, modify it to reflect your situation (ie, your own realm and kdc/admin server):

# $OpenBSD: krb5.conf,v 1.1 2014/07/13 14:10:13 ajacoutot Exp $
# See krb5.conf(5) and the heimdal info(1) page for more information.

# local realm(s)
default_realm = EXAMPLE.COM

# list of KDC(s) for this realm
kdc =

# admin server for this realm
admin_server =

default_domain = EXAMPLE.COM



# default salt string
default_keys = v5

# log to syslog(3)

By this point you should be able to use tools like kinit, klist, etc. on the OpenBSD client.  What we want to do now is set up a host principal for this machine, and a keytab for it.  At this point, I would like to mention that I had a problem with this on OpenBSD: normally I create the principal by logging into my KDC, then creating the principal in kadmin, then logging into the client and running kadmin as root.  Because of the krb5.conf configuration, you basically use kadmin to copy the principal from the KDC to the local keytab.  Unfortunately, when I tried to do this from my OpenBSD machine it hung.  I’m not sure what was going on, or if it was some kind of Heimdal vs MIT Kerberos issue, but I ended up having to copy the keytab over manually.

Log in to your KDC, and run the following.  Note that in the addprinc command I have the -x dn=”uid..” line – this is because my KDC uses LDAP as its backend (not just for authorization), and I keep the principal with other information about that computer.  (See the Ubuntu guide I linked earlier for more information.)  You can leave that out if you don’t do this.

The session should look something like this (again, my KDC is running MIT Kerberos):

root@kerberos:~/kdc# kadmin -p kerberosadminuser
Authenticating as principal kerberosadminuser with password.
Password for kerberosadminuser@EXAMPLE.COM: 
kadmin: addprinc -randkey -x dn="uid=openbsdclienthostname$,ou=computers,dc=example,dc=com" host/
WARNING: no policy specified for host/; defaulting to no policy
Principal "host/" created.
ktadd -k /path/to/some/file.keytab host/

The above copies the host principal to /path/to/some/file.keytab, which you need to then transfer to the client – rename it to /etc/heimdal/krb5.keytab.  Transfer it using a secure method, like SSH or a thumb drive.  Assuming you put it in /root:

# mv /root/file.keytab /etc/heimdal/krb5.keytab
# chown root:wheel /etc/heimdal/krb5.keytab
# chmod 600 /etc/heimdal/krb5.keytab

At this point, you should be able to get a Kerberos principal yourself:

# klist
klist: No ticket file: /tmp/krb5cc_0
# kinit krbuser
krbuser@EXAMPLE.COM's Password: 
# klist
Credentials cache: FILE:/tmp/krb5cc_0
 Principal: krbuser@EXAMPLE.COM

Issued Expires Principal
Mar 4 15:48:38 2018 Mar 5 15:48:38 2018 krbtgt/EXAMPLE.COM@EXAMPLE.COM

Next, we want to be able get that principal when we log in.  Earlier, we installed login_krb5, which will do this (along with of course letting us log into the system without a passwd entry).

Edit /etc/login.conf, and look for the default:\ section as shown below:

:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\

The line to add is “:auth=-krb5-or-pwd:\” just above “:tc=auth-defaults:\”.  This line allows you to use Kerberos as a login mechanism, but falls back to checking local files if that fails.

This should be about it – you can test authentication to a Kerberos account, but note that we don’t have authorization.  In other words, the system still has to look to local files for things like user and group information.  To test now, create a local account with a home directory, group, etc. in OpenBSD (as root):

# useradd krbuser

Follow the prompts that come up.  The password doesn’t really matter, just use something different than what you set up for the Kerberos principal.  Then, log in to the console as that user using the Kerberos principal’s password.  After logging in, you should be able to run klist and see that user’s principal.  (If you get a “Command not found” or similar error, make sure that /usr/local/heimdal/bin is in your path, see above.)


Assuming you got the Kerberos part working, now might be a good time to take a break, get a fresh coffee, etc.

As I mentioned before, LDAP is used for authorization, that is user info like groups, login shells, etc.  Unfortunately, OpenBSD doesn’t actually support using LDAP for authorization, only Network Information System (NIS, aka YellowPages or yp, which most of the tools are named for).  Luckily, there’s a translator we can use that comes with the base system, ypldap.  This basically makes the LDAP directory look like a YP (NIS) server.

I couldn’t find much online about using this with OpenBSD 6.2, but I think I got it working.  I found two pages on this, both of which are older.  Both of these start by talking about login_ldap, which I ended up installing, but which isn’t really needed.  That’s if you want to authenticate to LDAP (ie, if that’s where you’re storing your passwords).  In our case, that’s already taken care of by login_krb5.

To start, create /etc/ypldap.conf.  I recommend copying the example:

# cp /etc/examples/ypldap.conf /etc/ypldap.conf

There is another caveat – on my Linux clients, I use GSSAPI with the host principal to authenticate to the LDAP database.  On OpenBSD, ypldap does not support this (that I could tell).  This means you’ll need a user that can just bind to LDAP by itself, for instance using the userPassword attribute.  This user needs to be able to read through your directory to get user/group information.  Also, while I don’t have it set up here, you should probably be using SSL/TLS with your LDAP server.

Now, edit this file like the following (I’ve added some of my own comments) to reflect your own setup:

# $OpenBSD: ypldap.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $

domain "" #This is just the name of your realm
interval 120 #How often to pull data from the LDAP database, in seconds
provide map "passwd.byname"
provide map "passwd.byuid"
provide map "group.byname"
provide map "group.bygid"
provide map "netid.byname"

directory "" { #This is the machine hosting your LDAP directory
# directory options
binddn "uid=openbsdclienthostname$,ou=computers,dc=example,dc=com" #User to bind to LDAP as
bindcred "mypassword" #Password for above user
basedn "dc=example,dc=com"
# starting point for groups directory search, default to basedn
groupdn "ou=groups,dc=example,dc=com" #Change to reflect your setup

# passwd maps configuration (RFC 2307 posixAccount object class)
passwd filter "(objectClass=posixAccount)"

attribute name maps to "uid"
fixed attribute passwd "*" #Can leave this as is, we check passwords with Kerberos
attribute uid maps to "uidNumber"
attribute gid maps to "gidNumber"
attribute gecos maps to "cn"
attribute home maps to "homeDirectory"
attribute shell maps to "loginShell"
fixed attribute change "0"
fixed attribute expire "0"
fixed attribute class ""

# group maps configuration (RFC 2307 posixGroup object class)
group filter "(objectClass=posixGroup)"

attribute groupname maps to "cn"
fixed attribute grouppasswd "*"
attribute groupgid maps to "gidNumber"
# memberUid returns multiple group members
list groupmembers maps to "memberUid"

Next, we configure the YP client.  I recommend taking a look at the relevant page in the FAQ, for reference.  Since we basically just set up an YP server, we want to tell the client where to find it:

# echo '' > /etc/defaultdomain
# echo '' > /etc/yp/

To have the system use the YP client, make the following changes to /etc/master.passwd and /etc/group:

# echo '+:*::::::::' >> /etc/master.passwd
# pwd_mkdb -p /etc/master.passwd
# echo '+:*::' >> /etc/group

The first line sets the YP domain, while the second tells the YP client to look to our own host for the server (ypldap).  Next, enable some services:

# rcctl enable portmap
# rcctl start portmap
# rcctl enable ypldap
# rcctl start ypldap
# rcctl enable ypbind
# rcctl start ypbind

In some of the other guides online, it was said that you had to edit /etc/rc.local to make sure that ypldap starts before ypbind.  For 6.2, I didn’t have to do this.

Now, you can reboot and check to make sure you have the above running:

# ps aux | grep yp
_ypldap 3982 0.0 0.1 540 1488 ?? Ip 4:55PM 0:00.01 ypldap: dns engine (ypldap)
_ypldap 85354 0.0 0.2 584 1608 ?? Ssp 4:55PM 0:00.01 ypldap: parent (ypldap)
_ypldap 56536 0.0 0.2 628 1600 ?? Ip 4:55PM 0:00.01 ypldap: ldap client (ypldap)
root 23124 0.0 0.1 384 960 ?? Ss 4:55PM 0:00.00 /usr/sbin/ypbind

You can also test lookup up user information using the id command:

# id krbuser
uid=5555(krbuser) gid=5555(krbuser) groups=5555(krbuser)

In the above, 5555 would be whatever uid/gid you set it up for.  (If you have the user from before, the one which was using the local OpenBSD files, you may want to use a different one to make sure you’re actually pulling from LDAP.)

Next test logging in with a Kerberos/LDAP user from the console.  Note that I did not look into creating users’s home directories automatically, so you’ll have to do that yourself.  (If I figure this out, I’ll post it, or if someone else knows, feel free to comment.)

Final Remarks

I like OpenBSD a lot, but this was kind of a pain.  Actually, it was a good learning experience, and it’s good to know that it’s possible.  I got to learn a little more about the internals, and once I started looking into it it wasn’t too bad, just different from what I’d been used to on Linux.  Let me know if you have any trouble with this, or if I missed anything (I’m putting this down partly from memory, after working on it on and off over a couple weeks.).

I did not manage to get Kerberized SSH working, that is being able to SSH to/from the OpenBSD client without entering a password.  I think this is because the builtin sshd doesn’t support it.  This might be something that could be changed by recompiling it, I’ll have to look into it in the future.

Ubuntu Directory

Right now I am on vacation, as my last post may indicate.  It is beautiful here, the beaches are nice, and the fresh air is a much welcomed diversion.  However, I still think about random projects and things, and hence I take a few minutes here and there to right them down or even make up a neat little blog post.

The subject of this post is something I have kicked around for a little while, but have recently resolved to try to take on.  Basically, the situation is this: if you haven’t figured it out, I am a GNU/Linux user (though I do use OpenBSD and occasionally FreeBSD for some things as well).  At home I have a few different machines that run Linux, including a small server, a desktop, and a laptop.  There are several others as well, but these are the ones I use mainly.  The thing is, I would love an easy way to manage users and permissions across them.  Basically, I’m thinking of something similar to a domain, like you might see in a Microsoft-based network.

Now, yes, of course you can join *nix machines to a Windows domain (or have one be a domain controller via Samba).  I don’t really have any Windows machines, though, nor do I want to buy/pirate a server version of Windows.  I could also use Kerberos and LDAP, and in fact I do use them.  They work well for me for the most part, but I said in the last paragraph that I wanted an easy way to admin the network.  If you follow one of the various online tutorials about getting the two going the process of setting this up isn’t actually that bad, but adding and removing users can be a bit of a pain.  I mean, it’s not really complicated, but you’d need to add the user to Kerberos, then to LDAP.  Then I guess you can use an LDAP browser to manage the rest.  But, it seemed to me like there should be some sort of GUI tool that would manage both, IE let you create a user and add them to some networked groups and whatnot.  I was thinking of the name while considering a networked version on Ubuntu’s user and groups tool, hence the name.  (In other words, it wouldn’t have to be Ubuntu-specific by any means.)

Now, yes, there are other projects that aim to accomplish this kind of thing, like FreeIPA.  And I won’t lie, that one looks pretty neat.  But it just seemed to me that just having a frontend to take care of some basic user/group stuff would help out a lot.  Especially if you already have a Kerberos/LDAP setup.  So, at some point in the future I am going to see what I can do with my idea, and maybe whip something up in Python and GTK.  I can’t make any guarantees right now, nor say when I will get to working on it, but we shall see.

As a final disclaimer, I am not what you would call an “IT professional”.  I program, and I’ve done quite a bit of work with *nix and networking, but this isn’t my normal gig.  I haven’t extensively used Active Directory, and so I’m not trying to clone it.  I just want an easier way to manage some users across my home networks (for a couple friends, the cats, etc.), but to have the option of still getting at the guts if I want.  Hell, maybe the best way to go about this is just a nice shell script anyway.