Re: User + Device Authentication to Specific Network
On Jun 8, 2019, at 3:11 AM, Alan DeKok <aland@deployingradius.com> wrote:
That should be pretty simple. Put the MAC addresses into a database, and have FreeRADIUS check the database.
if ("%{sql:SELECT MAC from known_macs WHERE MAC = %{Calling-Station-Id}") { ... add to VLAN 2 ... } else { ... add to VLAN 1 ... }
You'll have to create your own table, and do some more tests. But that's the basic idea. Thank you for the help! I seem to almost have it working, but I've run into one problem: Attributes don't seem to be expanding. I have the following in my post-auth section for testing:
update reply { Unix-FTP-Shell := "%{Calling-Station-Id}" } Every time, Unix-FTP-Shell is set, but it's set to "": (22) # Executing section post-auth from file /etc/raddb/sites-enabled/inner-tunnel (22) post-auth { (22) update reply { (22) &Tunnel-Type := VLAN (22) &Tunnel-Medium-Type := IEEE-802 (22) } # update reply = noop (22) update reply { (22) EXPAND %{Calling-Station-Id} (22) --> (22) Unix-FTP-Shell := (22) } # update reply = noop I've swapped out Calling-Station-Id for a couple other things to test (Tunnel-Type (which I set about 3 lines up) and Service-Type (which came in with the request)), both with the same results. Why are these not getting expanded? Is post-auth the wrong place to do this?
On Jun 10, 2019, at 1:20 AM, Duncan X Simpson <virtualdxs@gmail.com> wrote:
Thank you for the help! I seem to almost have it working, but I've run into one problem: Attributes don't seem to be expanding. I have the following in my post-auth section for testing:
update reply { Unix-FTP-Shell := "%{Calling-Station-Id}" }
Every time, Unix-FTP-Shell is set, but it's set to "":
Read the *rest* of the debug output. Is there a Calling-Station-Id in the incoming packet?
(22) # Executing section post-auth from file /etc/raddb/sites-enabled/inner-tunnel (22) post-auth { (22) update reply { (22) &Tunnel-Type := VLAN (22) &Tunnel-Medium-Type := IEEE-802 (22) } # update reply = noop (22) update reply { (22) EXPAND %{Calling-Station-Id} (22) --> (22) Unix-FTP-Shell := (22) } # update reply = noop
I've swapped out Calling-Station-Id for a couple other things to test (Tunnel-Type (which I set about 3 lines up)
In the reply. NOT in the request. See "man unlang" for how to access the different lists.
and Service-Type (which came in with the request)), both with the same results. Why are these not getting expanded? Is post-auth the wrong place to do this?
Post the WHOLE debug output, and let someone else explain it. But odds are that the Service-Type attribute isn't in the request. There isn't a lot that can go wrong here. Alan DeKok.
On Sun, Jun 9, 2019 at 11:45 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 10, 2019, at 1:20 AM, Duncan X Simpson <virtualdxs@gmail.com>
wrote:
Thank you for the help! I seem to almost have it working, but I've run into one problem: Attributes don't seem to be expanding. I have the following in my post-auth section for testing:
update reply { Unix-FTP-Shell := "%{Calling-Station-Id}" }
Every time, Unix-FTP-Shell is set, but it's set to "":
Read the *rest* of the debug output. Is there a Calling-Station-Id in the incoming packet?
Yep, I double checked that. I was worried that case could be a problem, or a typo, but it's there: (10) Received Access-Request Id 165 from 174.79.36.24:51183 to 192.168.5.51:1812 length 261 (10) User-Name = "duncan" (10) NAS-Identifier = "802AA8834B4728077AE8" (10) Called-Station-Id = "A2-2A-A8-85-4B-47:802.1X test" (10) NAS-Port-Type = Wireless-802.11 (10) Service-Type = Framed-User (10) Calling-Station-Id = "10-98-C3-A9-2C-D4"
In the reply. NOT in the request. See "man unlang" for how to access the different lists.
Thanks for this tip. I was able to successfully expand Tunnel-Type after reviewing that.
Post the WHOLE debug output, and let someone else explain it.
But odds are that the Service-Type attribute isn't in the request. There isn't a lot that can go wrong here.
See above.
On Jun 10, 2019, at 10:59 AM, Duncan X Simpson <virtualdxs@gmail.com> wrote:
Yep, I double checked that. I was worried that case could be a problem, or a typo, but it's there:
(10) Received Access-Request Id 165 from 174.79.36.24:51183 to 192.168.5.51:1812 length 261 (10) User-Name = "duncan" (10) NAS-Identifier = "802AA8834B4728077AE8" (10) Called-Station-Id = "A2-2A-A8-85-4B-47:802.1X test" (10) NAS-Port-Type = Wireless-802.11 (10) Service-Type = Framed-User (10) Calling-Station-Id = "10-98-C3-A9-2C-D4"
Read the *rest* of the debug output.
Post the WHOLE debug output, and let someone else explain it.
Which shows you're running EAP. Which would have been good to know.
But odds are that the Service-Type attribute isn't in the request. There isn't a lot that can go wrong here.
See above.
Again, *read* the debug output. ALL OF IT. If it's hard to read, see: http://wiki.freeradius.org/radiusd-X You're doing EAP. And running the "inner-tunnel" virtual server. Which DOES show the request it receives. AND it shows that request doesn't contain Calling-Station-Id. The relevant lines are below: (9) eap_peap: State = 0x7d495cdf7c54466d1d9baad7442a1d1a (9) Virtual server inner-tunnel received request (9) EAP-Message = 0x021d00061a03 (9) FreeRADIUS-Proxied-To = 127.0.0.1 (9) User-Name = "duncan" (9) State = 0x7d495cdf7c54466d1d9baad7442a1d1a (9) WARNING: Outer and inner identities are the same. User privacy is compromised. (9) server inner-tunnel { (9) session-state: No cached attributes (9) # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel See? No Calling-Station-Id in the inner tunnel. Then later in the same packet, you do: (9) update reply { (9) EXPAND %{request:Calling-Station-Id} (9) --> (9) Unix-FTP-Shell := (9) } # update reply = noop Which makes sense. If you want to access the *outer* Calling-Station-ID attribute, you can do %{outer.request:Calling-Station-Id}. See "man unlang" for details. The debug output is large and complex, but it is *all* there for a reason. If you carefully read it, it will answer most of your questions. In this case: * the update Unix-FTP-Shell is happening in packet (9), so looking at packet (10) is a waste of time * once you see the update Unix-FTP-Shell happening, look BACKWARDS in the debug output to see the "received request" line * which then shows you what packet is being received * AND where that packet came from Alan DeKok.
On Mon, Jun 10, 2019 at 1:46 PM Alan DeKok <aland@deployingradius.com> wrote:
Which shows you're running EAP. Which would have been good to know.
I apologize, I thought 802.1X implied EAP.
Again, *read* the debug output. ALL OF IT. If it's hard to read, see:
http://wiki.freeradius.org/radiusd-X
You're doing EAP. And running the "inner-tunnel" virtual server. Which DOES show the request it receives. AND it shows that request doesn't contain Calling-Station-Id.
I see, I was under the impression that the proxied packet showed up as a (1)/(2)/etc, rather than part of the outer one.
If you want to access the *outer* Calling-Station-ID attribute, you can do %{outer.request:Calling-Station-Id}. See "man unlang" for details.
That did it, and the whole thing makes a lot more sense to me now. I have one last question relating to this. I couldn't find it anywhere in the docs. How do I determine if a user is in a given group in unlang? I can set an attribute in radgroupreply if I need to, but I figure there's probably a cleaner way than that.
On Jun 10, 2019, at 5:04 PM, Duncan X Simpson <virtualdxs@gmail.com> wrote:
That did it, and the whole thing makes a lot more sense to me now.
Sounds good.
I have one last question relating to this. I couldn't find it anywhere in the docs. How do I determine if a user is in a given group in unlang? I can set an attribute in radgroupreply if I need to, but I figure there's probably a cleaner way than that.
FreeRADIUS doesn't have a native concept of groups. That's what a database is for. You can query LDAP groups via the "LDAP-Group" attribute. Alan DeKok.
participants (2)
-
Alan DeKok -
Duncan X Simpson