Debian/Ubuntu Linux with AD Kerberos Server

Debian/Ubuntu Linux with AD Kerberos Server
	Linux Authenticating against Active Directory

See the previous section to get your nameserving in order.

Kerberos is a trusted-third-party symmetric key authentication method that Active Directory uses extensively. For Linux, two flavours are widely available: MIT and Heimdal.

Procedure 18. Configuring Linux for AD Kerberos

Preconfiguring heimdal (with DebConf)

I picked Heimdal Kerberos for this HOWTO because I've worked with it for years. MIT can be handled alike, albeit not identically.

Create a file - say - debconf-kerberos-settings:

# Default Kerberos version 5 realm (this is the single most important setting):
krb5-config krb5-config/default_realm string WSPACE.MYDOMAIN.NL

# Kerberos servers for your realm: 
krb5-config krb5-config/kerberos_servers string wspace.mydomain.com adsvr01.wspace.mydomain.com adsvr02.wspace.mydomain.com adsvr03.wspace.mydomain.com adsvr04.wspace.mydomain.com

# Local realm name: 
heimdal-kdc heimdal/realm string WSPACE.MYDOMAIN.NL

# Administrative server for your Kerberos realm: 
krb5-config krb5-config/admin_server string wspace.mydomain.com

# Does DNS contain pointers to your realm's Kerberos Servers? 
krb5-config krb5-config/dns_for_default boolean true

# Add locations of default Kerberos servers to /etc/krb5.conf? 
krb5-config krb5-config/add_servers boolean false

	The `kerberos_servers` can be left blank in our case, as they're served through DNS. The setting cannot be left out, as it won't be preseeded then, and debconf will ask questions.
	The `realm` to be used is not served by DNS in our case, so it must be specified.
	The `admin_server` is not served through DNS, but it isn't used either, so it may be left blank.
	DNS in our case deals only some Kerberos information, not all. See below in the troubleshooting section.
	This leads to the Kerberos servers specified in this file not being listed in `/etc/krb5.conf`. If DNS doesn't serve enough, try toggling to “true”.

Preseed Heimdal

apprentice@clnt-3-53:~$ cat debconf-kerberos-settings |sudo debconf-set-selections apprentice@clnt-3-53:~$ sudo apt-get install -y heimdal-clients <snip >
Try whether we can fetch a Kerberos ticket
The configuration file /etc/krb5.conf has been generated from the DebConf settings at package install time, so even without touching it, we can now fetch a ticket:
apprentice@clnt-3-53:~$ kinit U1234567 U1234567@WSPACE.MYDOMAIN.NL's Password: kinit: Password incorrect
(the wrong password, and it doesn't work)
apprentice@clnt-3-53:~$ kinit U1234567 U1234567@WSPACE.MYDOMAIN.NL's Password:
(the right password, and it works:)
apprentice@clnt-3-53:~$ klist Credentials cache: FILE:/tmp/krb5cc_7305 Principal: U1234567@WSPACE.MYDOMAIN.NL Issued Expires Principal May 1 16:19:02 2012 May 2 02:18:56 2012 krbtgt/WSPACE.MYDOMAIN.NL@WSPACE.MYDOMAIN.NL

Kerberos Basics

Within an AD domain, as within any Kerberos realm, not only users, but also machines and services may and do require authentication against the Kerberos database. In Kerberos parlance: users, machines and services all have Kerberos principals.

Right now, you may get away with only half an understanding of Kerberos jargon. Once troubleshooting starts, you should at least be familiar with realms, principals, credentials, keytabs, tickets and TGTs (Ticket Granting Tickets. The Kerberos User Guide from MIT is a good place to start. Or else this MS TechNet article.

Troubleshooting

There may be DNS records that serve Kerberos information. To see if the name of the realm itself is served for our company:

apprentice@clnt-3-53:~$ dig +noqr +nocmd +nocomments +nostats _kerberos.mydomain.com -t TXT

... or for wspace.mydomain.com:

apprentice@clnt-3-53:~$ dig +noqr +nocmd +nocomments +nostats _kerberos.wspace.mydomain.com -t TXT

But AD Kerberos does serve some Kerberos services:

apprentice@clnt-3-53:~$ dig +noqr +nocmd +nocomments +nostats -t SRV {_kerberos,_kerberos-master,_kerberos-adm,_kpasswd}.{_tcp,_udp}.wspace.mydomain.com < output snipped: _kerberos and _kpasswd are served, the rest is not >

(If you don't understand the output, try to remove some of the no* options.)

See which Kerberos services the AD servers provide:

apprentice@clnt-3-53:~$ nmap -P0 -p88,749,750,751 \ wspace.mydomain.com \ adsvr01.wspace.mydomain.com \ adsvr02.wspace.mydomain.com \ adsvr03.wspace.mydomain.com \ adsvr04.wspace.mydomain.com Starting Nmap 5.21 ( http://nmap.org ) at 2012-05-01 11:47 CEST Nmap scan report for wspace.mydomain.com (192.168.85.3) Host is up (0.00045s latency). rDNS record for 192.168.85.3: adsvr01.wspace.mydomain.com PORT STATE SERVICE 88/tcp open kerberos-sec 749/tcp filtered kerberos-adm 750/tcp filtered kerberos 751/tcp filtered kerberos_master <snip other hosts, as output is identical except hostname/IP>

... it looks like they all provide Kerberos, but none provides kerberos Admin services, and it looks like they're all slaves.