Hello I am trying to replace a NPS server with freeradius implantation but I am running into a hurdle that basically equates to a go/no go senerio for the project. When NPS (Microsoft Network Policy Server) denies my clients (in this case ip phones) they prompt the user to enter credentials - required for initial setup. However when I take the same device and deny it with freeradius, basically no username and password for the device it does not prompt for no credentials so there is basically no way to setup the device. What I would like to do is replicate the behavior NPS. I am including the screenshot: left is nps - right is freereadius of the reject packet, I can't seem to tell what would cause this over the other so hopefully someone has some insight. I don't think that it maters for this question but the freeradius version is 3.0.4 on Centos 7. Everything is default, clean install except for the client definition for the switch. I am also including the entire packet capture just in case it helps. Thanks Jeremy
hi,
I am also including the entire packet capture just in case it helps.
no. just output of radiusd -X this is probably the simply MSCHAP retry message... so, all you need to do is find the part in your eap module config relating to the mschap and ensuring you enable the error message retry....and then edit the mschap module to also do the same. alan
With these devices it is actually md5. Jeremy
On May 4, 2017, at 5:23 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
I am also including the entire packet capture just in case it helps.
no. just output of radiusd -X
this is probably the simply MSCHAP retry message... so, all you need to do is find the part in your eap module config relating to the mschap and ensuring you enable the error message retry....and then edit the mschap module to also do the same.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I also just went back down through the packet captures and am not seeing a retry message from the NPS server either, just the request and the reject so there must be something different in the reject message that I am simply not seeing that causes the prompt to happen on the phone. Jeremy
On May 4, 2017, at 5:23 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
I am also including the entire packet capture just in case it helps.
no. just output of radiusd -X
this is probably the simply MSCHAP retry message... so, all you need to do is find the part in your eap module config relating to the mschap and ensuring you enable the error message retry....and then edit the mschap module to also do the same.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
okay - NOW look at the packet captures to see what is in the reject message (from NPs and from FR ;-) ) alan On 4 May 2017 at 23:02, Martin, Jeremy <jmartin@emcc.edu> wrote:
I also just went back down through the packet captures and am not seeing a retry message from the NPS server either, just the request and the reject so there must be something different in the reject message that I am simply not seeing that causes the prompt to happen on the phone.
Jeremy
On May 4, 2017, at 5:23 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
I am also including the entire packet capture just in case it helps.
no. just output of radiusd -X
this is probably the simply MSCHAP retry message... so, all you need to do is find the part in your eap module config relating to the mschap and ensuring you enable the error message retry....and then edit the mschap module to also do the same.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
That's my question I guess I am not seeing anything that is really different, that's why I am asking if anyone knowns what it could be as I am really at a loss as the reject messages look the same but produce different behaviors from each platform. Jeremy Sent from my iPhone
On May 4, 2017, at 6:28 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
okay - NOW look at the packet captures to see what is in the reject message (from NPs and from FR ;-) )
alan
On 4 May 2017 at 23:02, Martin, Jeremy <jmartin@emcc.edu> wrote: I also just went back down through the packet captures and am not seeing a retry message from the NPS server either, just the request and the reject so there must be something different in the reject message that I am simply not seeing that causes the prompt to happen on the phone.
Jeremy
On May 4, 2017, at 5:23 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
I am also including the entire packet capture just in case it helps.
no. just output of radiusd -X
this is probably the simply MSCHAP retry message... so, all you need to do is find the part in your eap module config relating to the mschap and ensuring you enable the error message retry....and then edit the mschap module to also do the same.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 4, 2017, at 6:55 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
That's my question I guess I am not seeing anything that is really different, that's why I am asking if anyone knowns what it could be as I am really at a loss as the reject messages look the same but produce different behaviors from each platform.
The problem likely isn't in the final reject. There are lots of other things going on in the EAP messages. The packet traces don't really help a lot, unfortunately. Alan DeKok.
I partly agree, I agree that there are things going on but the part that points to the server having something to do with it is the fact that everything left the save, phone, switches, switch configuration yields a different result only when the radius server is changed so this leads me to believe there must be a difference in some value passed, perhaps to the server, but ultimately back to the switch from the radius server for eap as this is the only variable that changes and I get a different behavior. The good part is it is repeatable the unfortunate part is I am left without anywhere else to look. Jeremy
On May 4, 2017, at 8:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
On May 4, 2017, at 6:55 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
That's my question I guess I am not seeing anything that is really different, that's why I am asking if anyone knowns what it could be as I am really at a loss as the reject messages look the same but produce different behaviors from each platform.
The problem likely isn't in the final reject. There are lots of other things going on in the EAP messages.
The packet traces don't really help a lot, unfortunately.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 4, 2017, at 9:21 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I partly agree, I agree that there are things going on but the part that points to the server having something to do with it is the fact that everything left the save, phone, switches, switch configuration yields a different result only when the radius server is changed so this leads me to believe there must be a difference in some value passed,
As I said... there are a *lot* of things going on with EAP. It's not as simple as "some value". It's a whole set of protocol suites, and a whole set of negotiation. The short answer is that the end system *should* prompt for credentials on first login. After that, you'll probably need to configure MS-CHAP change password. Which means upgrading to 3.0.13. The functionality is documented in raddb/mods-available/mschap. Alan DeKok.
I would like to thank everyone for there time, looks like we are going to have to stick with NPS as it seem to be the product that supports the solution that returns whatever needs to be returned back to the switch. In this particular case though nothing to do with MS-CHAP its all MD5 based. Jeremy
On May 4, 2017, at 10:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
On May 4, 2017, at 9:21 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I partly agree, I agree that there are things going on but the part that points to the server having something to do with it is the fact that everything left the save, phone, switches, switch configuration yields a different result only when the radius server is changed so this leads me to believe there must be a difference in some value passed,
As I said... there are a *lot* of things going on with EAP. It's not as simple as "some value". It's a whole set of protocol suites, and a whole set of negotiation.
The short answer is that the end system *should* prompt for credentials on first login.
After that, you'll probably need to configure MS-CHAP change password. Which means upgrading to 3.0.13. The functionality is documented in raddb/mods-available/mschap.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 4, 2017, at 11:48 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I would like to thank everyone for there time, looks like we are going to have to stick with NPS as it seem to be the product that supports the solution that returns whatever needs to be returned back to the switch. In this particular case though nothing to do with MS-CHAP its all MD5 based.
If it's EAP-MD5, then there is *nothing* in the packets which can cause this behaviour. EAP-MD5 simply doesn't support that functionality. And the packet traces you posted are unhelpful. For one, they contain tons of non-EAP / non-RADIUS traffic. There's no reason to send ARP captures to this list. For two, they contain *both* EAPoL and RADIUS traffic. This doesn't make sense. If you're authenticating an end device, it should NEVER get RADIUS traffic. And the only EAP traffic is Identity request / response packets. And the only RADIUS traffic is Access-Reject. Nothing about that traffic makes any sense whatsoever. Something else is going on. Alan DeKok.
Ok I have figured out what is going on here: With NPS when a user account is disabled or the account is set to be rejectged what happens is this: Radius: Access-Request from switch comes in Radius: Access-Reject from radius server The result here is that the phone prompts for credentials Freeradius configured as > user name Auth-Type:=Reject for disabled account Access-Request from switch comes in Access-Challenge from server Access-Request from switch Access-Reject from server So what happens is when a reject is returned without a challenge the end device knows that it needs to prompt for credentials but when the server issues the challenge and then the rejection happens the device does not prompt. So the question now is how can I can configure freeradius to issue a access-reject message without a challenge for disabled users so I can set the initial password in the end device, again with Avaya IP 9608 Phones this is the only way to be prompted for 802.1x credentials? Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 5, 2017 7:37 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeraius vs NPS On May 4, 2017, at 11:48 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I would like to thank everyone for there time, looks like we are going to have to stick with NPS as it seem to be the product that supports the solution that returns whatever needs to be returned back to the switch. In this particular case though nothing to do with MS-CHAP its all MD5 based.
If it's EAP-MD5, then there is *nothing* in the packets which can cause this behaviour. EAP-MD5 simply doesn't support that functionality. And the packet traces you posted are unhelpful. For one, they contain tons of non-EAP / non-RADIUS traffic. There's no reason to send ARP captures to this list. For two, they contain *both* EAPoL and RADIUS traffic. This doesn't make sense. If you're authenticating an end device, it should NEVER get RADIUS traffic. And the only EAP traffic is Identity request / response packets. And the only RADIUS traffic is Access-Reject. Nothing about that traffic makes any sense whatsoever. Something else is going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 5, 2017, at 11:15 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
Ok I have figured out what is going on here:
With NPS when a user account is disabled or the account is set to be rejectged what happens is this: Radius: Access-Request from switch comes in Radius: Access-Reject from radius server
Do you have a PCAP of that happening? i.e. *just* those RADIUS packets? Because that's not the way EAP is supposed to work. I'd argue that it's explicitly forbidden by the EAP standards.
So what happens is when a reject is returned without a challenge the end device knows that it needs to prompt for credentials but when the server issues the challenge and then the rejection happens the device does not prompt.
So the question now is how can I can configure freeradius to issue a access-reject message without a challenge for disabled users so I can set the initial password in the end device, again with Avaya IP 9608 Phones this is the only way to be prompted for 802.1x credentials?
authorize { if (... bad user ...) { reject } } How you determine "bad user" is up to you. Typically it's done via an LDAP query. You can test this yourself by just rejecting all requests for a particular user. Then, looking at the debug log to see what the server is doing. The post-auth section (in v3 at least) has code to insert an EAP failure if a request is rejected early. So that should Just Work. Alan DeKok.
I am attaching them to this email. Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 5, 2017 11:19 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeraius vs NPS On May 5, 2017, at 11:15 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
Ok I have figured out what is going on here:
With NPS when a user account is disabled or the account is set to be rejectged what happens is this: Radius: Access-Request from switch comes in Radius: Access-Reject from radius server
Do you have a PCAP of that happening? i.e. *just* those RADIUS packets? Because that's not the way EAP is supposed to work. I'd argue that it's explicitly forbidden by the EAP standards.
So what happens is when a reject is returned without a challenge the end device knows that it needs to prompt for credentials but when the server issues the challenge and then the rejection happens the device does not prompt.
So the question now is how can I can configure freeradius to issue a access-reject message without a challenge for disabled users so I can set the initial password in the end device, again with Avaya IP 9608 Phones this is the only way to be prompted for 802.1x credentials?
authorize { if (... bad user ...) { reject } } How you determine "bad user" is up to you. Typically it's done via an LDAP query. You can test this yourself by just rejecting all requests for a particular user. Then, looking at the debug log to see what the server is doing. The post-auth section (in v3 at least) has code to insert an EAP failure if a request is rejected early. So that should Just Work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 5, 2017, at 11:46 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I am attaching them to this email.
Wow... the phone is just broken. It's sending an EAP-Identity of: 0xa009ed031e00 i.e. the MAC address of the phone... in binary form, NOT text, and finishing off with a trailing zero byte. What phone is this? That behavior is completely broken, and violates RFC 3748: https://tools.ietf.org/html/rfc3748#section-5.1 This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In any case, the suggestion I made in my last message should work. Though it will be made more complicated by the phone sending binary crap as the EAP-Identitiy, instead of a UTF-8 text string. Alan DeKok.
Alan These are avaya ip phones. Not see what you are referring to, I was looking at packet 1943, the first on the free radius capture byte 0040 looks like the user-name is encoded correctly but not really sure where you are looking. Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 5, 2017 11:54 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeraius vs NPS
On May 5, 2017, at 11:46 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I am attaching them to this email.
Wow... the phone is just broken. It's sending an EAP-Identity of: 0xa009ed031e00 i.e. the MAC address of the phone... in binary form, NOT text, and finishing off with a trailing zero byte. What phone is this? That behavior is completely broken, and violates RFC 3748: https://tools.ietf.org/html/rfc3748#section-5.1 This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In any case, the suggestion I made in my last message should work. Though it will be made more complicated by the phone sending binary crap as the EAP-Identitiy, instead of a UTF-8 text string. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, Thank you for you help, I think I am starting to get a handle on this problem. I added a check in the sites-enabled default file that did the trick and isolated it to one set and sure enough it kicked back and asked me for some credentials: authorize { if (User-Name == "A009ED031E00") { reject } .... } Log Entries: # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) if (User-Name == "A009ED031E00") (0) if (User-Name == "A009ED031E00") -> TRUE (0) if (User-Name == "A009ED031E00") { (0) [reject] = reject (0) } # if (User-Name == "A009ED031E00") = reject (0) } # authorize = reject Now for my last question (hopefully) before I go off and dig into the docs and examples, is there a table already setup that would make this check against a mysql table so I can easily write an interface so I don't have to train my techs to edit this file when setting up a new phone? Or if you have another reasonable way of don't it that I can write against using some web interface I would certainly entertain that option as well. I am certainly not against reading the docs but if there are any head starts they would appreciated. In any event I am certainly glad to know what is going to at least, so thanks for the help thus far. Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 5, 2017 11:54 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeraius vs NPS
On May 5, 2017, at 11:46 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
I am attaching them to this email.
Wow... the phone is just broken. It's sending an EAP-Identity of: 0xa009ed031e00 i.e. the MAC address of the phone... in binary form, NOT text, and finishing off with a trailing zero byte. What phone is this? That behavior is completely broken, and violates RFC 3748: https://tools.ietf.org/html/rfc3748#section-5.1 This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In any case, the suggestion I made in my last message should work. Though it will be made more complicated by the phone sending binary crap as the EAP-Identitiy, instead of a UTF-8 text string. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 5, 2017, at 12:51 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
Thank you for you help, I think I am starting to get a handle on this problem.
I added a check in the sites-enabled default file that did the trick and isolated it to one set and sure enough it kicked back and asked me for some credentials:
That's good.
Now for my last question (hopefully) before I go off and dig into the docs and examples, is there a table already setup that would make this check against a mysql table so I can easily write an interface so I don't have to train my techs to edit this file when setting up a new phone? Or if you have another reasonable way of don't it that I can write against using some web interface I would certainly entertain that option as well. I am certainly not against reading the docs but if there are any head starts they would appreciated.
Since this isn't a common problem, there are no pre-packaged solutions This is where it's really "roll your own". You can out the phone MAC addresses into an SQL table, and then write "unlang" rules to look up the MAC in the SQL table. i.e. write down what you need to track, and what you need the server to do, and then implement those policies in "unlang".
In any event I am certainly glad to know what is going to at least, so thanks for the help thus far.
It's what I do... Alan DeKok.
For the sake of completeness and my own sanity if I have to tackle this issue again in the future the following was the solution to my problem: authorize { if ("%{sql:SELECT COUNT(username) FROM radreject WHERE UPPER(username) = UPPER('%{User-Name}')}" > 0) { reject } ... } Where radreject is a mysql table that contains two columns, and id and username. Again thanks to everyone that helped point me in the right direction. Jeremy -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+jmartin=emcc.edu@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, May 5, 2017 1:24 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Freeraius vs NPS On May 5, 2017, at 12:51 PM, Martin, Jeremy <jmartin@emcc.edu> wrote:
Thank you for you help, I think I am starting to get a handle on this problem.
I added a check in the sites-enabled default file that did the trick and isolated it to one set and sure enough it kicked back and asked me for some credentials:
That's good.
Now for my last question (hopefully) before I go off and dig into the docs and examples, is there a table already setup that would make this check against a mysql table so I can easily write an interface so I don't have to train my techs to edit this file when setting up a new phone? Or if you have another reasonable way of don't it that I can write against using some web interface I would certainly entertain that option as well. I am certainly not against reading the docs but if there are any head starts they would appreciated.
Since this isn't a common problem, there are no pre-packaged solutions This is where it's really "roll your own". You can out the phone MAC addresses into an SQL table, and then write "unlang" rules to look up the MAC in the SQL table. i.e. write down what you need to track, and what you need the server to do, and then implement those policies in "unlang".
In any event I am certainly glad to know what is going to at least, so thanks for the help thus far.
It's what I do... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 8, 2017, at 10:08 AM, Martin, Jeremy <jmartin@emcc.edu> wrote:
For the sake of completeness and my own sanity if I have to tackle this issue again in the future the following was the solution to my problem:
authorize {
if ("%{sql:SELECT COUNT(username) FROM radreject WHERE UPPER(username) = UPPER('%{User-Name}')}" > 0) { reject }
That's a good solution. We recommend using custom tables for custom rules. The one thing I'd say is that you probably *also* want to reject users whose User-Names don't have the correct case. i.e. if the user's name is "bob", and they log in as "Bob", or "bOb", those attempts should be rejected *no matter what*. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Martin, Jeremy