rlm_krb5 vs. Active Directory how to

classic Classic list List threaded Threaded
1 message Options
| Threaded
Open this post in threaded view

rlm_krb5 vs. Active Directory how to

Enrik Berkhan-2

I've spent the last two days understanding Kerberos and Active Directory
interoperability by setting up FreeRADIUS to authenticate via rlm_krb5
against AD. As result, I've written the attached mini how to.

As I don't believe its ready for the average user, I post it to -devel
for review. If you think it is of any use, feel free to integrate it
into the FreeRADIUS doc/ stuff.


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

  default_realm = 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

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/[hidden email] -pass *
       -mapuser [hidden email] -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

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/[hidden email]: ...
ktutil:  addent -password -p freeradius/radius.example.com -k 3 -e arcfour-hmac
Password for freeradius/[hidden email]: ...
ktutil:  list -e
slot KVNO Principal
---- ----
   2    3 freeradius/[hidden email] (DES cbc mode with RSA-MD5)
   3    3 freeradius/[hidden email] (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 {

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

List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html