MAC Authentication Queries
Hi Team, I have recently set up MAC Authentication to happen before my EAP authentication takes over and just had some questions about the configuration I used (found here <https://wiki.freeradius.org/guide/Mac-Auth>). The page states that you should use the below configuration to make this work: if (!ok) { # Reject if the MAC address was not permitted. reject } # If this is NOT 802.1x, mac-auth if (!EAP-Message) { # MAC address has already been checked, so accept update control { Auth-Type := Accept } } else { # Normal FreeRADIUS virtual server config goes here e.g. eap } } But seemingly whenever I enclose the rest of my Authorize config within the final 'else' statement I get an error: */etc/freeradius/3.0/sites-enabled/default[526]: Failed to find "Autz-Type" as a module or policy./etc/freeradius/3.0/sites-enabled/default[526]: Please verify that the configuration exists in /etc/freeradius/3.0/mods-enabled/Autz-Type./etc/freeradius/3.0/sites-enabled/default[526]: Failed to parse "Autz-Type" subsection./etc/freeradius/3.0/sites-enabled/default[285]: Errors parsing authorize section. * If I then take out the 'else' entirely, the error then disappears and my server seems to work fine. It performs the MAC auth, then goes through to doing the EAP-TTLS auth. My question is, is removing the else going to cause issues, and if so, how can I get around my error? Many thanks!
On Sep 26, 2024, at 10:26 AM, FreeRAD <yetifreerad@gmail.com> wrote:
But seemingly whenever I enclose the rest of my Authorize config within the final 'else' statement I get an error:
*/etc/freeradius/3.0/sites-enabled/default[526]: Failed to find "Autz-Type" as a module or policy./etc/freeradius/3.0/sites-enabled/default[526]: Please verify that the configuration exists in
You didn't include the rest if the authorize section within the "else" statement. You included huge amounts more of the server configuration. Don't do that. Use an editor which shows you matching braces. Find the start: authorize { Then find the end: } add the extra brace before that one. It also helps to understand the configuration. Are you sure that you want to comment out the rest of the "authorize" section?
My question is, is removing the else going to cause issues, and if so, how can I get around my error?
Make sure that the configuration file has the correct syntax / format. You can't just add "}" in random places and expect it to work. Alan DeKok.
Hi Alan, Thank you for the reply here. I have put the closing braces only around the Authorize section but this issue is still occurring. I'm not sure what you are referring to about commenting out the rest of the Authorize section? Furthermore, there are plenty of other "if" statements in the various virtual server files that don't also have "else"s, so what is the requirement for it in this situation? I have tested without the else and it seems to work ok but it would be useful to know the implications of this. Many thanks On Thu, Sep 26, 2024 at 12:49 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 26, 2024, at 10:26 AM, FreeRAD <yetifreerad@gmail.com> wrote:
But seemingly whenever I enclose the rest of my Authorize config within the final 'else' statement I get an error:
*/etc/freeradius/3.0/sites-enabled/default[526]: Failed to find "Autz-Type" as a module or policy./etc/freeradius/3.0/sites-enabled/default[526]: Please verify that the configuration exists in
You didn't include the rest if the authorize section within the "else" statement. You included huge amounts more of the server configuration.
Don't do that. Use an editor which shows you matching braces. Find the start:
authorize {
Then find the end:
}
add the extra brace before that one.
It also helps to understand the configuration. Are you sure that you want to comment out the rest of the "authorize" section?
My question is, is removing the else going to cause issues, and if so, how can I get around my error?
Make sure that the configuration file has the correct syntax / format. You can't just add "}" in random places and expect it to work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 26, 2024, at 2:58 PM, FreeRAD <yetifreerad@gmail.com> wrote:
Thank you for the reply here. I have put the closing braces only around the Authorize section but this issue is still occurring.
The default configuration works. If your configuration doesn't work, it's because you edited it, and broke it.
Furthermore, there are plenty of other "if" statements in the various virtual server files that don't also have "else"s, so what is the requirement for it in this situation?
The comments explain what the unlang policies do, and why. There isn't much more I can add.
I have tested without the else and it seems to work ok but it would be useful to know the implications of this.
If it works, it works. Alan DeKok.
Hi Alan, I agree that the default config works fine but this part doesn't seem to the way it is instructed in the FreeRADIUS guide. What is actually supposed to go in the "else" statement? As based on the comments in the "if" statement I would assume it's 'if the MAC is correct and it's not an EAP message then ACCEPT. else, continue through the authorize section'. But this is seemingly what happens if you have the "else" or not. Another thing I have noticed when using the Authorized_Macs module is that I receive an Access-Accept initially once the MAC has been validated, but then I also get "Device with MAC Address %{Calling-Station-ID} authorized for network access" in every subsequent Access-Challenge that is sent from the Server to the NAS when the server is going through EAP-TTLS/PAP authentication. This is sent along with the EAP-Message, Message-Authenticator, and State attributes. Is this sort of behaviour expected? Many thanks! On Thu, Sep 26, 2024 at 3:21 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 26, 2024, at 2:58 PM, FreeRAD <yetifreerad@gmail.com> wrote:
Thank you for the reply here. I have put the closing braces only around the Authorize section but this issue is still occurring.
The default configuration works. If your configuration doesn't work, it's because you edited it, and broke it.
Furthermore, there are plenty of other "if" statements in the various virtual server files that don't also have "else"s, so what is the requirement for it in this situation?
The comments explain what the unlang policies do, and why. There isn't much more I can add.
I have tested without the else and it seems to work ok but it would be useful to know the implications of this.
If it works, it works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 26, 2024, at 4:42 PM, FreeRAD <yetifreerad@gmail.com> wrote:
I agree that the default config works fine but this part doesn't seem to the way it is instructed in the FreeRADIUS guide. What is actually supposed to go in the "else" statement? As based on the comments in the "if" statement I would assume it's 'if the MAC is correct and it's not an EAP message then ACCEPT. else, continue through the authorize section'. But this is seemingly what happens if you have the "else" or not.
See the debug output for why this happens. The entire configuration is documented. How the server processes files is documented. It's not productive for me to cut & paste that documentation to the list.
Another thing I have noticed when using the Authorized_Macs module is that I receive an Access-Accept initially once the MAC has been validated, but then I also get "Device with MAC Address %{Calling-Station-ID} authorized for network access" in every subsequent Access-Challenge that is sent from the Server to the NAS when the server is going through EAP-TTLS/PAP authentication. This is sent along with the EAP-Message, Message-Authenticator, and State attributes. Is this sort of behaviour expected?
It's fine. Alan DeKok.
Hi Alan, All the debug gives me is the error message but no assistance as to why the error message appears. I know it has something to do with what is included in the "else" statement which is why I'm querying what needs to be in the "else" statement. Since based on the guide I mentioned, I have put in there what needs to be put in there. Many thanks On Thu, Sep 26, 2024 at 3:45 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 26, 2024, at 4:42 PM, FreeRAD <yetifreerad@gmail.com> wrote:
I agree that the default config works fine but this part doesn't seem to the way it is instructed in the FreeRADIUS guide. What is actually supposed to go in the "else" statement? As based on the comments in the "if" statement I would assume it's 'if the MAC is correct and it's not an EAP message then ACCEPT. else, continue through the authorize section'. But this is seemingly what happens if you have the "else" or not.
See the debug output for why this happens. The entire configuration is documented. How the server processes files is documented. It's not productive for me to cut & paste that documentation to the list.
Another thing I have noticed when using the Authorized_Macs module is that I receive an Access-Accept initially once the MAC has been validated, but then I also get "Device with MAC Address %{Calling-Station-ID} authorized for network access" in every subsequent Access-Challenge that is sent from the Server to the NAS when the server is going through EAP-TTLS/PAP authentication. This is sent along with the EAP-Message, Message-Authenticator, and State attributes. Is this sort of behaviour expected?
It's fine.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 26, 2024, at 5:17 PM, FreeRAD <yetifreerad@gmail.com> wrote:
All the debug gives me is the error message but no assistance as to why the error message appears. I know it has something to do with what is included in the "else" statement which is why I'm querying what needs to be in the "else" statement. Since based on the guide I mentioned, I have put in there what needs to be put in there.
One approach is to simply try nothing, give up, and ask for help. Another, more productive approach, is to try to understand how the server works. If you look at the page you mentioned, it does not say "blindly put everything into the else statement". You still need to think, and understand what the rest of the "authorize" section does. The "Autz-Type" behavior is documented. You can't just bury it inside of "else" statements. It won't work, and will produce an error. If you want to skip the rest of the "authorize" section, there is a "return" statement. Which is documented. Just go to freeradius.org, and read the online documentation. Alan DeKok.
Hi Alan, The problem is that the only documentation for this specific implementation states "Normal virtual server configuration goes here" and that's it. If I was taking it literally I would have assumed it meant the rest of the virtual server configuration since that's what it says. The way I understand the authorize section to work is that it receives an Access-Request first, validates the information within the Access-Request, and ensures, based on the enabled modules, that the correct attributes are in the Access-Request for the Authentication section to be able to process. If they are, it then sets the Auth-Type for the Authentication section accordingly. Autz-Type is only going to be used if no other module takes responsibility for Authorization similar to how Auth-Type works in Authentication. Many thanks On Fri, Sep 27, 2024 at 9:00 AM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 26, 2024, at 5:17 PM, FreeRAD <yetifreerad@gmail.com> wrote:
All the debug gives me is the error message but no assistance as to why
the
error message appears. I know it has something to do with what is included in the "else" statement which is why I'm querying what needs to be in the "else" statement. Since based on the guide I mentioned, I have put in there what needs to be put in there.
One approach is to simply try nothing, give up, and ask for help. Another, more productive approach, is to try to understand how the server works.
If you look at the page you mentioned, it does not say "blindly put everything into the else statement". You still need to think, and understand what the rest of the "authorize" section does.
The "Autz-Type" behavior is documented. You can't just bury it inside of "else" statements. It won't work, and will produce an error.
If you want to skip the rest of the "authorize" section, there is a "return" statement. Which is documented. Just go to freeradius.org, and read the online documentation.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 27, 2024, at 11:18 AM, FreeRAD <yetifreerad@gmail.com> wrote:
The problem is that the only documentation for this specific implementation states "Normal virtual server configuration goes here" and that's it. If I was taking it literally I would have assumed it meant the rest of the virtual server configuration since that's what it says.
You're treating the MAC auth documentation as magic. i.e. it's perfect, you have to follow it exactly, and you are forbidden from reading any other documentation, or learning from any other documentation. This is the wrong approach.
The way I understand the authorize section to work is that it receives an Access-Request first, validates the information within the Access-Request, and ensures, based on the enabled modules, that the correct attributes are in the Access-Request for the Authentication section to be able to process. If they are, it then sets the Auth-Type for the Authentication section accordingly. Autz-Type is only going to be used if no other module takes responsibility for Authorization similar to how Auth-Type works in Authentication.
I've told you that you can't put the Auto-Type into an "else" statement. Did you read that? Are you going to update your configuration to fix that? It seems like your approach here is to argue about just about everything, and not follow any advice other than the MAC auth guide. I have no idea why. It's not productive. Either follow instructions, or stop asking questions. Alan DeKok.
I'm asking questions about the MAC auth documentation because this is what I am trying to achieve. I have also looked at other documentation and understand the different sections but I am trying to work out how the MAC auth fits into it. I have followed your advice on the Autz-Type and it works but I want to know why specifically the Autz-Type is not to be in there but all my other authorize modules should be. I'm not trying to be argumentative so apologies, there are just some things that I clearly don't fully understand from the documentation alone.
From my understanding of the documentation and the debug logs, FreeRADIUS checks the MAC address against the authorized MACs file, if it is correct and it's not an EAP message it Accepts it. Further information is then sent in the form of a username and password (with EAP information in the Access-Request) from the supplicant and FreeRADIUS sees the EAP attributes and sets the Auth-Type to EAP meaning that the authentication section can take it from there performing EAP auth. I would also hope that my understanding of why the Autz-Type is there is correct. If not then please let me know.
Is there anything wrong with what I have said above. On Fri, Sep 27, 2024 at 10:52 AM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 27, 2024, at 11:18 AM, FreeRAD <yetifreerad@gmail.com> wrote:
The problem is that the only documentation for this specific implementation states "Normal virtual server configuration goes here" and that's it. If I was taking it literally I would have assumed it meant the rest of the virtual server configuration since that's what it says.
You're treating the MAC auth documentation as magic. i.e. it's perfect, you have to follow it exactly, and you are forbidden from reading any other documentation, or learning from any other documentation.
This is the wrong approach.
The way I understand the authorize section to work is that it receives an Access-Request first, validates the information within the Access-Request, and ensures, based on the enabled modules, that the correct attributes are in the Access-Request for the Authentication section to be able to process. If they are, it then sets the Auth-Type for the Authentication section accordingly. Autz-Type is only going to be used if no other module takes responsibility for Authorization similar to how Auth-Type works in Authentication.
I've told you that you can't put the Auto-Type into an "else" statement. Did you read that? Are you going to update your configuration to fix that?
It seems like your approach here is to argue about just about everything, and not follow any advice other than the MAC auth guide. I have no idea why. It's not productive.
Either follow instructions, or stop asking questions.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 27, 2024, at 12:10 PM, FreeRAD <yetifreerad@gmail.com> wrote:
I'm asking questions about the MAC auth documentation because this is what I am trying to achieve. I have also looked at other documentation and understand the different sections but I am trying to work out how the MAC auth fits into it.
MAC auth isn't magic. You keep treating it as if it's magic. Stop. MAC works like _everything_ else in the server. A packet comes in, the data in the packet is used to look up information in DBs. The server replies. It's that easy.
I have followed your advice on the Autz-Type and it works but I want to know why specifically the Autz-Type is not to be in there but all my other authorize modules should be. I'm not trying to be argumentative so apologies, there are just some things that I clearly don't fully understand from the documentation alone.
Autz-Type is documented. I'm not going to copy & paste that documentation here.
From my understanding of the documentation and the debug logs, FreeRADIUS checks the MAC address against the authorized MACs file, if it is correct and it's not an EAP message it Accepts it. Further information is then sent in the form of a username and password (with EAP information in the Access-Request) from the supplicant and FreeRADIUS sees the EAP attributes and sets the Auth-Type to EAP meaning that the authentication section can take it from there performing EAP auth. I would also hope that my understanding of why the Autz-Type is there is correct. If not then please let me know.
You configured FreeRADIUS to take specific actions based on specific rules. Either you understand those rules, or you treat them a magic spells which are not understandable. Only one approach will get you to where you want. Alan DeKok.
Are you able to just tell me whether my understanding is correct or not? It's all based on the documentation so I would guess it is. Any chance you can point me in the direction of the Autz-Type documentation? Because when searched on the FreeRADIS wiki, the only mention of Autz-Type is here <https://wiki.freeradius.org/config/Acct%20Type> which doesn't give much info. There's also nothing in the Network RADIUS Technical guide for it. The most I found was this <https://opensource.apple.com/source/freeradius/freeradius-11/freeradius/doc/Autz-Type.auto.html> . On Fri, Sep 27, 2024 at 11:20 AM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 27, 2024, at 12:10 PM, FreeRAD <yetifreerad@gmail.com> wrote:
I'm asking questions about the MAC auth documentation because this is what I am trying to achieve. I have also looked at other documentation and understand the different sections but I am trying to work out how the MAC auth fits into it.
MAC auth isn't magic. You keep treating it as if it's magic. Stop.
MAC works like _everything_ else in the server. A packet comes in, the data in the packet is used to look up information in DBs. The server replies.
It's that easy.
I have followed your advice on the Autz-Type and it works but I want to know why specifically the Autz-Type is not to be in there but all my other authorize modules should be. I'm not trying to be argumentative so apologies, there are just some things that I clearly don't fully understand from the documentation alone.
Autz-Type is documented. I'm not going to copy & paste that documentation here.
From my understanding of the documentation and the debug logs, FreeRADIUS checks the MAC address against the authorized MACs file, if it is correct and it's not an EAP message it Accepts it. Further information is then sent in the form of a username and password (with EAP information in the Access-Request) from the supplicant and FreeRADIUS sees the EAP attributes and sets the Auth-Type to EAP meaning that the authentication section can take it from there performing EAP auth. I would also hope that my understanding of why the Autz-Type is there is correct. If not then please let me know.
You configured FreeRADIUS to take specific actions based on specific rules. Either you understand those rules, or you treat them a magic spells which are not understandable.
Only one approach will get you to where you want.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 27, 2024, at 12:33 PM, FreeRAD <yetifreerad@gmail.com> wrote:
Are you able to just tell me whether my understanding is correct or not? It's all based on the documentation so I would guess it is.
It's broadly correct. But as I pointed out, the underlying approach is not as productive as it could be.
Any chance you can point me in the direction of the Autz-Type documentation?
The raddb/sites-availalble file describes what each Autz-Type section does. If you're not going to use Autz-Type as per the examples, then you don't need to know any more. Alan DeKok.
participants (2)
-
Alan DeKok -
FreeRAD