The following describes how I configured Kerberos on Debian Lenny:

Install the required packages:

aptitude install krb5-kdc krb5-admin-server krb5-clients libpam-krb5

edit /etc/krb5.conf:

[libdefaults]
default_realm = ZEM.ORG.UK
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as 
# old versions of Sun Java). 
#   default_tgs_enctypes = des3-hmac-sha1 
#   default_tkt_enctypes = des3-hmac-sha1 
#   permitted_enctypes = des3-hmac-sha1 
# The following libdefaults parameters are only for Heimdal Kerberos. 
v4_instance_resolve = false 
v4_name_convert = { 
	host = { 
		rcmd = host 
		ftp = ftp 
	} 
	plain = { 
		something = something-else 
	} 
} 
fcc-mit-ticketflags = true 

[realms] 
ZEM.ORG.UK = { 
	kdc = ldap.zem.org.uk 
	admin_server = ldap.zem.org.uk 
} 

[domain_realm] 
.zem.org.uk = ZEM.ORG.UK 
zem.org.uk = ZEM.ORG.UK 

[login] 
krb4_convert = true 
krb4_get_tickets = false 

[logging] 
kdc = FILE:/var/log/kerberos/krb5kdc.log 
admin_server = FILE:/var/log/kerberos/kadmin.log 
default = FILE:/var/log/kerberos/krb5lib.log

create the new realm and initialise some basic users:

krb5_newrealm
kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin" 
kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw" 
kadmin.local -q "addprinc dan/admin@EXAMPLE.COM"
kadmin.local -q "addprinc ldapadm@EXAMPLE.COM"

edit /etc/krb5kdc/kadm5.acl

*/admin@ZEM.ORG.UK     * */*@ZEM.ORG.UK          i *@ZEM.ORG.UK           i

restart services:

# /etc/init.d/krb5-kdc restart 
Restarting Kerberos KDC: krb5kdc krb524d.
# /etc/init.d/krb5-admin-server
restart Restarting Kerberos administrative servers: kadmind`

edit /etc/pam.d/common-auth:

auth    sufficient  pam_krb5.so use_first_pass ignore_root forwardable
auth    required        pam_unix.so nullok_secure

edit /etc/pam.d/common-session:

session		required	pam_unix.so
session		sufficient	pam_krb5.so ignore_root

Configuring Solaris as a Kerberos client to work against a MS Active Directory Domain is documented by Oracle in the How to Configure a Kerberos Client for an Active Directory Server. This uses the /usr/sbin/kclient script provided by the kerberos-5 package, but makes some assumptions:

• The computer object will be created in OU=Computers
• The user joining the client to the domain must have Domain Administrator rights

The first issue is fairly trivial to work around, but the second is more interesting and that is what the rest of this post will focus on. To understand why such elevated rights are required it useful to look at what kclient is trying to do when joins a MS domain:

• Create or update the computer object via LDAP. It is worth noting for both these operations that userAccountControl gets set to 4130, which is a bit mask containing the flags: WORKSTATIONTRUSTACCOUNT | PASSWDNOTREQD | ACCOUNTDISABLE as described in http://support.microsoft.com/kb/305144 . - When creating the object, set the following attributes: objectClass, cn, sAMAccountName, userPrincipalName, servicePrincipalName, userAccountControl, dNSHostname. - When updating the object, replace the following attributes: userPrincipalName, servicePrincipalName, userAccountControl, dNSHostname. - Set a random password for the computer object. - Modify the msDS-SupportedEncryptionTypes attribute on the computer object based on which encryption types are supported by the client - Modify the userAccountControl attribute for the computer object and set the following flags: WORKSTATIONTRUSTACCOUNT | DONTEXPIREPASSWORD | TRUSTEDFOR_DELEGATION .

It is this last stage where an error occurs due to insufficient rights, even if you pre-create the computer object and explicitly set the ability for your user to modify the userAccountControl attribute. Further investigation shows that special permissions are required to set the TRUSTEDFORDELEGATION flag. It may be possible to grant a user permission to set this flag, I haven’t looked in to this. But as a non-Domain admin I don’t have this ability by default. It does raise the question why this flag is being set by default? Reading in to more detail about this flag suggests it should only be set when necessary.

For now I’ve modified the script to only set the WORKSTATIONTRUSTACCOUNT | DONTEXPIREPASSWORD flags (integer 69632) and we’ll see if not having the TRUSTEDFORDELEGATION flag causes any problems.

A modified version of kclient that doesn’t set the TRUSTEDFORDELEGATION flag and let’s you specify the target OU via the -o option can be downloaded from here. The argument for the -o option should be specified in DN format, not including the DN of your realm, e.g.:

OU=Solaris,OU=Servers