FreeBSD 5.2.1 can be configured as a DAS client without too much difficulty. Versions of FreeBSD prior to 5.0 use Kerberos 4 by default, and manual installation of PAM and other components is necessary to make a working Kerberos V client. The main differences between these instructions and the instructions for FreeBSD 5.1 are mainly component versions and the layout of the PAM config files.

FreeBSD 5.2.1 comes with Kerberos V client programs as the default, which suits our purpose well. Unfortunately, the Kerberos programs and libraries are based on the Heimdal Kerberos distribution. Although this will work as a basic client, programs like kadmin will not work with the MIT Kerberos KDCs. There are some other inconsistencies with client user programs. We will first describe how to configure a functioning Heimdal DAS client, then we will cover an optional procedure to replace the programs with MIT Kerberos V version 1.3.1. A standard install should result in a Heimdal Kerberos V implementation that is ready for use.


These FreeBSD DAS client instructions assume the following:

The last point is VERY important. If you are running telnet, ftp, rlogind, apache, etc. with those services configured to allow authentication of users with plaintext over the network, there is not much point in using Kerberos for secure authentication. The assumption is that you will only be logging in remotely via SSH2 or SSL/TLS encrypted sessions. This does NOT, however, preclude you from using Kerberized versions of TELNET or RLOGIN as long as they are configured to disallow plaintext authentication methods.

Step-by-step Instructions

Step 1: Software Installation

Fortunately, if you do a standard install of FreeBSD 5.2.1, all of the necessary binaries are in place. This includes ypbind, kinit, klist, kdestroy, kpasswd, pam_krb5, man pages, etc. These are part of Heimdal 0.6. The pam_krb5 libraries should be in /usr/lib.

Step 2: Modify Configuration Files

Here is a list of the config files that must be modified:

Before you do anything else, backup the orginal config files to another directory, or add the .org extension to them.

First, let's add entries in /etc/hosts for the DAS servers. These will be used by ypbind (the NIS client): das-m das-s

Now, let's add the necessary items to the /etc/rc.conf file to allow ypbind (the NIS client) to start automatically on boot:

nis_client_flags="-s -S,das-m,das-s -m"

The NIS client flags are needed so that ypbind will use unicasts to our DAS servers rather than simply broadcasting to discover them.

The next item is the /etc/nsswitch.conf file. By default, it does not exist. You will need to create the file. Here is what it should look like:

# /etc/nsswitch.conf

passwd:     files nis 
shadow:     files
group:      files nis

hosts:      files dns nis

Next, we need to edit or create the /etc/krb5.conf file. It should look like this:

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 ticket_lifetime = 24000
 default_realm = KERB.ORG
 dns_lookup_realm = false
 dns_lookup_kdc = false

  kdc =
  kdc =
  admin_server =
  default_domain =

[domain_realm] = KERB.ORG = KERB.ORG

 profile = /var/kerberos/krb5kdc/kdc.conf

 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false

Now, all we have left is the PAM configuration. The "system" config file is a change from FreeBSD 5.1. It is similar to the "system-auth" config file that is used in Red Hat. The "system" file is referenced by numerous other PAM config files in /etc/pam.d, so it affects a number of applications. Here are what the two config files need to look like:


# $FreeBSD: src/etc/pam.d/system,v 1.1 2003/06/14 12:35:05 des Exp $
# System-wide defaults, modified by Van for DAS client use
# auth
auth            sufficient             no_warn
auth            required             no_warn try_first_pass
# account
account         required
account         sufficient
account         required
# session
session         required          no_fail
#session        optional
# password
password        required             no_warn try_first_pass


# $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $
# PAM configuration for the "sshd" service, modified by Van for DAS
# auth
auth            required          no_warn
auth            sufficient             no_warn
auth            required             no_warn try_first_pass
# account
account         required
account         sufficient
account         required
# session
session         required
# password
password        required             no_warn try_first_pass

Depending on how you use your FreeBSD system, you may also want to modify some of the other PAM config files in /etc/pam.d . In fact, the biggest difference between different version of Unix and GNU/Linux is in the PAM modules and configurations. Some trial-and-error testing will almost certainly be necessary.

One additional step:   Most DAS users will have /bin/bash listed as their default shell. This is not installed by default with FreeBSD 5.1, and if you do install it, it will be in /usr/local/bin/bash. To solve this issue, you should use the sysinstall tool to install the BASH shell, then make a soft link to it like this:

ln -s /usr/local/bin/bash /bin/bash

If you do not do this, then any DAS user that has /bin/bash listed as his shell will not be able to login to the FreeBSD system.

Step 3: Reboot

The simplest way to get ypbind running is to restart the server. When it is up and running again, login as a local user. If your local user login seems to hang, wait for a few minutes and it will eventually let you in. This can happen if there is a problem binding to the NIS server.

Step 4: Make Sure System Clock is Synchronized

You can setup time synchronization by setting up ntpd, or by using ntpdate. Please refer to the Client Time Synchronization section for details.

Step 6: Test

First, make sure that the host is able to bind to the NIS domain. This can be done with the following command:

bsd521# ypwhich

You should see "das-m" or "das-s". You can test NIS client functionality with the following additional commands:

If you are not having any luck with this, use the ps and netstat commands to check that the portmapper and ypbind are both running.

NIS testing example:

bsd521# ypcat hosts   oscar       genuity   printer    defgate  rat       genuity-alt

bsd521# yppoll hosts.byname
Map hosts.byname has order number 1082010515. Thu Apr 15 14:28:35 2004
The master server is

bsd521# rpcinfo
   program version netid     address                service    owner
    100000    4    tcp          -          superuser
    100000    3    tcp          -          superuser
    100000    2    tcp          -          superuser
    100000    4    udp          -          superuser
    100000    3    udp          -          superuser
    100000    2    udp          -          superuser
    100000    4    tcp6      ::.0.111               -          superuser
    100000    3    tcp6      ::.0.111               -          superuser
    100000    4    udp6      ::.0.111               -          superuser
    100000    3    udp6      ::.0.111               -          superuser
    100000    4    local     /var/run/rpcbind.sock  -          superuser
    100000    3    local     /var/run/rpcbind.sock  -          superuser
    100000    2    local     /var/run/rpcbind.sock  -          superuser
    100007    2    udp          -          superuser
    100007    2    tcp           -          superuser
bsd521# netstat -a | grep rpc
tcp4       0      0  *.sunrpc               *.*                    LISTEN
tcp6       0      0  *.sunrpc               *.*                    LISTEN
udp4       0      0  *.sunrpc               *.*
udp6       0      0  *.sunrpc               *.*
c6c67ec4 stream      0      0 c6c6cc30        0        0        0 /var/run/rpcbind.sock

bsd521# ps -aux | grep bind
root      317  0.0  0.1  1432 1076  ??  Ss   11:53AM   0:00.16 /usr/sbin/rpcbind
root    23460  0.0  0.1  1448 1204  ??  Is   12:48PM   0:00.01 /usr/sbin/ypbind -s -S,d
root    23742  0.0  0.0   324  212  p0  R+    1:04PM   0:00.00 grep bind

Next, make sure than you can login as a DAS user to the Kerberos realm with kinit. You should do this as a local user, root or another one will work just as well. Here is an example:

bsd521# kinit -p kitty
kitty@KERB.ORG's Password:

bsd521# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: kitty@KERB.ORG
  Issued           Expires          Principal
May 10 13:04:49  May 10 19:44:48  krbtgt/KERB.ORG@KERB.ORG

bsd521# kdestroy

bsd521# klist
klist: No ticket file: /tmp/krb5cc_0

Now you know that the Kerberos client programs are working correctly. Next, we will make sure that NIS, PAM, and Kerberos together can login a user from a console or SSH login. You will do this by obtaining a console login prompt. Enter the user "kitty" and then your Kerberos password. You should be logged on. Type klist and make sure that you have a Kerb ticket. Use the kpasswd command to change your Kerb password. Now logout, and try logging back in. You should have no problems.

You will also want to make sure that you can login as a local user or as root from the console. Now, from a remote machine, SSH to the FreeBSD host and login as a local user. Then logout, and login as user "kitty". You should be able to login with your Kerb password.

Step 7: Create Home Directories for DAS Users (optional)

Unlike most major Linux distributions, FreeBSD 5.1 does not come with the pam_mkhomedir PAM module. This means that a DAS user who logs in for the first time is dropped into the / directory and has no place to store files. The local administrator may need to make a directory for the user under /home. As root, here is how you would do that:

bsd521# id kitty
uid=6000(kitty) gid=50000(labuser) groups=50000(labuser)

bsd521# mkdir /home/kitty

bsd521# chown kitty:labuser /home/kitty

bsd521# chmod 750 /home/kitty

bsd521# ls -ld /home/kitty
drwxr-x---  2 kitty  labuser  512 May 11 09:23 /home/kitty

If you have skeleton files that you must copy into all of your home directories, then you should go ahead and do that now. Make sure that you set the permissions correctly.

Operational/Performance Notes

Note 1 - The Heimdal version of kadmin will not work with an MIT Kerb5 KDC. You will not be able to use this program.

Note 2 - For some reason, a DAS user logging into the FreeBSD host via SSH will be authenticated via Kerberos, but no ticket will be cached. If you need this functionality, you will have to run "kinit" after logging in.

Note 3 - DAS users who login from the console will automatically get a ticket and have it cached. However, it will not be automatically destroyed during logout. If you want to do this, you would need to add "kdestroy" to the logout script, which depends on what shell you are using.

Note 4 - DAS users must change their passwords with kpasswd, not with passwd.

Note 5 - The getent command is not installed with FreeBSD.

Note 6 - Disk quotas for DAS users were tested. They were enforced whether the NIS servers were available or not.

Note 7 - FreeBSD does come with a Kerb/encrypted telnet client that will work with a Kerberized telnet daemon. I tested this and it worked fine. The installed rlogin client, however, does not include Kerb/encryption support.

Note 8 - FreeBSD does not come with the Name Server Cacheing Daemon, NSCD. It is also not in the ports collection.

Tests were conducted with both DAS servers available, DAS-M unavailable, and both DAS servers unavailable. When DAS-M is unavailable, a short delay is noticed when logging in, running ls -l, etc. When both DAS servers are not available, DAS (Kerb) user logins fail, and local logins are delayed up to 2 minutes. This is because various programs are attempting to look up information via NIS, and NIS is not available. If work needs to be done while disconnected from the DAS servers, you may want to consider stopping ypbind by entering the /etc/rc.d/ypbind stop command. You may also want to temporarily remove or modify the /etc/nsswitch.conf file.

Note on at and cron jobs: If the DAS servers are both unavailable while a DAS user's at or cron jobs are still pending, the jobs may fail. E-mail addressed to a local account may also fail, since from the host's perspective, the user does not exist. When the DAS servers are available again, the DAS user may need to delete his crontab and re-install it. I was able to test at jobs and cron jobs for DAS users, with and without the DAS servers available. It worked well, and I did not have to delete and reset any cron jobs or restart the cron daemon.

Optional Procedure to Install MIT Kerberos 5

An ordinary FreeBSD 5.2 install automatically includes a number of Heimdal Kerberos 5 components. They are not listed as individiual packages, so they cannot be removed with the pkg_delete command. You can install MIT Kerberos 5 from the ports collection. The binaries will be placed in /usr/local/bin and /usr/local/sbin. You can then move all of the Heimdal binaries from /usr/bin and /usr/sbin to a backup directory. The new binaries will then be used instead.

In order to install MIT Kerberos 5 from the ports collection, you need to do this:

bsd521# cd /usr/ports/security/krb5

bsd521# make install clean

This will install the following programs:

In /usr/local/bin:


In /usr/local/sbin:


You will now need to move the Heimdal versions of these programs from /usr/sbin and /usr/bin to some backup directory, then test. I tested Kerberized versions of FTP, RCP, RLOGIN, and TELNET against an application server, and they all worked. SSH logins, local logins, kinit, kdestroy, kpasswd, and klist all worked. In addition, kadmin worked correctly.

Perhaps there is a more elegant way to install the MIT Kerberos 5 programs during OS installation?


FreeBSD Handbook
FreeBSD Handbook: NIS
FreeBSD Handbook: Kerberos 5