I am working on a new radius config and have been trying to avoid the lookup in LDAP I have been seeing for the outer identity. I have moved to 2.1.8 with the inner-tunnel virtual host enabled. I have an authorise section for the relevant virtual server that has: authorize { preprocess auth_log chap mschap suffix eap { ok = return } files if (!EAP-Message) { ldap } expiration logintime pap } The "if(!EAP-Message)" works a treat at preventing an LDAP lookup for the outer identity, but if I want to send a basic User-Name/User-Password type auth request after checking with LDAP and returning "Remote access is permitted", I then see: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user What am I missing to tell the "authenticate" section below what I want to do next? authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix Auth-Type LDAP { ldap } Auth-Type EAP { eap } eap } I presume: if (!EAP-Message) { ldap } Fails to set Auth-Type LDAP? ---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540
Dean, Barry wrote:
I am working on a new radius config and have been trying to avoid the lookup in LDAP I have been seeing for the outer identity.
I have moved to 2.1.8 with the inner-tunnel virtual host enabled.
I have an authorise section for the relevant virtual server that has:
*which* virtual server?
The "if(!EAP-Message)" works a treat at preventing an LDAP lookup for the outer identity, but if I want to send a basic User-Name/User-Password type auth request after checking with LDAP and returning "Remote access is permitted", I then see:
No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
And the *rest* of the debug log says.... ?
I presume:
if (!EAP-Message) { ldap }
Fails to set Auth-Type LDAP?
Yes. It *shouldn't*, either. That was a mistake from 1.x. Alan DeKok.
On 13 May 2010, at 06:54, Alan DeKok wrote:
Dean, Barry wrote:
I am working on a new radius config and have been trying to avoid the lookup in LDAP I have been seeing for the outer identity.
I have moved to 2.1.8 with the inner-tunnel virtual host enabled.
I have an authorise section for the relevant virtual server that has:
*which* virtual server?
I have 3 virtual servers on this host, one is for just local authentication, one is for the JANET Roaming Service and one is for our local Guest Wireless service. The config section I posted was from the local auth virtual server. Complete config: # Local auth # server radius { listen { ipaddr = <server ip> port = 0 type = auth } listen { ipaddr = <server ip> port = 0 type = acct } proxy_requests = no $INCLUDE local-clients.conf authorize { preprocess auth_log if ("%{User-Name}" =~ /forbidden/i) { update reply { Reply-Message = "Cannot use this user account" } reject } chap mschap suffix eap { ok = return } files if (!EAP-Message) { ldap } expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix Auth-Type LDAP { ldap } Auth-Type EAP { eap } eap } preacct { preprocess acct_unique suffix files } accounting { detail unix radutmp attr_filter.accounting_response } session { radutmp } post-auth { Post-Auth-Type REJECT { attr_filter.access_reject } reply_log } pre-proxy { pre_proxy_log } post-proxy { eap post_proxy_log } }
The "if(!EAP-Message)" works a treat at preventing an LDAP lookup for the outer identity, but if I want to send a basic User-Name/User-Password type auth request after checking with LDAP and returning "Remote access is permitted", I then see:
No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
And the *rest* of the debug log says.... ?
Complete log is: rad_recv: Access-Request packet from host 192.168.0.10 port 63775, id=111, length=49 User-Name = "user" User-Password = "password" NAS-IP-Address = 192.168.0.10 server radius { +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /log/radacct/192.168.0.10/auth-detail-20100513 [auth_log] /log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /log/radacct/192.168.0.10/auth-detail-20100513 [auth_log] expand: %t -> Thu May 13 09:47:31 2010 ++[auth_log] returns ok ++? if ("%{User-Name}" =~ /forbidden/i) expand: %{User-Name} -> user ? Evaluating ("%{User-Name}" =~ /forbidden/i) -> FALSE ++? if ("%{User-Name}" =~ /forbidden/i) -> FALSE ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Stripped-User-Name = "user" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] returns ok [eap-eduroam] No EAP-Message, not doing EAP ++[eap-eduroam] returns noop ++[files] returns noop [ldap] performing user authorization for user [ldap] expand: %{Stripped-User-Name} -> user [ldap] expand: (sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}) -> (sAMAccountName=user) [ldap] expand: OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk -> OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] attempting LDAP reconnection [ldap] (re)connect to adserver.liv.ac.uk:389, authentication 0 [ldap] bind as CN=radius-account,OU=Service Accounts,OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk/special-password to adserver.liv.ac.uk:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in OU=UOL,DC=adserer,DC=liv,DC=ac,DC=uk, with filter (sAMAccountName=user) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user user authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user. Login incorrect: [user] (from client EZProxy port 0) } # server radius Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> user attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.0.10 port 63775, id=111, length=49 Waiting to send Access-Reject to client EZProxy port 63775 - ID: 111 Sending delayed reject for request 0 Sending Access-Reject of id 111 to 192.168.0.10 port 63775 Waking up in 4.9 seconds. Cleaning up request 0 ID 111 with timestamp +32
I presume:
if (!EAP-Message) { ldap }
Fails to set Auth-Type LDAP?
Yes. It *shouldn't*, either. That was a mistake from 1.x.
I have seen the dire warnings about "Don't set Auth-Type = LDAP" so I have not ventured there as I am sure there are dragons. ---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540
Dean, Barry wrote: ...
[ldap] performing search in OU=UOL,DC=adserer,DC=liv,DC=ac,DC=uk, with filter (sAMAccountName=user) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly?
I mean, really... what's the issue? ...
[pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
That should be a hint. Paste the debugging output into the form at:
++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user. Login incorrect: [user] (from client EZProxy port 0) } # server radius Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> user attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.0.10 port 63775, id=111, length=49 Waiting to send Access-Reject to client EZProxy port 63775 - ID: 111 Sending delayed reject for request 0 Sending Access-Reject of id 111 to 192.168.0.10 port 63775 Waking up in 4.9 seconds. Cleaning up request 0 ID 111 with timestamp +32
I presume:
if (!EAP-Message) { ldap }
Fails to set Auth-Type LDAP? Yes. It *shouldn't*, either. That was a mistake from 1.x.
I have seen the dire warnings about "Don't set Auth-Type = LDAP" so I have not ventured there as I am sure there are dragons.
---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540
------------------------------------------------------------------------
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 13 May 2010, at 10:15, Alan DeKok wrote:
Dean, Barry wrote: ...
[ldap] performing search in OU=UOL,DC=adserer,DC=liv,DC=ac,DC=uk, with filter (sAMAccountName=user) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly?
I mean, really... what's the issue?
The issue is that the self same configuration in FreeRADIUS 2.0.2 works! But with 2.1.8 it fails. The difference in the debug output is: ++[logintime] returns noop rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop rad_check_password: Found Auth-Type ldap auth: type "LDAP" +- entering group LDAP rlm_ldap: - authenticate In FR 2.0.2 this "rad_check_password" is causing LDAP authentication, whereas is FR 2.1.8 the same section of debug output says: ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user.
...
[pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
That should be a hint.
True. My problem was why was LDAP not being attempted for this basic request. No EAP, just a username and a password, which works just fine with FR 2.0.2. In fact with 2.0.2 either: if (!EAP-Message) { ldap } or ldap Works in the authorise section as the Non-EAP request calls ldap either way. With FR 2.1.8, both fail. They follow the same path and produce the "No authentication method ..." error. All the complex EAP/TTLS/PEAP/MSCHAP etc stuff is working with FR 2.1.8 with my config, just the simple stuff is broken. Maybe my question should have been: "FR 2.0.2 reports 'rad_check_password: Found Auth-Type ldap' then goes on to authenticate a user against LDAP, whereas FR 2.1.8 reports that there is no Auth-Type set and does not attempt LDAP authentication." Complete output for working one: rad_recv: Access-Request packet from host 192.168.0.10 port 33158, id=66, length=49 User-Name = "user" User-Password = "password" NAS-IP-Address = 192.168.0.10 server radius { +- entering group authorize ++[preprocess] returns ok expand: /log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /log/radacct/192.168.0.10/auth-detail-20100513 rlm_detail: /log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /log/radacct/192.168.0.10/auth-detail-20100513 expand: %t -> Thu May 13 10:46:02 2010 ++[auth_log] returns ok ++? if ("%{User-Name}" =~ /forbidden/i) expand: %{User-Name} -> user ? Evaluating ("%{User-Name}" =~ /forbidden/i) -> FALSE ++? if ("%{User-Name}" =~ /forbidden/i) -> FALSE ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: Found realm "NULL" rlm_realm: Adding Stripped-User-Name = "user" rlm_realm: Proxying request from user user to realm NULL rlm_realm: Adding Realm = "NULL" rlm_realm: Authentication realm is LOCAL. ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap-eduroam] returns noop users: Matched entry user at line 203 ++[files] returns ok ++? if (!EAP-Message) ? Evaluating !(EAP-Message) -> FALSE ++? if (!EAP-Message) -> TRUE ++- entering if (!EAP-Message) rlm_ldap: - authorize rlm_ldap: performing user authorization for user expand: %{Stripped-User-Name} -> user expand: (sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}) -> (sAMAccountName=user) expand: OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk -> OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to adserver.liv.ac.uk:389, authentication 0 rlm_ldap: bind as CN=radius-account,OU=Service Accounts,OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk/special-password to adserver.liv.ac.uk:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk, with filter (sAMAccountName=user) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? rlm_ldap: Setting Auth-Type = ldap rlm_ldap: user user authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop rad_check_password: Found Auth-Type ldap auth: type "LDAP" +- entering group LDAP rlm_ldap: - authenticate rlm_ldap: login attempt by "user" with password "password" rlm_ldap: user DN: CN=User\, Test,OU=users,OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk rlm_ldap: (re)connect to adserver.liv.ac.uk:389, authentication 1 rlm_ldap: bind as CN=User\, Test,OU=users,OU=UOL,DC=adserver,DC=liv,DC=ac,DC=uk/password to adserveradserver.liv.ac.uk:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user user authenticated succesfully ++[ldap] returns ok Login OK: [user/password] (from client EZProxy port 0) +- entering group post-auth expand: /log/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d -> /log/radacct/192.168.0.10/reply-detail-20100513 rlm_detail: /log/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d expands to /log/radacct/192.168.0.10/reply-detail-20100513 expand: %t -> Thu May 13 10:46:02 2010 ++[reply_log] returns ok } # server radius Finished request 0. Going to the next request Waking up in 0.9 seconds. Waking up in 4.0 seconds. Cleaning up request 0 ID 66 with timestamp +34 Ready to process requests. ---------------------- Barry Dean Principal Programmer/Analyst Networks Group Computing Services Department Tel: 0151 795 9540
Dean, Barry wrote:
The issue is that the self same configuration in FreeRADIUS 2.0.2 works! But with 2.1.8 it fails.
Yes... the behavior changed slightly in the past 2 years. Read raddb/modules/ldap in 2.1.8. Look for "auth_type". This is documented.
"FR 2.0.2 reports 'rad_check_password: Found Auth-Type ldap' then goes on to authenticate a user against LDAP, whereas FR 2.1.8 reports that there is no Auth-Type set and does not attempt LDAP authentication."
Yes. Older versions had the LDAP module set the Auth-Type... which is wrong. Alan DeKok.
<sigh> Dean, Barry wrote: ...
[ldap] performing search in OU=UOL,DC=adserer,DC=liv,DC=ac,DC=uk, with filter (sAMAccountName=user) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly?
Again... ...
[pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
See the form at: http://networkradius.com/freeradius.html It will *highlight* the information you need to know.
I have seen the dire warnings about "Don't set Auth-Type = LDAP" so I have not ventured there as I am sure there are dragons.
The warnings are there because people set it, and the try to do EAP. For some reason, no LDAP server implements EAP. Your choices are: a) fix your LDAP server to return a password b) force Auth-Type := LDAP *only* for certain kinds of packets If you're trying to do EAP with this LDAP server (I presume it's Active Directory), see my web site at http://deployingradius.com/. It has complete instructions. Alan DeKok.
participants (2)
-
Alan DeKok -
Dean, Barry