[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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

[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:

Code: Select all

*/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:

Code: Select all

[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:

Code: Select all

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:

Code: Select all

kdcbox ~ # kadmin.local

Add the required Kerberos service principals to the system keytab:

Code: Select all

kadmin.local:  ktadd kadmin/admin kadmin/changepw

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

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

kadmin.local:  quit

Start the Kerberos daemons and let them start after boot:

Code: Select all

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:

Code: Select all

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:

Code: Select all

kdcbox ~ # klist

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

Code: Select all

kdcbox ~ # kinit username

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

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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):

Code: Select all

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

[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:

Code: Select all

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:

Code: Select all

[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:

Code: Select all

somehost ~ # kinit username
somehost ~ $ kinit

Test out Kerberos authentication using the smbclient program:

Code: Select all

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:

Code: Select all

smbmount //server/share /mountpoint -o krb

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

Code: Select all

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:

Code: Select all

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.

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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:

Code: Select all

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.