Hi, 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. Enrik 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.