Configuring FreeRADIUS for Authentication against Active Directory

If you have any questions or comments regarding these instructions please contact the eduroam-US Team and we will work with you to assist as much as possible.

Description

The following is a sketch of the changes required to make a default FreeRADIUS instance stand up as an institutional eduroam server with an eye towards integrating with an existing ActiveDirectory instance.  These instructions are nearly identical for integrating with a Samba instance operating as a PDC as both use the ntlm_auth utility to perform the authentications.

Instructions

There are four files that define the majority of the customization required to configure your system:  eap.conf, proxy.conf, clients.conf, and sites-enabled/inner-tunnel.  In addition, if you plan on using MS-CHAPv2 (for Active Directory integration) you will need to edit modules/mschap.

Note: Before getting started please be aware that it is often easier to start with a default FreeRADIUS installation and build-up to a working eduroam configuration unless you have extensive experience in FreeRADIUS.  It may be easiest to stand-up an experimental server for eduroam, and once it is working with your 802.1x infrastructure, port the changes to your production FreeRADIUS instance.

In eap.conf you must setup the EAP methods (TTLS, PEAP, or both) that you plan on supporting at your institution (comments removed for brevity):

eap {
  default_eap_type = ttls
  timer_expire = 60
  ignore_unknown_eap_types = no
  cisco_accounting_username_bug = no
  max_sessions = 2048
 
  md5 {
  }
 
  leap {
  }
 
  tls {
    certdir = ${confdir}/certs
    cadir = ${confdir}/certs
    private_key_file = ${certdir}/serverkey.key
    certificate_file = ${certdir}/servercert.cert
    dh_file = ${certdir}/dh
    random_file = ${certdir}/random
    cipher_list = "DEFAULT"
    make_cert_command = "${certdir}/bootstrap"
    cache {
    enable = no
    max_entries = 255
  }
 
  ttls {
    default_eap_type=mschapv2
    copy_request_to_tunnel = yes
    use_tunneled_reply = yes
    virtual_server = "inner-tunnel"
  }
 
  peap {
    default_eap_type = mschapv2
    copy_request_to_tunnel = yes
    use_tunneled_reply = yes
    virtual_server = "inner-tunnel"
  }
	 
    mschapv2 {
  }
}

In your eap configuration block specify which EAP outer-method (TLS, TTLS, or PEAP) you default to with the default_eap_type directive

Regardless of your EAP type the TLS configuration is required to define the certificate presented to your users when they create their encrypted tunnel back to the eduroam RADIUS server. For testing it may be easiest to simply use the certificates shipped with FreeRADIUS since the certificate configuration is often the hardest part of this process.  If you choose to do so you may leave the tls configuration block alone in the tls section until the rest of the configuration is finished.  Before going into production you should plan on updating this configuration with either a production certificate.  For greatest compatibility with various devices a certificate signed by a CA that ships with most commercial supplicant key-stores such as Comodo, Thawte, or Verisign should be used.  This eases deployment onto user owned devices.

If you plan on supporting TTLS or PEAP then the sub-blocks defined above configure those methods.  In both cases we have the default EAP type set to mschapv2 as we use AD as our IdP. If you plan on using a different directory service you will likely need to change the default_eap_type in either the ttls or peap block (or both). In the case that you do use AD as your directory service your eap.conf should also have an empty MSCHAPv2 definition as shown above.

proxy.conf needs to define various RADIUS proxies to route users by realm and should look something like what follows:

proxy server {
  default_fallback = no
}
 
home_server localhost {
  type = auth
  ipaddr = 127.0.0.1
  secret = <your_local_secret>
}
 
realm NULL {
}
 
realm LOCAL {
}
	 
realm realm.edu {
  type = radius
  secret = <your_radius_secret>
 
  # If you have an existing RADIUS server and are not authenticating
  #  against ActiveDirectory directly this allows for proxying
  #  to your current server
  authhost = radius1.realm.edu # change to your radius server
  accthost = radius1.realm.edu # change to your radius server
 
  # If this server is the termination point for RADIUS requests and
  #   will authenticate directly against the ActiveDirectory server
  authhost = LOCAL
  accthost = LOCAL
}
 
realm DEFAULT {
  type = radius
  authhost = <eduroam-US top level server(s)>
  accthost = <eduroam-US top level server(s)>
  secret = <your_eduroam_secret>
  nostrip
}

If your forwarding to a campus RADIUS server which is also FreeRADIUS you will need to create a separate DEFAULT block on it as well to forward the eduroam users (anyone with a realm different from your local realm) to the eduroam FreeRADIUS server you configured above.

You must also configure your clients.conf to match the proxy.conf:

client localhost {
  ipaddr = 127.0.0.1
  secret = <your_local_secret>
  nastype = other
}
	 
client <eduroam-US top level server(s)> {
  #ipaddr = <eduroam-US top level server(s)>
  secret = <your_eduroam_secret>
  nastype = other
}
 
client radius1.realm.edu {
  secret = <your_radius_secret>
  nastype = other
}
	

In our sites-enabled/inner-tunnel configuration we simply disabled authentication by files and by UNIX password and added ntlm_auth to support our ActiveDirectory. If you plan on proxying your RADIUS requests to an existing RADIUS server, which in turn is already configured to authenticate against your directory-service, this configuration is not necessary and, after fixing the port number (see next paragraph) you should not need to make further changes to the inner-tunnel.

Also note, in the current FreeRADIUS distribution there is a typo leaving the authentication port set to 18120 instead of the standard 1812. In general eduroam-US uses udp/1812,1813 (for authentication and accounting resp.) but sites may opt to use udp/1645,1646 (the old standards) depending on their needs.

In modules/mschap to following settings should be changed.  The encryption settings allow for the cryptographic key material to be passed back to the NAS and the ntlm_auth configuration uses the local Samba authentication against the ActiveDirectory.  Be sure to change the domain to be appropriate for your institution:

mschap {
  # if use_mppe is not set to no mschap will
  # add MS-CHAP-MPPE-Keys for MS-CHAPv1 and
  # MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2
  use_mppe=yes
 
  # if mppe is enabled require_encryption makes
  # encryption moderate
  require_encryption = yes
 
  # require_strong always requires 128 bit key
  # encryption
  require_strong = yes
 
  # Windows sends us a username in the form of
  # DOMAIN\user, but sends the challenge response
  # based on only the user portion.  This hack
  # corrects for that incorrect behavior.
  with_ntdomain_hack = yes
 
  # Configure to use your local NTLM authentication mechanism      
  ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --domain=%{%{mschap:NT-Domain}:-<YOUR DOMAIN>} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
}