On Jan 11, 2018, at 10:39 AM, David Hendricks <dahendricks1@gmail.com> wrote:
I have a wireless lab with an Aruba 7005 Controller (ArubaOS 6.5.4.3), and now FreeRADIUS 3.0.15. Client authentication succeeds for both 802.1X and captive portal users. A rule at the controller that is supposed to assign user role based on returned Filter-Id works for the captive portal / guest users but not 802.1X users. Filter-Id = "labguest" but the assigned role is the 802.1X default, "authenticated".
OK.
I posted the issue at https://stackoverflow.com/questions/47681051/server- derived-role-based-on-filterid-using-freeradius-not-working
Don't use stack overflow. I'm sure it's nice and all, but this list is the main support forum for FreeRADIUS. i.e. I don't read stack overflow questions...
"I would like to inform you that I went through the packet captures and I have attached the screenshots from the same based on what we observed; As seen in the CP-Accept screenshot, we see the Radius Accept, for when the user was authenticating with Captive Portal. We see in the accept packet, that the server is sending the attribute 'labguest' to the controller for the user role to be assigned. In the case of Dot1x-Accept screenshot, we do not see any attribute being sent by the server in the accept packet for when the user was authenticating with dot1x authentication.
That should be an easy fix, then.
Please check on the server end if we need to enable sending attribute for MSCHAPv2 along with the PAP protocol, or if there are any specific configurations on the server that are handling the attributes to be sent based on the authentication type."
users file entry: guest123 Cleartext-Password := guest123 Service-Type = Framed-User, Framed-Filter-Id = labguest # Aruba-User-Role = largest
That should work, and should return the Filter-Id.
freeradius -X >debug.txt (during 802.1X authentication) ... (10) Received Access-Request Id 35 from 192.168.18.254:34699 to 192.168.18.249:1812 length 226 (10) User-Name = "guest123"
That's the correct username, good...
(10) NAS-IP-Address = 192.168.18.254 (10) NAS-Port = 0 (10) NAS-Identifier = "192.168.18.254" (10) NAS-Port-Type = Wireless-802.11 (10) Calling-Station-Id = "FCC2DE13D615" (10) Called-Station-Id = "000B86BE91F0" (10) Service-Type = Framed-User (10) Framed-MTU = 1100 (10) EAP-Message = 0x020b002e190017030300230000000000000004f146d1ea0f8955fd7d856784ab41de9850863bcbb43418d874af5a (10) State = 0x272438532e2f215e98ac8b27aec7a2e9 (10) Aruba-Essid-Name = "Lab-Emp" (10) Aruba-Location-Id = "AP2" (10) Aruba-AP-Group = "Lab1" (10) Message-Authenticator = 0xc84dc673770cea5197b5288dd7635f1a (10) session-state: No cached attributes (10) # Executing section authorize from file /etc/freeradius/sites-enabled/default (10) authorize { ... (10) } # policy filter_username = notfound (10) [preprocess] = ok (10) [chap] = noop (10) [mschap] = noop (10) [digest] = noop (10) suffix: Checking for suffix after "@" (10) suffix: No '@' in User-Name = "guest123", looking up realm NULL (10) suffix: No such realm "NULL" (10) [suffix] = noop (10) eap: Peer sent EAP Response (code 2) ID 11 length 46 (10) eap: Continuing tunnel setup (10) [eap] = ok (10) } # authorize = ok (10) Found Auth-Type = eap
Note that it's not running the "files" module. So the "guest123" entry is never being matched. The solution is to move the "files" module to before "eap". Edit raddb/sites-enabled/default. Look at the "authorize" section.
(10) Sent Access-Accept Id 35 from 192.168.18.249:1812 to 192.168.18.254:34699 length 0 (10) MS-MPPE-Recv-Key = 0x1898fd2108c78f60fdd3ebc6e998001935e960f785b5fcb3c1765ba0329c8b90 (10) MS-MPPE-Send-Key = 0xb027c9455d30fd20e58e1db39bea514d5b5deee855e215b8485be483be3060da (10) EAP-Message = 0x030b0004 (10) Message-Authenticator = 0x00000000000000000000000000000000 (10) User-Name = "guest123"
And because it didn't run the "files" module, it didn't return the attribute. As with nearly all of these issues, *reading* the debug output shows the problem clearly. There is a lot of EAP magic in the output, of course. But, it should also be clear when the "files" module is being run. All you need to do is to check for that, and skip the rest of the magic. Alan DeKok.