The following text briefly describes the steps necessary to setup an
Active Directory Server and FreeRADIUS to use rlm_krb5 for
authentication purposes. The setup has been tested using FreeRADIUS
1.0.2 (Debian sarge package 1.0.2-4), MIT Kerberos 5 1.4.3 (Debian etch
package 1.4.3-4) and Microsoft Windows Server 2003 SP1.


0. Setup Kerberos client side on FreeRADIUS server

The following examples assume /etc/krb5.conf to look something like
this:

[libdefaults]
  default_realm = EXAMPLE.COM

[realms]
EXAMPLE.COM = {
  kdc = <your.ads.server>
  admin_server = <your.ads.server>
}

The realms section might not be necessary if DNS SRV lookups work at
your setup for the FreeRADIUS machine.


1. Create user account within AD to hold the service principal used for
   FreeRADIUS

Create a normal user account (called `freeradius' form here on) to hold
the service principal that rlm_krb5 should use to verify tickets.
Remember the password as it will be used to derive kerberos keys later.

Don't disable the account as this will prevent Kerberos from working. If
you want to disable interactive logon for the account, set the list of
allowed hosts to a non-existing one, e.g. Maybe there are better ways to
achieve this ...


2. Map service principal to AD account on ADS side

Use the Microsoft tool `ktpass' to map the service principal used by
FreeRADIUS to the account created in step 1. `ktpass' can be found in
"Windows Support Tools".

In this example, the service principal shall be
freeradius/radius.example.com and the Kerberos 5 realm shall be
EXAMPLE.ORG. Of course, in real life the realm has to match your AD
setup. Then `ktpass' could be called like this:

C:\> ktpass -princ freeradius/radius.example.com@EXAMPLE.COM -pass *
       -mapuser freeradius@EXAMPLE.COM -desonly
...
Type the password for freeradius/radius.example.com: ...
Type the password again to confirm: ...
...

This will generate the kerberos keys on the ADS side. `-desonly'
prevents the account from being set to 'Use DES encryption only'. If not
specified, arcfour-hmac would not be used by the ADS anymore for
encrypting the service ticket acquired by FreeRADIUS for account
verification.

Theoretically, `ktpass' could be used to generate the keytab entries for
the FreeRADIUS side, but again, DES keys only.

3. Generate keytab for FreeRADIUS

Use Kerberos' `ktutil' to generate keytab entries for FreeRADIUS. We
need two entries: One for des-cbc-md5, as rlm_krb5 uses this encryption
type to verify that a host key is present at all before even attempting
two authenticate (maybe this should be fixed?). The second key is for
arcfour-hmac used by ADS since we didn't configure the freeradius account
to use DES only.

# cd ${confdir}
# ktutil
ktutil:  addent -password -p freeradius/radius.example.com -k 3 -e des-cbc-md5
Password for freeradius/radius.example.com@EXAMPLE.COM: ...
ktutil:  addent -password -p freeradius/radius.example.com -k 3 -e arcfour-hmac
Password for freeradius/radius.example.com@EXAMPLE.COM: ...
ktutil:  list -e
slot KVNO Principal
---- ----
---------------------------------------------------------------------
   2    3 freeradius/radius.example.com@EXAMPLE.COM (DES cbc mode with RSA-MD5)
   3    3 freeradius/radius.example.com@EXAMPLE.COM (ArcFour with HMAC/md5)
ktutil:  wkt radius.keytab
ktutil:  q
#


4. Configure rlm_krb5

Configure rlm_krb5 to use the correct keytable and service principal:

modules {
  ...
  krb5 {
    keytab = ${confdir}/radius.keytab
    service_principal = freeradius/radius.example.com
    
  }
  ...
}

...

authenticate {
  Auth-Type krb {
    krb5
  }
}

Of course, you will have to set Auth-Type := krb somehow.


5. Authorization

Additionally, rlm_ldap should/could be used for authorization purposes
with AD.

Currently, rlm_ldap seems to support simple bind only, so the kerberos
setup from above can't be used to authenticate rlm_ldap to ADS via
GSSAPI yet.

