FreeBSD 5.1 can be configured as a DAS client without too much difficulty. FreeBSD 4.8 uses Kerberos IV by default, and manual installation of PAM and other components is necessary to make a working Kerberos V client. For this reason, I will only cover FreeBSD 5.1 and higher.

FreeBSD 5.1 comes with Kerberos V client programs as the default, which suits our purpose well. Althought the "ports" collection includes MIT Kerberos 1.2.8, we do not need to install this. A standard install should result in a Heimdal Kerberos V implementation that is ready for use. However, between using the Heimdal version and FreeBSD instead of Linux, there are a few quirks, which are primarily related to kadmin, PAM, and ypbind for NIS.


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.1, all of the necessary binaries are in place. This includes ypbind, kinit, klist, kdestroy, kpasswd, pam_krb5, man pages, etc. You can check that Heimdal is installed with the following command: pkg_info heimdal-0.5.1. 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, lets 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. Here are what the two config files need to look like:


# $FreeBSD: src/etc/pam.d/login,v 1.15 2003/04/30 21:57:54 markm Exp $
# PAM configuration for the "login" service

# auth
auth		required		
auth		sufficient
auth		required		try_first_pass

# account
account		required
account		required
account		sufficient
account  	required

# session
session		required		no_fail

# password
password	required		no_warn


# $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $
# PAM configuration for the "sshd" service

# auth
auth		required		no_warn
auth		sufficient		no_warn try_first_pass
auth		required		no_warn try_first_pass

# account
account 	required
account		required
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 .

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:


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:

leo# ypwhich -m

leo# ypcat hosts	 oscar		 genuity  printer	 defgate		 genuity-pri		 genuity-alt
leo# yppoll hosts.byname
Map hosts.byname has order number 1066724878. Tue Oct 21 16:27:58 2003
The master server is

leo# 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    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          -          unknown
    100007    2    tcp          -          unknown
leo# netstat -a | grep rpc
tcp4       0      0  *.sunrpc               *.*                    LISTEN
tcp6       0      0  *.sunrpc               *.*                    LISTEN
udp4       0      0  *.sunrpc               *.*                    
udp6       0      0  *.sunrpc               *.*                    
c20c408c stream      0      0 c20d97fc        0        0        0 /var/run/rpcbind.sock

leo# ps -aux | grep bind
root    304  0.0  0.6  1420 1064  ??  Ss    2:13PM   0:00.04 /usr/sbin/rpcbind
root    307  0.0  0.5  1272  944  ??  Is    2:13PM   0:00.05 /usr/sbin/ypbind -s -S,das-m,das-s -m

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:

leo# kinit -p kitty@KERB.ORG
Password for kitty@KERB.ORG: 
leo# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: kitty@KERB.ORG

Valid starting     Expires            Service principal
10/30/03 14:41:10  10/31/03 00:41:07  krbtgt/KERB.ORG@KERB.ORG

leo# kdestroy
leo# klist
klist: No credentials cache found (ticket cache 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:

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

leo# mkdir /home/kitty

leo# chown kitty:labuser /home/kitty
leo# ls -l /home/kitty
drwxr-xr-x  2 kitty    labuser  512 Oct 30 14:42 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 5.1.

Note 6 - Disk quotas for DAS users were not tested, as enabling disk quotas requires a kernel recompile.

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 include nscd.

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 temporarily removing 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 will 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.


FreeBSD Handbook
FreeBSD Handbook: NIS
FreeBSD Handbook: Kerberos 5