We have been using FreeRadius for over 10 years to authenticate our PPPoE users. We are putting in a new system that will be using DHCP and would like to authentication and accounting on our DHCP clients. Being these clients may be using their own equipment, MAC address username will not be the best. We have setup our system to use Option 82 to pass the username and password to the DHCP server. I have confirmed that the DHCP is receiving the Option 82 correctly and passing it to FreeRadius as both Agent-Circuit-Id and ADSL-Agent-Circuit-Id. I'm currently trying to figure out the best way to take the information contained in Agent-Circuit-Id and parse that to replace both username and password on the authorize request. Should I try to do this be writing my own ULang script in Policy.d and putting that in the start of authorize {} section? Should I dig into doing it as a PERL script? Seems like FreeRadius is optimized for PERL and doesn't take a performance hit. Has this been done before and I'm just not using the correct keywords in google to find it? I have read in certain posts that modifying User-Name is not recommended. If that is the case what variable should be used and where in the config should it be changed? Thanks -- Thanks, Mark mailto:mark@mailmt.com Myakka Communications www.Myakka.com Serving Manatee and Sarasota Counties with High-Speed Internet for over 20 years
On Jan 13, 2025, at 2:13 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
We have been using FreeRadius for over 10 years to authenticate our PPPoE users. We are putting in a new system that will be using DHCP and would like to authentication and accounting on our DHCP clients. Being these clients may be using their own equipment, MAC address username will not be the best.
DHCP doesn't do authentication and accounting, so you have to design the system carefully to work around those limitations.
We have setup our system to use Option 82 to pass the username and password to the DHCP server. I have confirmed that the DHCP is receiving the Option 82 correctly and passing it to FreeRadius as both Agent-Circuit-Id and ADSL-Agent-Circuit-Id.
I'm currently trying to figure out the best way to take the information contained in Agent-Circuit-Id and parse that to replace both username and password on the authorize request.
Why replace it? That doesn't gain you anything. Why not just allow the user (or not), depending on the information in the packet?
Has this been done before and I'm just not using the correct keywords in google to find it?
What do you actually want to do? i.e. "rewrite User-Name" isn't a requirement, it's a proposed solution. What information are you putting into the User-Name? Where is that information coming from? What database lookups or policies are you running with that User-Name? i.e. there is nothing special about User-Name. If you want to change the SQL queries to do lookups based on MAC address, you can do that. They're text. Just edit them. If you're not finding guides on how to implement a particular solution, then it's likely because no one else is using that solution. Because there are other, better, solutions available.
I have read in certain posts that modifying User-Name is not recommended. If that is the case what variable should be used and where in the config should it be changed?
If the server is doing EAP, you can't modify the User-Name. For other authentication methods it is possible. But generally there are no good reasons for doing that. Alan DeKok.
Alan, Sorry about the delay, your reply landed in my SPAM folder. Current PPPoE setup is as follows. Clients connect to a Mikroik PPPoE server, Mikrotik Authenticates via a FreeRadius Server, FreeRadius Authenticates via a MS SQL Server. We also do accounting. Client uses a Username/Password we supply them. We are implementing some new hardware which would work better if we used DHCP instead of PPPoE. We have setup a Mikrotik DHCP server. Mikrotik allows us to authenticate DHCP request via Radius. We have this piece of the system setup. Currently the way mikrotik authenticates is using device MAC address as username and a blank password. This is a problem being the mac address is supplied by the clients device. We want this to be invisible to the client. If the client decides to change their equipment, we don't want it to generate a service call. We decided to use DHCP Option 82 on our new equipment. Setting it up this way we can have the Option 82 data programmed into our equipment which will stay static. For example we can pass something like XX01-username-password-port-etc. We have the setup and I can confirm the freeradius server is receiving the correct data in the Agent-Circuit-Id. What I would like to do as early as possible in the freeradius process is to extract the username and password from Agent-Circuit-Id and update both username and password with that data. Current issues Agent-Circuit-Id is transferred as hex. Doesn't look like uLang has a hex to string conversion routine. That causes issues with the RegEx extract. That is why I was thinking about dropping into perl I have created a new file in policy.d that I have been fooling around with. Calling my routine just before filter_username in default authorize {} and using update request. Unfortunately, I had to take my test device offline at the lab, so I can't continue testing. I think I'm missing the updated keyword at the end of my routine to tell FreeRadius that I updated the request. That maybe all I'm missing on the procedure. Now I have to do some digging on doing Hex to String. Didn't see anything in the uLang manual for that, but no sure if I dug deep enough. This got a bit wordy, but hopefully it give you a clearer picture. -- Best regards, Mark mailto:mark@mailmt.com Myakka Communications www.Myakka.com ------ Monday, January 13, 2025, 2:58:27 PM, you wrote: AD> On Jan 13, 2025, at 2:13 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
We have been using FreeRadius for over 10 years to authenticate our PPPoE users. We are putting in a new system that will be using DHCP and would like to authentication and accounting on our DHCP clients. Being these clients may be using their own equipment, MAC address username will not be the best.
AD> DHCP doesn't do authentication and accounting, so you have to design the system carefully to work around those limitations.
We have setup our system to use Option 82 to pass the username and password to the DHCP server. I have confirmed that the DHCP is receiving the Option 82 correctly and passing it to FreeRadius as both Agent-Circuit-Id and ADSL-Agent-Circuit-Id.
I'm currently trying to figure out the best way to take the information contained in Agent-Circuit-Id and parse that to replace both username and password on the authorize request.
AD> Why replace it? That doesn't gain you anything. Why not just allow the user (or not), depending on the information in the packet?
Has this been done before and I'm just not using the correct keywords in google to find it?
AD> What do you actually want to do? i.e. "rewrite User-Name" isn't a requirement, it's a proposed solution. AD> What information are you putting into the User-Name? Where is that information coming from? What database lookups or policies are you running with that User-Name? AD> i.e. there is nothing special about User-Name. If you want to change the SQL queries to do lookups based on MAC address, you can do that. They're text. Just edit them. AD> If you're not finding guides on how to implement a particular solution, then it's likely because no one else is using that solution. Because there are other, better, solutions available.
I have read in certain posts that modifying User-Name is not recommended. If that is the case what variable should be used and where in the config should it be changed?
AD> If the server is doing EAP, you can't modify the User-Name. For other authentication methods it is possible. But generally there are no good reasons for doing that. AD> Alan DeKok.
On Jan 15, 2025, at 1:04 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Current PPPoE setup is as follows. Clients connect to a Mikroik PPPoE server, Mikrotik Authenticates via a FreeRadius Server, FreeRadius Authenticates via a MS SQL Server. We also do accounting. Client uses a Username/Password we supply them.
OK.
We are implementing some new hardware which would work better if we used DHCP instead of PPPoE. We have setup a Mikrotik DHCP server. Mikrotik allows us to authenticate DHCP request via Radius. We have this piece of the system setup. Currently the way mikrotik authenticates is using device MAC address as username and a blank password. This is a problem being the mac address is supplied by the clients device. We want this to be invisible to the client. If the client decides to change their equipment, we don't want it to generate a service call.
That makes sense.
We decided to use DHCP Option 82 on our new equipment. Setting it up this way we can have the Option 82 data programmed into our equipment which will stay static. For example we can pass something like XX01-username-password-port-etc. We have the setup and I can confirm the freeradius server is receiving the correct data in the Agent-Circuit-Id.
Hmm... there's no need to send a password. That data is sent over the network in the clear. So any password you send is publicly visible. Which means that the password isn't that useful.
What I would like to do as early as possible in the freeradius process is to extract the username and password from Agent-Circuit-Id and update both username and password with that data.
Sure. If the server is receiving this in RADIUS packets, see mods-available/dhcp. It can decode Option 82 into fields. Or, if this is native DHCP, just update dictionary.dhcp. Define whatever sub-options you need there, and the server will automatically decode them.
Current issues
Agent-Circuit-Id is transferred as hex. Doesn't look like uLang has a hex to string conversion routine. That causes issues with the RegEx extract. That is why I was thinking about dropping into perl
Are you sure it's ASCII HEX? Or just binary data that is printed as hex? The dictionary.dhcp file has DHCP-Agent-Circuit-Id defined as "octets", which is binary data. This means it's printed as hex in debug mode, but the actual data is binary. You shouldn't need to use Perl. Just use the native functionality in FreeRADIUS. It will handle this. And this shouldn't need to be said, but do you have debug putout as suggested in *all* of the documentation? It would help a lot to be able to see the actual contents of Agent-Circuit-Id. i.e. you're asking me for help with a problem, but aren't actually saying what the problem is. You don't need to convert hex to string. You don't need to use Perl. You don't need to use regexes on binary data. Those are all possible solutions, and likely the wrong solution. You should explain what, exactly, is in the Agent-Circuit-ID option. The best way to do this is to post the debug output. This is describing the problem, which then allows us to suggest a good solution. Alan DeKok.
Alan, I will dig into both mods-available/dhcp and dictionary.dhcp. Yes I am running in debug mode. The information you gave me is very useful. Once I have access to my lab again, I'll get back into this. If I hit another road block, I'll make sure to include the data dump. Thank you for your time. -- Best regards, Mark mailto:mark@mailmt.com Myakka Communications www.Myakka.com ------ Wednesday, January 15, 2025, 1:50:20 PM, you wrote: AD> On Jan 15, 2025, at 1:04 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Current PPPoE setup is as follows. Clients connect to a Mikroik PPPoE server, Mikrotik Authenticates via a FreeRadius Server, FreeRadius Authenticates via a MS SQL Server. We also do accounting. Client uses a Username/Password we supply them.
AD> OK.
We are implementing some new hardware which would work better if we used DHCP instead of PPPoE. We have setup a Mikrotik DHCP server. Mikrotik allows us to authenticate DHCP request via Radius. We have this piece of the system setup. Currently the way mikrotik authenticates is using device MAC address as username and a blank password. This is a problem being the mac address is supplied by the clients device. We want this to be invisible to the client. If the client decides to change their equipment, we don't want it to generate a service call.
AD> That makes sense.
We decided to use DHCP Option 82 on our new equipment. Setting it up this way we can have the Option 82 data programmed into our equipment which will stay static. For example we can pass something like XX01-username-password-port-etc. We have the setup and I can confirm the freeradius server is receiving the correct data in the Agent-Circuit-Id.
AD> Hmm... there's no need to send a password. That data is sent over the network in the clear. So any password you send is publicly visible. Which means that the password isn't that useful.
What I would like to do as early as possible in the freeradius process is to extract the username and password from Agent-Circuit-Id and update both username and password with that data.
AD> Sure. If the server is receiving this in RADIUS packets, see mods-available/dhcp. It can decode Option 82 into fields. AD> Or, if this is native DHCP, just update dictionary.dhcp. Define whatever sub-options you need there, and the server will automatically decode them.
Current issues
Agent-Circuit-Id is transferred as hex. Doesn't look like uLang has a hex to string conversion routine. That causes issues with the RegEx extract. That is why I was thinking about dropping into perl
AD> Are you sure it's ASCII HEX? Or just binary data that is printed as hex? AD> The dictionary.dhcp file has DHCP-Agent-Circuit-Id defined as "octets", which is binary data. This means it's printed as hex in debug mode, but the actual data is binary. AD> You shouldn't need to use Perl. Just use the native functionality in FreeRADIUS. It will handle this. AD> And this shouldn't need to be said, but do you have debug putout as suggested in *all* of the documentation? It would help a lot to be able to see the actual contents of Agent-Circuit-Id. AD> i.e. you're asking me for help with a problem, but aren't actually saying what the problem is. AD> You don't need to convert hex to string. You don't need to use Perl. You don't need to use regexes on binary data. Those are all possible solutions, and likely the wrong solution. AD> You should explain what, exactly, is in the Agent-Circuit-ID option. The best way to do this is to post the debug output. This is describing the problem, which then allows us to suggest a good solution. AD> Alan DeKok.
Below is the code I used in a policy.d routine I then added agent_username as the first line in default config at preacct and authorize. This allows me to extract the username and password needed for our system from Agent-Circuit-Id. I have some more testing to do and also have to add some code to skip this if client is using PPPoE and not DHCP. agent_username { #Agent-Circuit-Id needs to be CAST to sting for RegEx #Agent-Circuit-Id format is xxx-aaaaa-uuuuu-xxxxx #Where x is unused in radius #Where a is account number used to build Password #Where u is username if ("%{string:Agent-Circuit-Id}" =~ /(.*)-(.*)-(.*)-(.*)/) { update request { User-Name := "%{3}" User-Password := "dhcp%{2}" } } #Need to issue updated being we change request packet updated } -- Best regards, Mark mailto:mark@mailmt.com Myakka Communications www.Myakka.com ------ Wednesday, January 15, 2025, 2:36:04 PM, you wrote:
Alan,
I will dig into both mods-available/dhcp and dictionary.dhcp. Yes I am running in debug mode. The information you gave me is very useful. Once I have access to my lab again, I'll get back into this. If I hit another road block, I'll make sure to include the data dump.
Thank you for your time.
-- Best regards, Mark mailto:mark@mailmt.com
Myakka Communications www.Myakka.com
------
Wednesday, January 15, 2025, 1:50:20 PM, you wrote:
On Jan 15, 2025, at 1:04 PM, Mark - Myakka Technologies via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Current PPPoE setup is as follows. Clients connect to a Mikroik PPPoE server, Mikrotik Authenticates via a FreeRadius Server, FreeRadius Authenticates via a MS SQL Server. We also do accounting. Client uses a Username/Password we supply them.
OK.
We are implementing some new hardware which would work better if we used DHCP instead of PPPoE. We have setup a Mikrotik DHCP server. Mikrotik allows us to authenticate DHCP request via Radius. We have this piece of the system setup. Currently the way mikrotik authenticates is using device MAC address as username and a blank password. This is a problem being the mac address is supplied by the clients device. We want this to be invisible to the client. If the client decides to change their equipment, we don't want it to generate a service call.
That makes sense.
We decided to use DHCP Option 82 on our new equipment. Setting it up this way we can have the Option 82 data programmed into our equipment which will stay static. For example we can pass something like XX01-username-password-port-etc. We have the setup and I can confirm the freeradius server is receiving the correct data in the Agent-Circuit-Id.
Hmm... there's no need to send a password. That data is sent over the network in the clear. So any password you send is publicly visible. Which means that the password isn't that useful.
What I would like to do as early as possible in the freeradius process is to extract the username and password from Agent-Circuit-Id and update both username and password with that data.
Sure. If the server is receiving this in RADIUS packets, see mods-available/dhcp. It can decode Option 82 into fields.
Or, if this is native DHCP, just update dictionary.dhcp. Define whatever sub-options you need there, and the server will automatically decode them.
Current issues Agent-Circuit-Id is transferred as hex. Doesn't look like uLang has a hex to string conversion routine. That causes issues with the RegEx extract. That is why I was thinking about dropping into perl
Are you sure it's ASCII HEX? Or just binary data that is printed as hex?
The dictionary.dhcp file has DHCP-Agent-Circuit-Id defined as "octets", which is binary data. This means it's printed as hex in debug mode, but the actual data is binary.
You shouldn't need to use Perl. Just use the native functionality in FreeRADIUS. It will handle this.
And this shouldn't need to be said, but do you have debug putout as suggested in *all* of the documentation? It would help a lot to be able to see the actual contents of Agent-Circuit-Id.
i.e. you're asking me for help with a problem, but aren't actually saying what the problem is.
You don't need to convert hex to string. You don't need to use Perl. You don't need to use regexes on binary data. Those are all possible solutions, and likely the wrong solution.
You should explain what, exactly, is in the Agent-Circuit-ID option. The best way to do this is to post the debug output. This is describing the problem, which then allows us to suggest a good solution.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Mark - Myakka Technologies