Thursday 4 February 2010

How to setup FreeRADIUS to integrate with Active Directory Authentication

I used the tutorial found at http://deployingradius.com/documents/configuration/active_directory.html for FreeRadius Active Directory integration, but modified it slightly to suit my needs, and fixed some errors which I encountered.

You may also want to read how to link Linux to a domain.

Firstly, setup Samba to link your computer to the domain:

Once Samba has been installed on your system, you should edit the smb.conf file, and configure the [global] section to point to your NT server, including hostname and NT domain.
# workgroup = NT-Domain-Name
workgroup = MYDOMAIN
...
# Security mode. Most people will want user level security. See
# security_level.txt for details.
security = ads
# Use password server option only with security = server
password server = nt-server-hostname.company.com
...
realm = realm.company.com
You will also have to edit the /etc/krb5.conf file, to add an entry that points to the Active Directory Server
[realms]
...
realm.company.com = {
kdc = nt-server-hostname.company.com
}
...
Start the Samba and Kerberos servers, and as root join the domain:
$ net join -U Administrator
Enter the administrator password at the prompt.
Next, verify that a user in the domain can be authenticated:
$ wbinfo -a user%password
You should see a number of lines of text, followed by authentication succeeded . The next step is to try the same login with the ntlm_auth program, which is what FreeRADIUS will be using:
$ ntlm_auth --request-nt-key --domain=MYDOMAIN --username=user --password=password
If all goes well, you should see authentication succeeding ( NT_STATUS_OK ). You should also see the NT_KEY output, which is needed in order for FreeRADIUS to perform MS-CHAP authentication.

Next, setup FreeRADIUS with ntlm_auth, and test it:

Configuring FreeRADIUS to use ntlm_auth
Once you have verified that Samba is installed and working correctly, and that the ntlm_auth program works, you can proceed with configuring FreeRADIUS to use ntlm_auth. For initial testing, we will be using the exec module, and will run the exact command line used above.
Create a file /etc/freeradius/modules/ntlm_auth , and put the following text in it:
exec ntlm_auth {
wait = yes
program = "/path/to/ntlm_auth --request-nt-key --domain=MYDOMAIN --username=%{mschap:User-Name} --password=%{User-Password}"
}
This configuration tells the server to run the ntlm_auth program with the user name and password obtained from the Access-Request. You will also have to list ntlm_auth in the authenticate sections of each the /etc/freeradius/sites-enabled/default file, and of the /etc/freeradius/sites-enabled/inner-tunnel file:
authenticate {
...
ntlm_auth
...
}
and add the following text for testing purposes only to the top of the users file.
DEFAULT Auth-Type = ntlm_auth
This configuration says "for all users, if the authenticate method has not been set, set it to use the ntlm_auth program".
Start the server using freeradius -X (you may have to stop the automatic daemon by /etc/init.d/freeradius stop), and wait for the debugging text to stop scrolling by. If all goes well, you should see the following text:
Ready to process requests.
In another terminal window on the same machine, type the following command:
$ radtest user password localhost 0 testing123
If all goes well, you should see the server returning an Access-Accept message, and the window with radtest should print text similar to the following:
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, length=20
This text means that authentication succeeded. A few lines above this text, the debug output will also show the exact command line used to run ntlm_auth.
Note: You may get this error: radclient: socket: cannot initialize udpfromto: Function not implemented.
This means for some reason it can't resolve the hostname localhost. Change localhost to 127.0.0.1 and it should work.

Then setup MS-CHAP with ntlm_auth:

Configuring FreeRADIUS to use ntlm_auth for MS-CHAPOnce you have the previous steps working, configuring FreeRADIUS to use ntlm_auth for MS-CHAP is simple. First, if you use any other authentication types (such as local UNIX accounts) delete the testing entry used above from the users file, as leaving it in will break other authentication types. Instead, move it to the bottom of the file, so that other authentication types still work.
Then, fine the mschap module in /etc/freeradius/modules/mschap file, and look for the line containing ntlm_auth = . It is commented out by default, and should be uncommented, and edited to be as follows. As before, update the fields in bold to match your local configuration.
ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
Start the server and use a test client to send an MS-CHAP authentication request. The radclient cannot currently be used to send this request, unfortunately, which makes testing a little difficult If everything goes well, you should see the server returning an Access-Accept message as above.

More information:
http://wiki.freeradius.org/Authentication
http://tldp.org/HOWTO/8021X-HOWTO/freeradius.html
http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO (Broken)
http://homepages.lu/charlesschwartz/radius/freeRadius_AD_tutorial.pdf
http://ubuntuforums.org/showthread.php?t=151388

Update: Here is my full krb5.conf file (my domain name has been replaced with "domain.local"). Note that this configuration includes many default settings which I haven't bothered to get rid of. All the MIT and standford stuff is unneccessary.


[libdefaults]
default_realm = DOMAIN.LOCAL

# 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]
ATHENA.MIT.EDU = {
kdc = kerberos.mit.edu:88
kdc = kerberos-1.mit.edu:88
kdc = kerberos-2.mit.edu:88
admin_server = kerberos.mit.edu
default_domain = mit.edu
}
MEDIA-LAB.MIT.EDU = {
kdc = kerberos.media.mit.edu
admin_server = kerberos.media.mit.edu
}
ZONE.MIT.EDU = {
kdc = casio.mit.edu
kdc = seiko.mit.edu
admin_server = casio.mit.edu
}
MOOF.MIT.EDU = {
kdc = three-headed-dogcow.mit.edu:88
kdc = three-headed-dogcow-1.mit.edu:88
admin_server = three-headed-dogcow.mit.edu
}
CSAIL.MIT.EDU = {
kdc = kerberos-1.csail.mit.edu
kdc = kerberos-2.csail.mit.edu
admin_server = kerberos.csail.mit.edu
default_domain = csail.mit.edu
krb524_server = krb524.csail.mit.edu
}
IHTFP.ORG = {
kdc = kerberos.ihtfp.org
admin_server = kerberos.ihtfp.org
}
GNU.ORG = {
kdc = kerberos.gnu.org
kdc = kerberos-2.gnu.org
kdc = kerberos-3.gnu.org
admin_server = kerberos.gnu.org
}
1TS.ORG = {
kdc = kerberos.1ts.org
admin_server = kerberos.1ts.org
}
GRATUITOUS.ORG = {
kdc = kerberos.gratuitous.org
admin_server = kerberos.gratuitous.org
}
DOOMCOM.ORG = {
kdc = kerberos.doomcom.org
admin_server = kerberos.doomcom.org
}
ANDREW.CMU.EDU = {
kdc = vice28.fs.andrew.cmu.edu
kdc = vice2.fs.andrew.cmu.edu
kdc = vice11.fs.andrew.cmu.edu
kdc = vice12.fs.andrew.cmu.edu
admin_server = vice28.fs.andrew.cmu.edu
default_domain = andrew.cmu.edu
}
CS.CMU.EDU = {
kdc = kerberos.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}
DEMENTIA.ORG = {
kdc = kerberos.dementia.org
kdc = kerberos2.dementia.org
admin_server = kerberos.dementia.org
}
DOMAIN.LOCAL = {
kdc = primaryserver.domain.local
admin_server = primaryserver.domain.local
default_domain = DOMAIN.LOCAL
}
stanford.edu = {
kdc = krb5auth1.stanford.edu
kdc = krb5auth2.stanford.edu
kdc = krb5auth3.stanford.edu
master_kdc = krb5auth1.stanford.edu
admin_server = krb5-admin.stanford.edu
default_domain = stanford.edu
}

[domain_realm]
.mit.edu = ATHENA.MIT.EDU
mit.edu = ATHENA.MIT.EDU
.media.mit.edu = MEDIA-LAB.MIT.EDU
media.mit.edu = MEDIA-LAB.MIT.EDU
.csail.mit.edu = CSAIL.MIT.EDU
csail.mit.edu = CSAIL.MIT.EDU
.whoi.edu = ATHENA.MIT.EDU
whoi.edu = ATHENA.MIT.EDU
.stanford.edu = stanford.edu
.slac.stanford.edu = SLAC.STANFORD.EDU
.domain.local = DOMAIN.LOCAL
domain.local = DOMAINL.LOCAL

[login]
krb4_convert = true
krb4_get_tickets = false

4 comments:

Anonymous said...

Hi David, thanks for documenting your experience, i'm sure the greater internet thanks you for your efforts.

I was wondering perhaps if you wouldnt mind pasting your full krb5.conf, i'm having some issues with krb5 and seeing a functional config would help tons :)

Regards

Ronald

Unknown said...

Hi Ronald,

I've posted my full krb5.conf file in the original post, hope it helps you!

Cheers,

David

Anonymous said...

Does this same configuration applies to freeRadius running under windows. Like configuring the SAMBA Server?
Sorry I am a newbie and trying to understand the intricacies involved with RADIUS Authentication/Authorization using MS-AD

Unknown said...

I'm not sure about freeRADIUS on Windows. But SAMBA is a free open source implementation of Microsoft's networking stack, so you shouldn't have to install it on Windows.

I'd suggest you lookup the freeRadius website for more info, or perhaps your ever-faithful friend, Google. =)