FilterID or Aruba-User-Role being returned for captive portal but not 802.1X authentication

[David Hendricks]

Alan, I appreciate your help. It works.

I took the time before posting to the user list to try to rule out NAS
issues, and learn enough to ask useful questions and provide proper debug
data.

I hope that helped keep your blood pressure down. I thank you for your
expertise and quick solution.

On Thu, Jan 11, 2018 at 10:54 AM, Alan DeKok <aland at deployingradius.com>
wrote:

> On Jan 11, 2018, at 10:39 AM, David Hendricks <dahendricks1 at 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 =
> > 0x020b002e190017030300230000000000000004f146d1ea0f8955fd7d85
> 6784ab41de9850863bcbb43418d874af5a
> > (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.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html