dot1x, MAB and EAP-TLS/PEAP with Freeradius
Hi, I would like to allow host access to the network according to these restrictions (I am listing only those that require a RADIUS server): 1) wireless clients that connect to a specific SSID are required to either use EAP-TLS or PEAP. If they pass the authorization and authentication they will be dynamically assigned to vlan 112 (base on a local SQL lookup of their MAC addresses). Rejected otherwise. 2) wired clients: a) If they support dot1x, use either EAP-TLS or PEAP and pass then they will be dynamically assigned to vlan 20 (base on a local SQL lookup of their MAC addresses). b) If dot1x fails try MAC Authentication Bypass. The MAC address received by the Freeradius server will be looked up in a local DB, and a VLAN ID will be dynamically assigned accordingly (different vlan IDs except '1'). c) If the MAC address involved in MAB is not found in the local DB then allow access but dynamically assign another vlan ID (eg. 1). I have a FreeRADIUS server and a mix of Cisco and D-Link switches (but I'll be focusing on Cisco because I don't think the D-Link models I have support MAB). Step 1 (wireless clients) has been working fine for years now. I managed to get step 2 working, but then step 1 fails. The configuration is quite long so I hope no one minds if I paste here some sections. Here is the "working" configuration for step 1 (for testing purposes and to simplify debugging I'm just assigning vlan ID 112 when using EAP and vlan ID 1 when not). File 'sites-enabled/default' contains: server default { listen { type = auth ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { ipaddr = * port = 0 type = acct limit { } } listen { type = auth ipv6addr = :: port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { ipv6addr = :: port = 0 type = acct limit { } } authorize { custom_split_username_nai filter_username preprocess custom_filter_default suffix ntdomain -ldap expiration logintime } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } preacct { preprocess acct_unique suffix } accounting { unix exec attr_filter.accounting_response } session { } post-auth { update { &reply: += &session-state: } linelog exec remove_reply_message_if_eap Post-Auth-Type REJECT { linelog attr_filter.access_reject eap remove_reply_message_if_eap } Post-Auth-Type Challenge { } if (EAP-Message) { update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := 112 # &Auth-Type := Accept } } else { update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := 1 # &Auth-Type := Accept } } } pre-proxy { } post-proxy { eap } } --- In file policy.d/filter custom_filter_default looks up MAC addresses in local DB eventually denying some requests. A debug log of a working authentication (step 1) would look something like this: (32) Received Access-Request Id 200 from 192.168.216.22:43597 to 10.215.144.91:1812 length 435 (32) User-Name = "host/HM2214.domain.local" (32) NAS-Identifier = "b4fbe475aed9" (32) Called-Station-Id = "B4-FB-E4-75-AE-D9:HM private access" (32) NAS-Port-Type = Wireless-802.11 (32) Service-Type = Framed-User (32) Calling-Station-Id = "8C-55-4A-D5-73-57" (32) Connect-Info = "CONNECT 0Mbps 802.11b" (32) Acct-Session-Id = "E70814F5EF081437" (32) Acct-Multi-Session-Id = "355A9CEC86878217" (32) WLAN-Pairwise-Cipher = 1027076 (32) WLAN-Group-Cipher = 1027076 (32) WLAN-AKM-Suite = 1027073 (32) Framed-MTU = 1400 (32) EAP-Message = 0x025400ac0d80000000a2160303009d0100009903036317801de99d7d69b9fec9eb8e49887f7c0eb4abedee360ab1fc236b4de4a05800002ac02cc02bc030c02f009f009ec024c023c028c027c00ac009c014c013009d009c003d003c0035002f000a01000046000500050100000000000a00080006001d00170018000b00020100000d001a00180804080508060401050102010403050302030202060106030023000000170000ff01000100 (32) State = 0x0081417701d54caa876904a5f97342cd (32) Message-Authenticator = 0xaf1a468d4f13396bec05eaa4670f2bdc [...] (32) authorize { [...] [ntdomain] = noop (32) [expiration] = noop (32) [logintime] = noop (32) } # authorize = updated (32) Found Auth-Type = eap (32) # Executing group from file /etc/raddb/sites-enabled/default (32) authenticate { (32) eap: Expiring EAP session with state 0x0081417701d54caa (32) eap: Finished EAP session with state 0x0081417701d54caa (32) eap: Previous EAP request found for state 0x0081417701d54caa, released from the list (32) eap: Peer sent packet with method EAP TLS (13) (32) eap: Calling submodule eap_tls to process data (32) eap_tls: (TLS) EAP Peer says that the final record size will be 162 bytes (32) eap_tls: (TLS) EAP Got all data (162 bytes) (32) eap_tls: (TLS) Handshake state - before SSL initialization (0) (32) eap_tls: (TLS) Handshake state - Server before SSL initialization (0) (32) eap_tls: (TLS) Handshake state - Server before SSL initialization (0) (32) eap_tls: (TLS) recv TLS 1.3 Handshake, ClientHello (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read client hello (20) (32) eap_tls: (TLS) send TLS 1.2 Handshake, ServerHello (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server hello (22) (32) eap_tls: (TLS) send TLS 1.2 Handshake, Certificate (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write certificate (23) (32) eap_tls: (TLS) send TLS 1.2 Handshake, ServerKeyExchange (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write key exchange (24) (32) eap_tls: (TLS) send TLS 1.2 Handshake, CertificateRequest (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write certificate request (25) (32) eap_tls: (TLS) send TLS 1.2 Handshake, ServerHelloDone (32) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server done (26) (32) eap_tls: (TLS) Server : Need to read more data: SSLv3/TLS write server done (32) eap_tls: (TLS) In Handshake Phase (32) eap: Sending EAP Request (code 1) ID 85 length 1004 (32) eap: EAP session adding &reply:State = 0x0081417702d44caa (32) [eap] = handled (32) } # authenticate = handled (32) Using Post-Auth-Type Challenge (32) # Executing group from file /etc/raddb/sites-enabled/default (32) Challenge { ... } # empty sub-section is ignored (32) session-state: Saving cached attributes (32) Framed-MTU = 994 (32) Sent Access-Challenge Id 200 from 10.215.144.91:1812 to 192.168.216.22:43597 length 0 [...] (37) authenticate { (37) eap: Expiring EAP session with state 0x0081417706d84caa (37) eap: Finished EAP session with state 0x0081417706d84caa (37) eap: Previous EAP request found for state 0x0081417706d84caa, released from the list (37) eap: Peer sent packet with method EAP TLS (13) (37) eap: Calling submodule eap_tls to process data (37) eap_tls: (TLS) EAP Got final fragment (1012 bytes) (37) eap_tls: (TLS) EAP Done initial handshake (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server done (26) (37) eap_tls: (TLS) recv TLS 1.2 Handshake, Certificate (37) eap_tls: (TLS) Creating attributes from TLS-Client-Cert-Serial certificate (37) eap_tls: (TLS) Creating attributes from server certificate (37) eap_tls: TLS-Cert-Serial := "5b0000000f6866b08df40ccce300010000000f" (37) eap_tls: TLS-Cert-Expiration := "320829094522Z" (37) eap_tls: TLS-Cert-Valid-Since := "220901094522Z" (37) eap_tls: TLS-Cert-Subject := "/DC=local/DC=domain/CN=SUBCAHM" (37) eap_tls: TLS-Cert-Issuer := "/DC=local/DC=domain/CN=CAHM" (37) eap_tls: TLS-Cert-Common-Name := "SUBCAHM" (37) eap_tls: (TLS) Creating attributes from client certificate (37) eap_tls: TLS-Client-Cert-Serial := "3100002953a699132464a0c6c4000800002953" (37) eap_tls: TLS-Client-Cert-Expiration := "230906155017Z" (37) eap_tls: TLS-Client-Cert-Valid-Since := "220906155017Z" (37) eap_tls: TLS-Client-Cert-Subject := "/CN=HM2214.domain.local" (37) eap_tls: TLS-Client-Cert-Issuer := "/DC=local/DC=domain/CN=SUBCAHM" (37) eap_tls: TLS-Client-Cert-Common-Name := "HM2214.domain.local" (37) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Dns := "HM2214.domain.local" (37) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication, TLS Web Server Authentication" (37) eap_tls: TLS-Client-Cert-X509v3-Subject-Key-Identifier += "38:AE:B8:45:E3:FF:5F:E8:6B:E9:F8:CA:8A:DA:0C:C7:55:63:69:71" (37) eap_tls: TLS-Client-Cert-X509v3-Authority-Key-Identifier += "keyid:2B:A9:FC:BD:BA:C9:E4:C0:E2:55:23:36:EB:96:FD:F0:03:CC:53:2D\n" (37) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2" (37) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.1" (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read client certificate (27) (37) eap_tls: (TLS) recv TLS 1.2 Handshake, ClientKeyExchange (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read client key exchange (28) (37) eap_tls: (TLS) recv TLS 1.2 Handshake, CertificateVerify (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read certificate verify (29) (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read change cipher spec (31) (37) eap_tls: (TLS) recv TLS 1.2 Handshake, Finished (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS read finished (32) (37) eap_tls: (TLS) send TLS 1.2 ChangeCipherSpec (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write change cipher spec (35) (37) eap_tls: (TLS) send TLS 1.2 Handshake, Finished (37) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write finished (36) (37) eap_tls: (TLS) Handshake state - SSL negotiation finished successfully (1) (37) eap_tls: (TLS) Connection Established (37) eap_tls: TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384" (37) eap_tls: TLS-Session-Version = "TLS 1.2" (37) eap: Sending EAP Request (code 1) ID 90 length 61 (37) eap: EAP session adding &reply:State = 0x0081417707db4caa (37) [eap] = handled (37) } # authenticate = handled (37) Using Post-Auth-Type Challenge (37) # Executing group from file /etc/raddb/sites-enabled/default (37) Challenge { ... } # empty sub-section is ignored (37) session-state: Saving cached attributes (37) Framed-MTU = 994 (37) TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384" (37) TLS-Session-Version = "TLS 1.2" (37) Sent Access-Challenge Id 205 from 10.215.144.91:1812 to 192.168.216.22:43597 length 0 (37) EAP-Message = 0x015a003d0d80000000331403030001011603030028c62d4b915fa17f780d1eeed1c8df2666d86f908e5ffa52fb0f687cd05e9a61940f477283e89dfc87 (37) Message-Authenticator = 0x00000000000000000000000000000000 (37) State = 0x0081417707db4caa876904a5f97342cd (37) Finished request Waking up in 4.6 seconds. (38) Received Access-Request Id 206 from 192.168.216.22:43597 to 10.215.144.91:1812 length 269 (38) User-Name = "host/HM2214.domain.local" [...] (38) authenticate { (38) eap: Expiring EAP session with state 0x0081417707db4caa (38) eap: Finished EAP session with state 0x0081417707db4caa (38) eap: Previous EAP request found for state 0x0081417707db4caa, released from the list (38) eap: Peer sent packet with method EAP TLS (13) (38) eap: Calling submodule eap_tls to process data (38) eap_tls: (TLS) Peer ACKed our handshake fragment. handshake is finished (38) eap: Sending EAP Success (code 3) ID 90 length 4 (38) eap: Freeing handler (38) [eap] = ok (38) } # authenticate = ok (38) # Executing section post-auth from file /etc/raddb/sites-enabled/default (38) post-auth { (38) update { (38) &reply::Framed-MTU += &session-state:Framed-MTU[*] -> 994 (38) &reply::TLS-Session-Cipher-Suite += &session-state:TLS-Session-Cipher-Suite[*] -> 'ECDHE-RSA-AES256-GCM-SHA384' (38) &reply::TLS-Session-Version += &session-state:TLS-Session-Version[*] -> 'TLS 1.2' (38) } # update = noop (38) linelog: EXPAND messages.%{%{reply:Packet-Type}:-default} (38) linelog: --> messages.Access-Accept (38) linelog: EXPAND Accepted user: %{User-Name} (38) linelog: --> Accepted user: host/HM2214.domain.local (38) linelog: EXPAND /var/log/radius/linelog (38) linelog: --> /var/log/radius/linelog (38) [linelog] = ok (38) [exec] = noop (38) policy remove_reply_message_if_eap { (38) if (&reply:EAP-Message && &reply:Reply-Message) { (38) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (38) else { (38) [noop] = noop (38) } # else = noop (38) } # policy remove_reply_message_if_eap = noop (38) if (EAP-Message) { (38) if (EAP-Message) -> TRUE (38) if (EAP-Message) { (38) update reply { (38) &Tunnel-Type := VLAN (38) &Tunnel-Medium-Type := IEEE-802 (38) &Tunnel-Private-Group-Id := 112 (38) } # update reply = noop (38) } # if (EAP-Message) = noop (38) } # else = noop (38) } # post-auth = ok (38) Login OK: [host/HM2214.domain.local] (from client UH3B3 port 0 cli 8C-55-4A-D5-73-57) (38) Sent Access-Accept Id 206 from 10.215.144.91:1812 to 192.168.216.22:43597 length 0 (38) MS-MPPE-Recv-Key = 0xf4306c74bb325ce7db5a69f321f82830cb28530f48748c69cf1df45cf32f8994 (38) MS-MPPE-Send-Key = 0xd246e7a33f6701cec10c067ab22350bf04080357151e849b8c6038a0e3762cf4 (38) EAP-Message = 0x035a0004 (38) Message-Authenticator = 0x00000000000000000000000000000000 (38) User-Name = "host/HM2214.domain.local" (38) Framed-MTU += 994 (38) Tunnel-Type := VLAN (38) Tunnel-Medium-Type := IEEE-802 (38) Tunnel-Private-Group-Id := "112" (38) Finished request --- So the host HM2214.domain.local is now within vlan 112 and has the expected network access rights. I then tried to modify the Freeradius configuration to allow wired hosts access to the network. Again, to simplify things at first I did not connect a client with dot1x - I just wanted to use MAB. Thus the Cisco switch sends the client's MAC address as the "user name". This is part of a debug log of a successful login of a wired host. (36) Received Access-Request Id 139 from 172.28.175.244:1645 to 172.28.175.254:1812 length 261 (36) User-Name = "c4346b67d37f" (36) User-Password = "c4346b67d37f" (36) Service-Type = Call-Check (36) Cisco-AVPair = "service-type=Call Check" (36) Framed-MTU = 1500 (36) Called-Station-Id = "00-27-90-6C-BA-8D" (36) Calling-Station-Id = "C4-34-6B-67-D3-7F" (36) Message-Authenticator = 0x34433f3a86e93db1665f511096654022 (36) Cisco-AVPair = "audit-session-id=AC1CAFF40000001C2427594E" (36) Cisco-AVPair = "method=mab" (36) NAS-IP-Address = 172.28.175.244 (36) NAS-Port-Id = "GigabitEthernet1/0/13" (36) NAS-Port-Type = Ethernet (36) NAS-Port = 50113 (36) # Executing section authorize from file /etc/raddb/sites-enabled/default (36) authorize { [...] (36) eap: No EAP-Message, not doing EAP (36) [eap] = noop [...] (36) [ntdomain] = noop (36) files: users: Matched entry c4346b67d37f at line 207 (36) [files] = ok (36) [expiration] = noop (36) [logintime] = noop (36) [pap] = updated (36) } # authorize = updated (36) Found Auth-Type = PAP (36) # Executing group from file /etc/raddb/sites-enabled/default (36) Auth-Type PAP { (36) pap: Login attempt with password (36) pap: Comparing with "known good" Cleartext-Password (36) pap: User authenticated successfully (36) [pap] = ok (36) } # Auth-Type PAP = ok (36) # Executing section post-auth from file /etc/raddb/sites-enabled/default (36) post-auth { (36) update { (36) No attributes updated for RHS &session-state: (36) } # update = noop (36) linelog: EXPAND messages.%{%{reply:Packet-Type}:-default} (36) linelog: --> messages.Access-Accept (36) linelog: EXPAND Accepted user: %{User-Name} (36) linelog: --> Accepted user: c4346b67d37f (36) linelog: EXPAND /var/log/radius/linelog (36) linelog: --> /var/log/radius/linelog (36) [linelog] = ok (36) [exec] = noop (36) policy remove_reply_message_if_eap { (36) if (&reply:EAP-Message && &reply:Reply-Message) { (36) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (36) else { (36) [noop] = noop (36) } # else = noop (36) } # policy remove_reply_message_if_eap = noop (36) if (EAP-Message) { (36) if (EAP-Message) -> FALSE (36) else { (36) update reply { (36) &Tunnel-Type := VLAN (36) &Tunnel-Medium-Type := IEEE-802 (36) &Tunnel-Private-Group-Id := 1 (36) } # update reply = noop (36) } # else = noop (36) } # post-auth = ok (36) Login OK: [c4346b67d37f] (from client D2423 port 50113 cli C4-34-6B-67-D3-7F) (36) Sent Access-Accept Id 139 from 172.28.175.254:1812 to 172.28.175.244:1645 length 0 (36) Tunnel-Type := VLAN (36) Tunnel-Medium-Type := IEEE-802 (36) Tunnel-Private-Group-Id := "1" (36) Tunnel-Preference = 0 (36) Finished request In order to get this I modified 'sites-enabled/default' to include 'files' in the 'authorize' section. I also had to add the following in the users file: DEFAULT Auth-Type := Accept That's because I was hoping to accomplish what is stated in Step 2 (c), ie. allow "any" MAC address but assign a different vlan ID. With this configuration wired hosts access "as expected", but wireless hosts with EAP-TLS fail to have access to the network even though the freeradisu debug log reports a "Login OK" line. The EAP messages are not seen in the log so it seems they're being by-passed. I'd like to give more information, but this e-mail is long already -- maybe even too long. What could I try from here? Regards, Vieri
On Sep 7, 2022, at 7:02 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
I would like to allow host access to the network according to these restrictions (I am listing only those that require a RADIUS server):
1) wireless clients that connect to a specific SSID are required to either use EAP-TLS or PEAP. If they pass the authorization and authentication they will be dynamically assigned to vlan 112 (base on a local SQL lookup of their MAC addresses). Rejected otherwise.
2) wired clients:
a) If they support dot1x, use either EAP-TLS or PEAP and pass then they will be dynamically assigned to vlan 20 (base on a local SQL lookup of their MAC addresses).
Are these from different NASes? i.e. are the RADIUS packets for WiFi coming from a different IP address than RADIUS packets for wired? If so, just read sites-available/README, especially section 5. You can use completely different virtual servers for the two cases. It's often difficult to design correct if / then / else logic for complex cases like this. So the simple solution is "don't do that, use a different approach".
b) If dot1x fails try MAC Authentication Bypass. The MAC address received by the Freeradius server will be looked up in a local DB, and a VLAN ID will be dynamically assigned accordingly (different vlan IDs except '1').
c) If the MAC address involved in MAB is not found in the local DB then allow access but dynamically assign another vlan ID (eg. 1).
That "fail over to MAB" is a done by the switch. You just configure FreeRADIUS to allow both 802.1X and MAB.
I have a FreeRADIUS server and a mix of Cisco and D-Link switches (but I'll be focusing on Cisco because I don't think the D-Link models I have support MAB).
Step 1 (wireless clients) has been working fine for years now.
That's good.
I managed to get step 2 working, but then step 1 fails.
Likely because something for step 1 changed.
The configuration is quite long so I hope no one minds if I paste here some sections.
The configuration is generally not helpful. What matters is how it's used, which is the debug output.
So the host HM2214.domain.local is now within vlan 112 and has the expected network access rights.
I then tried to modify the Freeradius configuration to allow wired hosts access to the network. Again, to simplify things at first I did not connect a client with dot1x - I just wanted to use MAB. Thus the Cisco switch sends the client's MAC address as the "user name".
This is part of a debug log of a successful login of a wired host.
Which doesn't show a lot.
In order to get this I modified 'sites-enabled/default' to include 'files' in the 'authorize' section. I also had to add the following in the users file:
DEFAULT Auth-Type := Accept
That's almost always wrong. That tells the server to bypass all authentication, including 802.1X.
That's because I was hoping to accomplish what is stated in Step 2 (c), ie. allow "any" MAC address but assign a different vlan ID.
With this configuration wired hosts access "as expected", but wireless hosts with EAP-TLS fail to have access to the network even though the freeradisu debug log reports a "Login OK" line. The EAP messages are not seen in the log so it seems they're being by-passed.
Exactly.
I'd like to give more information, but this e-mail is long already -- maybe even too long.
What could I try from here?
Don't set a DEFAULT which applies to all packets. Instead, read the debug output to see how the MAB packets are different from the 802.1X packets. Then, write "unlang" rules to match the MAB packets (but not the 802.1X packets!). Something like: authorize { ... if (somehow packet is MAB) { do MAB stuff accept } ... } That will still "accept" the MAB packets, but it won't match the 802.1X packets. Alan DeKok.
On Wed, Sep 7, 2022 at 3:42 PM Alan DeKok <aland@deployingradius.com> wrote:
Are these from different NASes? i.e. are the RADIUS packets for WiFi coming from a different IP address than RADIUS packets for wired?
They are now, but this might change in the future as they might come from the same NASes.
Don't set a DEFAULT which applies to all packets. Instead, read the debug output to see how the MAB packets are different from the 802.1X packets.
Then, write "unlang" rules to match the MAB packets (but not the 802.1X packets!). Something like:
The only thing I found that could identify the packet as being MAB (well, Cisco's MAB implementation) is: Cisco-AVPair = "method=mab" It seems to always be in 3rd position, but I don't know if this is reliable. (1) Cisco-AVPair = "service-type=Call Check" (1) Cisco-AVPair = "audit-session-id=AC1CAFF4000000222E048EA2" (1) Cisco-AVPair = "method=mab" This seems to work fine for me: if ("%{request:Cisco-AVPair[2]}" == "method=mab" && !EAP-Message) -> TRUE as well as this: if ("%{request:Cisco-AVPair[*]}" =~ /method=mab/ && !EAP-Message) -> TRUE I don't know if I should also check for the presence of "service-type=Call Check". So anyway, I can set the following condition in authorize and "accept" without filtering: if ("%{request:Cisco-AVPair[*]}" =~ /method=mab/ && !EAP-Message) { accept } In post-auth I will then add a condition to lookup the MAC addr. in local DB, eg: if (EAP-Message) { # all my wireless and wired EAP-TLS/PEAP clients should go here # determine &MY_VLAN_ID (local DB lookup) update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := &MY_VLAN_ID } } else { # all my other clients should end up here (in my case, via MAB only) # determine &MY_VLAN_ID (different local DB lookup) else &MY_VLAN_ID = 1 update reply { &Tunnel-Type := VLAN &Tunnel-Medium-Type := IEEE-802 &Tunnel-Private-Group-Id := &MY_VLAN_ID } } It seems to be working for me now. Do you see anything foolish security-wise in my setup? Thanks!
On 08/09/2022 11:08, Vieri Di Paola wrote:
On Wed, Sep 7, 2022 at 3:42 PM Alan DeKok <aland@deployingradius.com> wrote:
Then, write "unlang" rules to match the MAB packets (but not the 802.1X packets!). Something like:
The only thing I found that could identify the packet as being MAB (well, Cisco's MAB implementation) is:
Cisco-AVPair = "method=mab"
It seems to always be in 3rd position, but I don't know if this is reliable.
You can enable "with_cisco_vsa_hack" in the preprocess module and add a new local attribute "method" in /etc/raddb/dictionary. Then the preprocess module will convert the fake Cisco AVpair attribute into a real one. Makes things easier. Other usual checks for MAB are that there is no EAP-Message attribute, User-Name and User-Password are identical, and both are a MAC address format.
This seems to work fine for me:
if ("%{request:Cisco-AVPair[2]}" == "method=mab" && !EAP-Message) -> TRUE
Use the preprocess hack and you should then be able to do if (&method == "mab" && !EAP-Message) {
I don't know if I should also check for the presence of "service-type=Call Check".
Doubt it, if you can work out what's going on from other attributes.
So anyway, I can set the following condition in authorize and "accept" without filtering:
if ("%{request:Cisco-AVPair[*]}" =~ /method=mab/ && !EAP-Message) { accept }
You could look up the MAC address here and reject if it is not found, assuming you don't want to allow all MAB auths.
In post-auth I will then add a condition to lookup the MAC addr. in local DB, eg:
Seems OK to me. -- Matthew
On Thu, Sep 8, 2022 at 3:15 PM Matthew Newton <mcn@freeradius.org> wrote:
You can enable "with_cisco_vsa_hack" in the preprocess module and add a new local attribute "method" in /etc/raddb/dictionary. Then the preprocess module will convert the fake Cisco AVpair attribute into a real one. Makes things easier.
Thanks for that.
Other usual checks for MAB are that there is no EAP-Message attribute, User-Name and User-Password are identical, and both are a MAC address format.
True. Thanks for pointing that out. It seems to be working fine now in my scenario. Thanks to all, Vieri
participants (3)
-
Alan DeKok -
Matthew Newton -
Vieri Di Paola