FR3.0.11 with ldap + 802.1x + dynamic Vlan assignment.
Hi Freeradius Users, We are using FR3.0.11 and are trying to set up 802.1x authentication. We are using eap-gtc inside peap. Here is what was configured: 1. mods-available/ldap + symlink to mods-enabled/ldap 2. mods-enabled/eap a. EAP section: changed default_eap_type to peap b. PEAP section: changed default_eap_type to gtc 3. mods-config/files/authorize Added the following: DEFAULT Ldap-Group == "juniper-admins" Service-Type = "Login-User", Idle-Timeout = 600, Juniper-Local-User-Name = "admin", Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 505, Filter-Id = "USERS-FILTER" Here is the full debug: http://pastebin.com/Lugmz3yc The result: Ldap works, user gets authenticated, and Access-Accept message is received however Vlan attributes and Filter-id are not present in Access-Accept. Freeradius-2.1.12 version returns attributes just fine. P.S: The reason why i m not using available RPM FR_3.0.4 is because when I perform change number 2.a. (eap section) as described above, freeradius doesn't recognize it and displays default config: ================================================ # Loading module "eap" from file /etc/raddb/mods-enabled/eap eap { default_eap_type = "mschapv2" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 16384 ================================================= I would appreciate any help or point in the right direction. Thanks Vlad
Correction regarding version 3.0.4: The correct output is in peap section, it keeps insisting on mschap after performing the following change: b. PEAP section: changed default_eap_type to gtc Using cached TLS configuration from previous invocation # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_method = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no require_client_cert = no On Wed, Mar 9, 2016 at 3:14 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Hi Freeradius Users,
We are using FR3.0.11 and are trying to set up 802.1x authentication. We are using eap-gtc inside peap.
Here is what was configured:
1. mods-available/ldap + symlink to mods-enabled/ldap
2. mods-enabled/eap a. EAP section: changed default_eap_type to peap b. PEAP section: changed default_eap_type to gtc
3. mods-config/files/authorize
Added the following:
DEFAULT Ldap-Group == "juniper-admins" Service-Type = "Login-User", Idle-Timeout = 600, Juniper-Local-User-Name = "admin", Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 505, Filter-Id = "USERS-FILTER"
Here is the full debug:
The result:
Ldap works, user gets authenticated, and Access-Accept message is received however Vlan attributes and Filter-id are not present in Access-Accept.
Freeradius-2.1.12 version returns attributes just fine.
P.S: The reason why i m not using available RPM FR_3.0.4 is because when I perform change number 2.a. (eap section) as described above, freeradius doesn't recognize it and displays default config:
================================================
# Loading module "eap" from file /etc/raddb/mods-enabled/eap eap { default_eap_type = "mschapv2" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 16384
=================================================
I would appreciate any help or point in the right direction.
Thanks Vlad
On Mar 9, 2016, at 3:38 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Correction regarding version 3.0.4:
The correct output is in peap section, it keeps insisting on mschap after performing the following change:
The server can request GTC. The client can still choose MS-CHAP.
Using cached TLS configuration from previous invocation # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_method = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no
You probably want to set this to "yes". That will cause the inner tunnel reply to be sent in the final Access-Accept Alan DeKok.
Thanks Alan, Setting use_tunneled_reply = yes solved the issue. Interesting to note, that I didn't change this option in radius version 2.1.12 and access-accept still returned vlan and filter-id values. On the other note, can you tell which attribute i could match in access-request message in order to differentiate between 802.1x request and lets say ssh login to network device ? Thanks again, Vlad On Wed, Mar 9, 2016 at 4:07 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 9, 2016, at 3:38 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Correction regarding version 3.0.4:
The correct output is in peap section, it keeps insisting on mschap
after
performing the following change:
The server can request GTC. The client can still choose MS-CHAP.
Using cached TLS configuration from previous invocation # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_method = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no
You probably want to set this to "yes". That will cause the inner tunnel reply to be sent in the final Access-Accept
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mar 9, 2016, at 4:44 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Setting use_tunneled_reply = yes solved the issue.
Interesting to note, that I didn't change this option in radius version 2.1.12 and access-accept still returned vlan and filter-id values.
2.1.12 is extremely old. 3.0 behaves differently for very good reasons, which are documented in the config files.
On the other note, can you tell which attribute i could match in access-request message in order to differentiate between 802.1x request and lets say ssh login to network device ?
Typically, 802.1X will have EAP-Message and admin logins won't... but that's not always the case. As with anything RADIUS, read the debug output. Look at the packets, and see what the differences are. Alan DeKok.
participants (2)
-
Alan DeKok -
Vlad Kratsberg