Freeradius + Active Directory
Hello I am trying to get Freeradius to authenticate end-user using Active Directory. The end-user will be using be there AD username and password to login to network devices. Would some please help me? I have embedded a copy of the debug log from the radius server. rad_recv: Access-Request packet from host 192.168.168.252:1645, id=94, length=92 User-Name = "svc-ldap-01@corp-test" User-Password = "WindowsXP!" Service-Type = NAS-Prompt-User NAS-IP-Address = 192.168.168.252 NAS-Port = 10 Calling-Station-Id = "192.168.168.194" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: Looking up realm "corp-test" for User-Name = "svc-ldap-01@corp-test" rlm_realm: No such realm "corp-test" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 modcall[authenticate]: module "unix" returns notfound for request 0 modcall: leaving group authenticate (returns notfound) for request 0 auth: Failed to validate the user. Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 94 to 192.168.168.252 port 1645 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 94 with timestamp 4cbf5aee Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 192.168.168.252:1645, id=95, length=104 User-Name = "svc-ldap-01@corp-test.weather.com" User-Password = "WindowsXP!" Service-Type = NAS-Prompt-User NAS-IP-Address = 192.168.168.252 NAS-Port = 10 Calling-Station-Id = "192.168.168.194" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: Looking up realm "corp-test.weather.com" for User-Name = " svc-ldap-01@corp-test.weather.com" rlm_realm: No such realm "corp-test.weather.com" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 1 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 1 modcall: leaving group authorize (returns ok) for request 1 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 modcall[authenticate]: module "unix" returns notfound for request 1 modcall: leaving group authenticate (returns notfound) for request 1 auth: Failed to validate the user. Delaying request 1 for 1 seconds Finished request 1 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 95 to 192.168.168.252 port 1645 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 95 with timestamp 4cbf5b25 Nothing to do. Sleeping until we see a request.
On 10/20/2010 05:38 PM, Rashard Roberts wrote:
Hello
I am trying to get Freeradius to authenticate end-user using Active Directory. The end-user will be using be there AD username and password to login to network devices. Would some please help me? I have embedded a copy of the debug log from the radius server.
Read the howto's here and follow the instructions: http://deployingradius.com Then read the Active Directory documentation here and follow the instructions: http://deployingradius.com/documents/configuration/active_directory.html -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
I was able to configure FreeRadius/AD differently than most tutorials – just using Kerberos as an authentication mechanism (sorry for any weird formatting, coming from a wiki): All sample configuration will be for cada dev ula environment *Pre-Requisite:* # You have a keytab file for the Kerberos server located at /etc/freeradius/radius.keytab # Your Kerberos principal username is 'freeradius/mat-desktop.security.lab.company.net' {code:title=Define kerberos configurations. (/etc/krb5.conf)} [realms] COMPANY.NET = { kdc = kdc01.security.lab.company.net:88 kdc = kdc02.security.lab.company.net:88 admin_server = kdc01.security.lab.company.net:749 } company.net = { kdc = kdc01.security.lab.company.net:88 kdc = kdc02.security.lab.company.net:88 admin_server = kdc01.security.lab.company.net:749 } {code} _Note: The hostnames MUST resolve through DNS (not /etc/hosts)_ {code:title=Configure the FreeRadius kdc plugin (FREERADIUS_CONFIG_DIR/modules/kdc.conf)} krb5 { keytab = /etc/freeradius/radius.keytab service_principal =freeradius/mat-desktop.security.lab.company.net } {code} {code:title=Add your domain for FreeRadius. (FREERADIUS_CONFIG_DIR/proxy.conf)} realm company.net { } realm COMPANY.NET { } {code} {code:title=Add Kerberos to possible authentication subsystems. (FREERADIUS_CONFIG_DIR/sites-available/default)} authenticate { Auth-Type Kerberos { krb5 } {code} _Note: 'Kerberos' is the string used for 'Auth-Type' RADIUS key; it can be anything, but must be matched with RADIUS attribute 'Auth-Type'_ {code:title=Set your Auth-Type for the realm to authenticate against Kerberos (FREERADIUS_CONFIG_DIR/users)} DEFAULT Realm == "company.net", Auth-Type := Kerberos DEFAULT Realm == "COMPANY.NET", Auth-Type := Kerberos {code} _Note: The ':=' means that the user MUST authenticate using Kerberos_ _Note2: Syntax for users file_ _key \[comparison to request list, assignments to control list\]_ _assignments to reply list #1,_ _assignments to reply list #2,_ _etc._ _Setting "Auth-Type := Kerberos" on the 1st line sets a control item._ _Setting it on the 2nd or subsequent lines sets it in the reply items,_ _where it's meaningless._ Mathew Rowley IIS Network Security Architecture From: Rashard Roberts <grroberts@gmail.com<mailto:grroberts@gmail.com>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Wed, 20 Oct 2010 17:38:30 -0400 To: <freeradius-devel@lists.freeradius.org<mailto:freeradius-devel@lists.freeradius.org>> Cc: <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Freeradius + Active Directory Hello I am trying to get Freeradius to authenticate end-user using Active Directory. The end-user will be using be there AD username and password to login to network devices. Would some please help me? I have embedded a copy of the debug log from the radius server. rad_recv: Access-Request packet from host 192.168.168.252:1645<http://192.168.168.252:1645/>, id=94, length=92 User-Name = "svc-ldap-01@corp-test" User-Password = "WindowsXP!" Service-Type = NAS-Prompt-User NAS-IP-Address = 192.168.168.252 NAS-Port = 10 Calling-Station-Id = "192.168.168.194" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: Looking up realm "corp-test" for User-Name = "svc-ldap-01@corp-test" rlm_realm: No such realm "corp-test" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 modcall[authenticate]: module "unix" returns notfound for request 0 modcall: leaving group authenticate (returns notfound) for request 0 auth: Failed to validate the user. Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 94 to 192.168.168.252 port 1645 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 94 with timestamp 4cbf5aee Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 192.168.168.252:1645<http://192.168.168.252:1645/>, id=95, length=104 User-Name = "svc-ldap-01@corp-test.weather.com<mailto:svc-ldap-01@corp-test.weather.com>" User-Password = "WindowsXP!" Service-Type = NAS-Prompt-User NAS-IP-Address = 192.168.168.252 NAS-Port = 10 Calling-Station-Id = "192.168.168.194" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: Looking up realm "corp-test.weather.com<http://corp-test.weather.com/>" for User-Name = "svc-ldap-01@corp-test.weather.com<mailto:svc-ldap-01@corp-test.weather.com>" rlm_realm: No such realm "corp-test.weather.com<http://corp-test.weather.com/>" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 1 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 1 modcall: leaving group authorize (returns ok) for request 1 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 modcall[authenticate]: module "unix" returns notfound for request 1 modcall: leaving group authenticate (returns notfound) for request 1 auth: Failed to validate the user. Delaying request 1 for 1 seconds Finished request 1 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 95 to 192.168.168.252 port 1645 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 95 with timestamp 4cbf5b25 Nothing to do. Sleeping until we see a request.- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 10/20/2010 10:59 PM, Rowley, Mathew wrote:
I was able to configure FreeRadius/AD differently than most tutorials – just using Kerberos as an authentication mechanism (sorry for any weird formatting, coming from a wiki):
(For the archives) The reason it's different than most tutorials, to be clear, is that this config can only check PAP requests, so is not useful for the common case of PEAP/MS-CHAP for wireless/wired 802.1x. Obviously if you use EAP-TTLS/PAP for 802.1x, or just PAP for some other service (as CLI login to switches/routers usually is) it'll work fine. (People seem to get very confused about this topic, so it's worth noting ;o)
Ah, that is true. I never though that deeply into it, and only did a POC. Is the downfall of doing things this way that passwords must be sent in the clear? On 10/21/10 1:59 AM, "Phil Mayers" <p.mayers@imperial.ac.uk> wrote:
On 10/20/2010 10:59 PM, Rowley, Mathew wrote:
I was able to configure FreeRadius/AD differently than most tutorials just using Kerberos as an authentication mechanism (sorry for any weird formatting, coming from a wiki):
(For the archives)
The reason it's different than most tutorials, to be clear, is that this config can only check PAP requests, so is not useful for the common case of PEAP/MS-CHAP for wireless/wired 802.1x.
Obviously if you use EAP-TTLS/PAP for 802.1x, or just PAP for some other service (as CLI login to switches/routers usually is) it'll work fine.
(People seem to get very confused about this topic, so it's worth noting ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 21/10/10 15:50, Rowley, Mathew wrote:
Ah, that is true. I never though that deeply into it, and only did a POC. Is the downfall of doing things this way that passwords must be sent in the clear?
Not really. The User-Password radius field is "encrypted" with the shared secret, which is reasonable (though not excellent) security. For wireless/wired 802.1x users, the issue is that the windows supplicant does not *support* EAP-TTLS/PAP. It only supports EAP-PEAP/MS-CHAP, so rlm_krb5 is no use in this (common) case. As I say, if you're just checking PAP it may meet your needs.
I am kind of confused - one of our use cases is having our wireless infrastructure authenticating through freeradius and in the end AD. Why would it matter that freeradius uses rlm_krb5? Wouldn¹t it look something like: User----AP----Controller----freeradius----AD Anything-auth radius kerberos Controller configured On 10/21/10 9:16 AM, "Phil Mayers" <p.mayers@imperial.ac.uk> wrote:
On 21/10/10 15:50, Rowley, Mathew wrote:
Ah, that is true. I never though that deeply into it, and only did a POC. Is the downfall of doing things this way that passwords must be sent in the clear?
Not really. The User-Password radius field is "encrypted" with the shared secret, which is reasonable (though not excellent) security.
For wireless/wired 802.1x users, the issue is that the windows supplicant does not *support* EAP-TTLS/PAP. It only supports EAP-PEAP/MS-CHAP, so rlm_krb5 is no use in this (common) case.
As I say, if you're just checking PAP it may meet your needs.
On 10/21/2010 06:40 PM, Rowley, Mathew wrote:
I am kind of confused - one of our use cases is having our wireless infrastructure authenticating through freeradius and in the end AD. Why would it matter that freeradius uses rlm_krb5? Wouldn¹t it look something like:
User----AP----Controller----freeradius----AD Anything-auth radius kerberos Controller configured
This is an FAQ, and you can find plenty of discussion on the list, or see here: http://deployingradius.com/documents/protocols/compatibility.html Suffice to say that there are many different ways to interact with AD, and the different protocols (kerberos, ldap, NT domain RPCs) have very different capabilities. Only one method can authenticate 802.1x from stock windows clients against Active Directory using username/password credentials, and that is the "mschap" module using Samba & domain RPCs via the ntlm_auth helper binary. This is a fundamental cryptographic property of the EAP-PEAP/MSCHAP protocols which windows supports. If you install additional 802.1x supplicant software on your windows clients, you can use another eap method which does send plaintext passwords to the server (e.g. EAP-TTLS/PAP) and rlm_krb5 will be able to process those.
participants (4)
-
John Dennis -
Phil Mayers -
Rashard Roberts -
Rowley, Mathew