# [HOWTO] Kerberos for small networks, without LDAP or AD

## Bones

Please post comments and constructive criticism in this thread.

Simple Kerberos HOWTO

The purpose of this guide is to walk an admin through the steps needed to Kerberise a small network.  I wrote it because I couldn't find anything on the Internet that suited my needs.  All of the HOWTOs I found were for setting up industrial-strength, redundant solutions appropriate for a corporate network.  Those sorts of setups are fabulously capable, but they are massively over-engineered for a small network.  I was looking primarily for single sign-on (SSO) to my network services... and that's all.  I didn't need LDAP, didn't need NIS, and didn't want to integrate Windows AD into my network.

I'll try not to bore you with details of how Kerberos works, and instead stick with the practical matter of getting Kerberos up and running.  I assume basic knowledge of Kerberos terms and concepts.  If you don't know at least a little about Kerberos, go read up on it now.

The end product of this guide is a fully functional Kerberos realm, with:

A master KDC running on a Linux host without failover capability (no fault tolerance)

Single Sign-on (SSO) capability for network services, without having to remember or type in different passwords for each service

Windows clients directly integrated into the Kerberos realm without the use of Active Directory

Also covered is how to Kerberise the following services:OpenSSH

Samba file sharing

IMAP mail service with virtual users, courtesy of Dovecot

Why Kerberos?

I chose Kerberos because it has seen many years of development and deployment; it is mature.  It can be easily integrated into a network in stages, and can be set up to work transparently to the network users.  Many services have built-in support for Kerberos.  Basically, if it has GSSAPI capability, it can directly use Kerberos.  By extension, anything that supports SASL (which can interface with GSSAPI) can also authenticate with Kerberos.

Which Kerberos?

Several Kerberos implementations are available.  Possibly the best known is used by Microsoft Windows AD services.  On the open source side of things are the Heimdal and MIT packages.  This guide was developed while using the MIT-Kerberos package, version 1.5.2, on Gentoo Linux systems.  The necessary Gentoo packages are:

app-crypt/mit-krb5-1.5.2-r1

sys-auth/pam_krb5-20030601-r1

These packages should be installed on each Gentoo host on the network.

----------

## Bones

Required Infrastructure

Kerberos requires NTP and DNS.

NTP

Kerberos authentication is time sensitive.  The system times between the client and the server hosts must be synchronized, or at least nearly so.  Clock time discrepancies of more than 5 minutes (in the default configuration) will result in authenticaion failure.  No two machines keep time at the same rate, and so the clocks WILL drift apart without active intervention.  The easiest way to keep the clocks in sync is to use NTP on every host, either running as a daemon (preferred), or periodically as a cron job to make step adjustments to the system clock.

DNS

Kerberos makes heavy use of name services.  Almost every operation involves a lookup of some sort, so it is vital to have a healthy DNS in place.  Any misconfiguration or problem will result in a broken or partially functional Kerberos system.  Your DNS must be capable of forward and reverse lookups.  On each host, a name lookup must return the fully qualified domain name (FQDN).  THIS IS VITALLY IMPORTANT.  To check this, run this command on each host:

```
hostname -f
```

The output should be the FQDN of the host.  For example, if your host's name is "testbox", and your network's domain is "tiny.net", that command should return "testbox.tiny.net" and not just "testbox".  If you didn't get the FQDN, you need to fix the /etc/resolv.conf files, the /etc/hosts files, or maybe the /etc/nsswitch.conf files before proceeding.

One more thing about name resolution: Under no circumstances should a name lookup return 127.0.0.1, with the exception of localhost.

Most of the problems I encountered in implementing Kerberos were related to badly configured /etc/hosts files.  The easiest way to avoid name resolution problems is to prioritize DNS over hosts file lookups in /etc/nsswitch.conf.

Pre-Configuration

Add "kerberos" to your USE flags in /etc/make.conf, then do an emerge with --newuse to recompile the packages that can use Kerberos.

Before diving into a Kerberos configuration file, you must do a little planning.  First, figure out the name of your Kerberos realm.  Your realm name is the same as your network's domain name, in all uppercase letters.  For example, the realm name for the DNS domain "tiny.net" is "TINY.NET".  Kerberos is case sensitive, a fact that apparently escaped the Windows developers.

The second thing you must figure out is what crypto algorithms will be used by your Kerberos installation.  The default crypto types are Triple-DES and DES.  There are many alternative crypto choices.  Which one(s) you choose depend on what sort of Kerberos clients are on your network.  According the the documentation, Kerberos understands the following encryption types:

des-cbc-crc

des-cbc-md4

des-cbc-md5

des3-cbc-sha1

des3-hmac-sha1

des3-cbc-sha1-kd

des-hmac-sha1

aes256-cts-hmac-sha1-96

aes128-cts-hmac-sha1-96

rc4-hmac

rc4-hmac-exp

If your network has no Microsoft Windows clients, you may choose whichever crypto algorithms you wish.  By adding even one Windows client into your Kerberos realm, however, you are forced into using DES and/or Arcfour as one of your crypto methods.

The configuration files in this guide choose the strongest crypto algorithms available to Kerberos, while still retaining compatibility with Windows clients.  Linux clients will be configured to prefer 256-bit AES encryption, while Windows clients will use 128-bit Arcfour.

Configuration

For purposes of illustration, the configs in this guide are for a small, imaginary network with a DNS domain of "tiny.net", and a Kerberos realm of "TINY.NET".  Our Key Distribution Center (KDC) host will have a FQDN of kdcbox.tiny.net.  Your network will likely be different, so substitute names and such accordingly.

There are two parts to Kerberos configuration: one part is for the Kerberos server (KDC), the other is for Kerberised applications (clients).  The Kerberos server machine (kdcbox.tiny.net) should have both the server and client portions configured on it.  The other hosts on the network should only have the client portion configured.

This guide assumes that the Kerberos daemons are run as the root user on the KDC server, which how the Gentoo init scripts set it up.

Server Configuration

Kerberos uses two server daemons: one for the KDC, and one for administration of the Kerberos database (/usr/sbin/krb5kdc and /usr/sbin/kadmind, respectively).  They are both configured with one file, kdc.conf.  The files needed by the daemons, including kdc.conf, are kept in /var/lib/krb5kdc by default on a Gentoo system.  File locations are changeable from the default in kdc.conf, but there is a catch-22; the service daemons need to read kdc.conf first, which is looked for at /var/lib/krb5kdc/kdc.conf.  An alternate location for kdc.conf can be specified prior to executing the daemons like this:

```
export KRB5_KDC_PROFILE=/path/to/kdc.conf
```

Naturally, it is easiest to use the default locations.

*** WARNING: The 1.5.2-r1 ebuild for MIT Kerberos places a sample configuration file at /etc/kdc.conf.example.  The Kerberos daemons WILL NOT find a config file at /etc/kdc.conf without an exported KRB5_KDC_PROFILE variable.  THE INIT SCRIPTS DO NOT SET THIS VARIABLE.  A misplaced kdc.conf will result in puzzling behavior from your KDC, and may not produce any error messages to alert you.  The best way forward is to use the default /var/lib/krb5kdc/kdc.conf location.  YOU HAVE BEEN WARNED. ***

The KDC daemon, krb5kdc, starts with sensible defaults for most options.  As a result, the kdc.conf for our TINY.NET realm is short:

```

[realms]

   TINY.NET = {

      max_life = 16h 0m 0s

      max_renewable_life = 7d 0h 0m 0s

      master_key_type = aes256-cts-hmac-sha1-96

      supported_enctypes = aes256-cts-hmac-sha1-96:normal rc4-hmac:normal

      kdc_supported_enctypes = aes256-cts-hmac-sha1-96:normal rc4-hmac:normal

   }

```

If your network has no Windows clients, the rc4-hmac types may be deleted from the *_enctypes lines.

Next, create an administration ACL file at /var/lib/krb5kdc/kadm5.acl with the following contents:

```
*/admin@TINY.NET   *
```

This file determines Kerberos database permissions when a user logs into the administration daemon, kadmind.  For the TINY.NET realm, any principal with a name like "user/admin@TINY.NET" gets full access to the database.  Check the permissions on this file, it should not be writable except by root.

Client Configuration

Every host in the TINY.NET realm has an identical /etc/krb5.conf:

```

[libdefaults]

   default_realm = TINY.NET

   default_tkt_enctypes = aes256-cts-hmac-sha1-96

   default_tgs_enctypes = aes256-cts-hmac-sha1-96

   permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac

   forwardable = true

[realms]

   TINY.NET = {

      admin_server = kdcbox.tiny.net

      kdc = kdcbox.tiny.net

      }

[domain_realm]

   .tiny.net = TINY.NET

   tiny.net = TINY.NET

[logging]

   kdc = SYSLOG

   admin_server = SYSLOG

   default = SYSLOG

```

In [libdefaults], the realm name and encryption types are set.  Again, if you have no Windows hosts, feel free to omit the rc4-hmac type.  In [realms], the FQDN of the master KDC server and the admin server is specified for TINY.NET.  Both daemons will be running on kdcbox.  It is possible to use the IP address insead of the hostname here; functionally, it makes no difference.  The [domain_realm] section provides mappings between domain names and Kerberos realms.  The [logging] section only affects the KDC server.  Here, the krb5kdc daemon is told to send everything to the system logs.

----------

## Bones

Creating the Kerberos Database

Create the Kerberos database using the kdb5_util program.  As root:

```
kdcbox ~ # kdb5_util create -r TINY.NET -s
```

You will be prompted for a password for the master key.  Don't forget it.  As a convenience, the master key is recorded in a "stash file" at /var/lib/krb5kdc/.k5.TINY.NET.  It is literally the key to the kingdom.  Check the permissions on the stash file.  Only root should be able to read it.

The next step is to add the required Kerberos database service principals and at least one admin user.  The kadmin utility is used for Kerberos realm administrative tasks like this, but it won't work yet.  kadmin needs to authenticate admin logins, but Kerberos authentications won't work yet since the database is empty.  The solution is to use the kadmin.local utility.  This special program offers the same functions as the kadmin utility, but it only works when run on the KDC server machine and does not authenticate logins:

```
kdcbox ~ # kadmin.local
```

Add the required Kerberos service principals to the system keytab:

```
kadmin.local:  ktadd kadmin/admin kadmin/changepw
```

Then create a default policy that will be used for new principals:

```
kadmin.local:  add_policy -maxlife "10 years" default
```

A policy is a named group of restrictions on passwords like their minimum length and maximum lifetime.  Each principal is assigned a policy when it is created.  If no explicit policy is given during principal creation, the policy "default" is assigned.  In the above example, the password for principals assigned the "default" policy will expire in 10 years.

Now create an administrative principal and a normal principal.  Note that the format of the admin principal's name follows that specified in the ACL file:

```

kadmin.local:  add_principal username/admin

kadmin.local:  add_principal username

```

Use the same username for each principal here.  You will be prompted for passwords for each principal, and they will each be assigned the "default" password policy.

The last step in the initial Kerberos KDC setup is to create a host principal for the KDC server machine and add it to the system keytab:

```

kadmin.local:  add_principal -randkey host/kdcbox.tiny.net

kadmin.local:  ktadd host/kdcbox.tiny.net

```

Note that you will not be prompted for a password due to the -randkey option used for creation of the service principal.  Since this principal will be added to a keytab, the password will never be used by a human.  Also, the ktadd command randomizes passwords upon adding the principal to the keytab anyway, so specifying a password here serves no purpose.  The system keytab file's default location is /etc/krb5.keytab.

Exit the kadmin.local utility:

```
kadmin.local:  quit
```

Start the Kerberos daemons and let them start after boot:

```

kdcbox ~ # /etc/init.d/mit-krb5kdc start

kdcbox ~ # /etc/init.d/mit-krb5kadmind start

kdcbox ~ # rc-update add mit-krb5kdc default

kdcbox ~ # rc-update add mit-krb5kadmind default

```

Note that kadmind tries to obtain data from /dev/random when starting up.  If the KDC host machine's entropy pool is empty, the kadmind daemon will hang until it gets what it needs.  The quickest way to build some entropy is to type gibberish into a terminal and/or move the mouse around a lot.  This can be a problem if the KDC host is headless and without a keyboard and mouse.  (need a good solution here)

Test the Kerberos KDC by trying to get a ticket for the host principal from the system keytab:

```
kdcbox ~ # kinit -k
```

No feedback is good.  If you get an error, check the server and client config files very carefully.  Another cause of problems here is name resolution - check the KDC machine's DNS settings.

Check out the ticket list, it will show a ticket granting ticket (TGT) for the host/kdcbox.tiny.net principal:

```
kdcbox ~ # klist
```

Now try to get a TGT for the normal, unpriveleged principal you set up earlier:

```
kdcbox ~ # kinit username
```

Enter the password and use klist to see your new ticket.  Again, no feedback from kinit is good.  Now try kadmin:

```

kdcbox ~ # kadmin

Authenticating as principal username/admin@TINY.NET with password.

Password for username/admin@TINY.NET:

```

Type in the password for the admin principal you created earlier.  Notice that kadmin figured out that you were trying to log in with unpriveleged principal credentials (username@TINY.NET), and automatically tried to authenticate you as username/admin@TINY.NET.

If you got an error message concerning a corrupted master key, it likely means that your kdc.conf file is not being read by kadmind.  Put your kdc.conf in the default location: /var/lib/krb5kdc/kdc.conf, then restart kadmind and krb5kdc.

The kadmin utility is network aware in that it can be run on any machine on the network.  It will connect to the kadmind daemon on the KDC, and all administration functions can be done remotely, which is quite convenient.

If you haven't received any error messages up to this point, your KDC is ready for production use in your small network.

----------

## Bones

Adding a Network Host to the Kerberos Realm

This section of the guide configures a computer to take part in the Kerberos realm.  This involves making PAM kerberos aware, and installing host service principals into the system keytab for the SSH server.  I consider SSH to be a critical service for every host on my network, so I'll cover the Kerberos configuration in this section.

PAM Configuration

First, a word about user accounts.  Kerberos does not act as a database for user accounts as far as user logins are concerned.  The network admin must still configure user accounts on each individual machine.  Kerberos does not replace the /etc/passwd or /etc/shadow files!  It only handles authentication.  So there is a duality, of sorts, with this type of Kerberos setup.  Each host keeps a list of users, and Kerberos keeps its own list of users (principals).

When logging in, PAM will try to get a TGT for the principal named "loginname@REALM" using the password typed in by the user.  Therefore, when adding new user accounts to machines on your network, make sure to add Kerberos principals with the same name.

The pam_krb5 module makes Kerberising PAM quite easy.  Basically, the pam_krb5 module is inserted into the system-auth PAM configuration file, in front of the pam_unix module.  PAM will then try to authenticate with Kerberos first, and we will set things up to allow normal pam_unix authentication in case the KDC is not available.  We will also configure PAM to handle Kerberos password changes transparently with system user password changes.

*** Warning!  Open up another terminal somewhere before testing changes to PAM configuration files.  If you screw it up badly, you may have problems logging back in to make fixes! You can use the previously opened terminal to make emergency repairs. ***

Make these changes to the auth and password sections of /etc/pam.d/system-auth:

```

auth      sufficient   pam_krb5.so

auth      sufficient   pam_unix.so use_first_pass likeauth nullok

password   optional   pam_krb5.so use_authtok

password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow

```

The order is important, make sure to place pam_krb5.so first in each case.  Remove or comment out the following line; for some reason, PAM pukes on password changes if it is left active:

```
password      required   pam_deny.so
```

SSH Configuration

The first step here is to add the necessary service principal to the system keytab.  In basic terms, sshd uses it to tell Kerberos that it is a legitimate network service, and allows the KDC to grant tickets for use of that service.  The SSH server requires a host/fqdn service key, which is added to the system keytab with the kadmin utility.

When configuring SSH on the KDC server, remember that you have already placed the necessary host/fqdn key in its keytab.  In other words, when configuring SSH on the KDC server, skip straight to editing the SSH config files.

We will suppose that the FQDN of our new computer is testbox.tiny.net.  The first step is to add the new service principal to the Kerberos database using kadmin.  As root on testbox.tiny.net, grab a TGT for the admin principal, and start kadmin:

```
testbox ~ # kinit username/admin

testbox ~ # kadmin
```

As usual, enter your admin principal's password to access the database.  Next, create the new host service principal, and add it to the system keytab:

```

kadmin:  add_principal -randkey host/testbox.tiny.net

kadmin:  ktadd host/testbox.tiny.net

kadmin:  quit

```

Now configure the SSH server to use Kerberos authentication.  Change the following in /etc/ssh/sshd_config:

```

KerberosAuthentication yes

KerberosOrLocalPasswd no

KerberosTicketCleanup yes

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

# I recommend disabling PAM and other forms of interactive authentication.  Use pubkey for a backup form of authentication instead.

PasswordAuthentication no

ChallengeResponseAuthentication no

UsePAM no

```

I elected to disable all forms of interactive authentication for sshd, but you may, of course, do differently.  It is useful to allow public key authentication as well as Kerberos, to ensure that SSH remains available when the KDC isn't.

To let the SSH client use Kerberos authentication, make the following changes to /etc/ssh/ssh_config:

```

GSSAPIAuthentication yes

GSSAPIDelegateCredentials yes

```

If sshd is already running, make sure to restart it before trying out the Kerberos functionality.  Test ssh from a different Kerberised host on the network (from kdcbox in this example):

```

username@kdcbox ~ $ kinit

username@kdcbox ~ $ slogin testbox.tiny.net

```

The slogin program will not ask for a password if it is correctly configured for Kerberos.  SSH will log in as the user with the same name as the current principal.  In the above example, the kinit command will get a ticket for the principal username@tiny.net, and SSH will try to log in as user username.

Also, if you have configured sshd to reject root logins, remember to not test this out using root  :Wink: 

----------

## Bones

Samba Configuration

To enable Kerberos functionality, Samba should be compiled with the "kerberos" and "ldap" USE flags.  Even though we are not using LDAP, the Samba build requires it to be present for Kerberos.

Samba uses a cifs/fqdn service principal to do its business.  Add it to the Kerberos database and the system keytab using the kadmin utility.  Here we will assume the FQDN of the file sharing machine is sambabox.tiny.net.  As root on the Samba server:

```
sambabox ~ # kadmin

kadmin:  add_principal -randkey cifs/sambabox.tiny.net

kadmin:  ktadd cifs/sambabox.tiny.net

kadmin:  quit

```

Next, make the following edits to the global section of /etc/samba/smb.conf:

```

[global]

        netbios name = sambabox

        workgroup = TINY

        security = ads 

        realm = TINY.NET

        use kerberos keytab = yes

        encrypt passwords = yes

```

This configuration tells the Samba server to use Kerberos as its user/password database.  If you are converting over an existing Samba installation, realize that the existing database will no longer be used.  Also, the smbpasswd utility is now useless.  Samba will authenticate any user with a principal in the Kerberos realm.

Kerberos authentication is enabled by setting the security type to ads (Active Directory), and telling Samba to use the service principal in the system keytab.  It is important to set the workgroup to the first part of your Kerberos realm name as shown above.  Windows clients automatically assume that they belong to a workgroup with the same name as the first part of the Kerberos realm, and setting up Samba to do the same greases the skids for adding Windows clients later on.

At this time, restart Samba.  You may test the Kerberised Samba server from any host in the Kerberos realm.  Before testing, make sure that you have a non-admin user TGT with one of the following commands:

```
somehost ~ # kinit username

somehost ~ $ kinit
```

Test out Kerberos authentication using the smbclient program:

```
smbclient //sambabox/sharename -k
```

If there are no errors, Samba is set up correctly and is ready for production use for interfacing with Linux clients.  Windows file sharing requires some additional service principals to be added to sambabox's keytab due to Microsoft's hatred for case sensitivity.  I'll cover that later, when covering how to integrate Windows into the Kerberos realm.

At the time of this writing, with kernel 2.6.22, the CIFS kernel module does not support Kerberos authentication.  So any attempt to use mount.cifs for shares on a Kerberised Samba server will fail.  Instead, make sure that SMB support is built into your kernels and use smbmount to mount the shares:

```
smbmount //server/share /mountpoint -o krb
```

When the CIFS module gets Kerberos working, mounting will be done with this command:

```
mount.cifs //server/share /mountpoint -o sec=krb5
```

----------

## Bones

Adding a Windows Client to the Kerberos Realm

This section of the guide implements Kerberos support in Windows 2000/XP as a client to the realm.  We will first add the Windows machine to the realm, and then discuss how to get Windows to talk to a Kerberised Samba server.  These instructions are for XP, but the Windows 2000 setup is exactly the same except that some of the GUI button labels are different.

Adding the Windows Machine to the Kerberos Database

Use kadmin to add a host/fqdn principal to the Kerberos database.  In this example, we will assume that the Windows machine has a FQDN of windbox.tiny.net.  Do not use the -randkey option here like we did for the Linux hosts; we must give the password to Windows later on.  The Arcfour encryption type MUST be specified here as the only type allowed for this principal:

```
testbox ~ # kadmin

kadmin:  add_principal -e rc4-hmac:normal host/windbox.tiny.net

kadmin:  quit

```

That's it for the database, now move to the Windows machine.

Windows Kerberos Configuration

Obviously, all of this must be done as a user with administrator rights.

First install the Microsoft support tools on the Windows machine we are about to add to the realm.  These command-line tools are not part of the default install, but reside on the Windows CD at /support/tools.  Double click on the setup.exe in that directory.

Next, edit the network ID by right clicking My Computer and selecting Properties.  Then select on the Computer Name tab, and click the Change button next to the "To rename this computer or join a domain" label.  In the "Computer Name Changes" dialog box, fill in the hostname of the computer, "windbox" in this case.  Click the More button and watch the "DNS Suffix and NetBIOS Computer Name" dialog pop up.  Fill in "tiny.net" as the Primary DNS suffix and click OK.  Notice that Windows has automatically filled in TINY.NET as the workgroup.  Click OK buttons until all of the dialogs are closed, and let Windows reboot.

After the reboot, open a terminal and use the ksetup program to configure this machine for Kerberos.  For the setmachpassword command, give it the password you used when adding the host principal to the database.

```
C:\Documents and Settings\username>ksetup /setrealm TINY.NET

C:\Documents and Settings\username>ksetup /addkdc TINY.NET kdcbox.tiny.net

C:\Documents and Settings\username>ksetup /addkpasswd TINY.NET kdcbox.tiny.net

C:\Documents and Settings\username>ksetup /setmachpassword password

```

Reboot the machine.  If you didn't have it set up before, Windows will now require a ctrl-alt-delete to login.  There is one more ksetup command that needs to be run after the reboot:

```
C:\Documents and Settings\username>ksetup /mapuser * *
```

Now run ksetup without any arguments, and it will show the Kerberos settings for this machine.  Review it for errors before moving on:

```
C:\Documents and Settings\username>ksetup

default realm = TINY.NET (external)

TINY.NET:

   kdc = kdcbox.tiny.net

   kpasswd = kdcbox.tiny.net

   Realm Flags = 0x0 none

Mapping all users (*) to a local account by the same name (*).

```

Now log out.  At the login window, click the "Options >>" button to reveal an additional "Log on to" field.  The drop down list will let you log in to the local machine without using Kerberos, or log in with Kerberos.  Choose the Kerberos realm login option, and use a username corresponding to a Kerberos principal and local account.  Like the Linux clients, Windows maintains its own user accounts and assumes that Kerberos has principals with the same usernames.

The Kerberos password can be changed from Windows.  While logged in, hit ctrl-alt-delete and click the "Change Password..." button.

Getting Windows to Talk to Kerberised Samba

The first order of business is to remove any cached credentials that Windows might be keeping for the Samba server(s).  Go to User Accounts in the Windows control panel, and do this for each user: In the side pane, click "Manage my network passwords" and remove entries there for all of the Kerberised Samba servers on the network.  Unless the the cache is flushed like this, Windows will simply refuse to use Kerberos for file sharing authentication.

The next part is tricky: Windows uses different combinations of capital and lowercase letters when requesting cifs/fqdn tickets from the KDC for the Samba server.  Since Kerberos is case sensitive, these (broken) requests will fail because "cifs/Sambabox.tiny.net" is a different principal from "cifs/sambabox.tiny.net".  The only workaround for this is to figure out which principals Windows wants to use to communicate with our Samba server, and add those principals to the Kerberos database and the Samba server's keytab.

The easiest method I've found for figuring out what Windows needs is to run "tail -f /var/log/messages" on the KDC machine to watch which tickets get requested.  To get Windows to issue a ticket request, browse the network in Windows Explorer and click on the Samba server in question.  If you have set up the workgroup names in Samba correctly, this should not be a problem.  A typical ticket request from Windows looks like this:

```
Jun 15 21:12:53 kdcbox krb5kdc[9999]: TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.0.100: ISSUE: authtime 1181956373, etypes {rep=23 tkt=18 ses=23}, username@TINY.NET for cifs/SAMBABOX.TINY.NET@TINY.NET
```

Notice that Windows requested a ticket for "cifs/SAMBABOX.TINY.NET".

We need to add this principal.  As root on the Samba server:

```
sambabox ~ # kadmin

kadmin:  add_principal -randkey cifs/SAMBABOX.TINY.NET

kadmin:  ktadd cifs/SAMBABOX.TINY.NET
```

Repeat this process of trying to access a Samba share from Windows, and adding cifs principals, until Windows runs out of combinations it wants to use.  For my test setup, this is what "klist -k" says is in the system keytab of sambabox.tiny.net:

```
sambabox ~ # klist -k

Keytab name: FILE:/etc/krb5.keytab

KVNO Principal

---- --------------------------------------------------------------------------

   3 host/sambabox.tiny.net@TINY.NET

   3 host/sambabox.tiny.net@TINY.NET

   3 cifs/sambabox.tiny.net@TINY.NET

   3 cifs/sambabox.tiny.net@TINY.NET

   3 cifs/SAMBABOX.TINY.NET@TINY.NET

   3 cifs/SAMBABOX.TINY.NET@TINY.NET

   3 cifs/Sambabox.TINY.NET@TINY.NET

   3 cifs/Sambabox.TINY.NET@TINY.NET

```

Notice that Windows needed two different capitalizations of sambabox, and it always capitilized the domain name.  Your setup may need other combinations.

This file sharing setup is one-way only; Windows machines will be able to access Samba shares, but Linux clients will not be able to use smbmount with Kerberos to mount shares located on Windows machines.  Normal username/password access will still work.  In the future, the CIFS module may be able to mount Windows shares.

----------

## Bones

Mail Server Configuration

This section covers the configuration of the Dovecot server, and the Thunderbird 2.0 mail client.

Dovecot Configuration

Dovecot can use Kerberos as its user database, allowing us to set up a virtual mail system that provides a mailbox for every Kerberos principal.  First, create an imap/fqdn service principal and add it to the keytab on the IMAP server.  We will assume that our mail server has a FQDN of mailserver.tiny.net:

```

mailserver ~ # kadmin

kadmin:  add_principal -randkey imap/mailserver.tiny.net

kadmin:  ktadd imap/mailserver.tiny.net

kadmin:  quit

```

Next, make the following changes to /etc/dovecot/dovecot.conf:

```

mail_location = maildir:~

auth default {

  mechanisms = gssapi 

  userdb static {

    args = uid=vmail gid=vmail home=/var/vmail/%u

  }

}

```

The mechanisms line tells Dovecot to use Kerberos authentication.  The userdb section sets up virtual mailboxes for all Kerberos principals in /var/vmail, and all mails will be owned by the vmail user.  Note that a passdb section is not required for this setup. Dovecot itself doesn't check passwords; instead, it hands off authentication to Kerberos.

Thunderbird Mail Client Setup

Setting up Thunderbird to use our Kerberised IMAP server is easy.  Make a new email account in Thunderbird as you would normally.  Then go to Server Settings for that account and check the "Use secure authentication" checkbox under the Security Settings heading.

----------

## Xn0r

Nice writeup for KRB n00bs like myself.

You may want to reiterate that when you run kadmin and add the principal for the SSH server host (testbox in your example), that this should be run ON testbox, otherwise it wont put the key into the system keytab on that host.

Rather obvious now, but when I was n00bing around with it I didn't think about it.

----------

