Machine authentications with proxy-inner-tunnel and NPS as backend
This isn't really a problem with FreeRADIUS, but maybe someone else here has ever tried this. A short description of our setup: we're trying to use 802.1X on WLAN, with the access points using FreeRADIUS as backend, authenticating via PEAP. FreeRADIUS is configured to use the proxy-inner-tunnel virtual server for this requests, and uses Active Directory 2012R2 as a RADIUS backend (NPS). With user authentication, this works like a charm once you've changed the policy to accept MSCHAPv2 outside of PEAP too. When trying to use this same setup with a machine authentication, the backend replies that the username or password is incorrect. When we're acting as a normal proxy instead of an inner-tunnel-proxy, it just works without any changes on the client pc. Has anyone ever tried something like this and got the setup working? -- Herwin Weststrate
On 21-07-14 11:03, Phil Mayers wrote:
On 21/07/2014 09:49, Herwin Weststrate wrote:
Has anyone ever tried something like this and got the setup working?
I haven't tried it, but there's no fundamental reason it wouldn't work. Can you post a debug i.e. "radiusd -X | tee log" of a failing case?
I've got one at https://gist.github.com/qnet-herwin/ca4b8a7f1d279bffc5c7, but there's not that much information it gives. Starting at line 2052, it tries to send a packet to 10.101.0.227 (which is an NPS) an receives an Access-Reject. There is nothing interesting happening before, and afterwards it behaves like it should when receiving an Access-Reject. In case someone is wondering about the unspecified Vendor Specific Attributes: the are sometimes sent by HP devices, see https://www.mail-archive.com/radiator@open.com.au/msg16094.html The behaviour doesn't change when a different Access Point is used. The exact error message in Active Directory is "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect." -- Herwin Weststrate
Hi,
I've got one at https://gist.github.com/qnet-herwin/ca4b8a7f1d279bffc5c7, but there's
okay. pretty clear - what does the NPS log say? alan
On 21-07-14 15:38, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I've got one at https://gist.github.com/qnet-herwin/ca4b8a7f1d279bffc5c7, but there's
okay. pretty clear - what does the NPS log say?
I already posted that in the e-mail you were quoting:
The exact error message in Active Directory is "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect."
-- Herwin Weststrate
Hi,
Has anyone ever tried something like this and got the setup working?
dont mess with the packets - dont just proxy the inner tunnel to the NPS, send all valid stuff at the outer layer to the NPS box for it to deal with (ie make it the end EAP termination tunnel). you know that nice setting (check cryptobinding) you see on the client? thats designed to check that the EAP termination is actually the same server that unwrapped the TLS in the first instance. use unlang to define the proxy group/realm - proxy stuff to the NPS that matches your desire. alan
On 21/07/2014 10:10, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Has anyone ever tried something like this and got the setup working?
dont mess with the packets - dont just proxy the inner tunnel to the NPS, send
This is a reasonable point, but it doesn't really explain why it works for user but not machine auth... The debug however will almost certainly make that obvious.
On 21-07-14 11:10, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Has anyone ever tried something like this and got the setup working?
dont mess with the packets - dont just proxy the inner tunnel to the NPS, send all valid stuff at the outer layer to the NPS box for it to deal with (ie make it the end EAP termination tunnel). you know that nice setting (check cryptobinding) you see on the client? thats designed to check that the EAP termination is actually the same server that unwrapped the TLS in the first instance. use unlang to define the proxy group/realm - proxy stuff to the NPS that matches your desire.
I don't really see the relevance of cryptobinding here. The EAP tunnel is unpacked, and only the contents of it (slightly modified) is sent to a backend. FreeRADIUS is the EAP terminator and the server that started with the TLS unwrapping. This scenario shouldn't be too weird, or else the virtual server proxy-inner-tunnel would not exist in the distribution. From an EAP point of view, this is not so different from a setup where the users would be defined in the users-file on the FreeRADIUS server. -- Herwin Weststrate
Not at all. You are passing the auth back to another system....this IS different and just because the virtual-server exists it doesnt mean that its applicable to all scenerios where RADIUS is used. I'm guessing the NPS error matches the strong rather than lead to more info. The request is likely not being handled by the NPS box because it's not a method supported by your policy. .. which means that it falls through to the last policy which is what generates the final error you see. Check your policies :) ... and don't be dismissive of help/advice given to you for free on this list. I'd really recommend you read up about the TLV cryptobinding because it's likely to undo all your ideas with a future windows OS or NPS update alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I got our machine wireless auth working under similar configuration as yours except we use FreeRadius with NTLM. No Windows NPS involved. I ran into username and password incorrect issue during setup and fixed it on FR configuration by adding '$' to username: Under authorize {} section of the inner-tunnel. if ( "%{request:User-Name}" =~ /(^host\/)(some regular expression to match machine name pattern)(some regular expression to match domain pattern)*$/i) { update request { Stripped-User-Name := "%{2}$" } } Then pass " Stripped-User-Name " to NTLM. Hope this helps. Yu Wang ____________________________ Network Architect Information Technology Services The Florida State University 850-645-6810 yu.wang@fsu.edu -----Original Message----- From: freeradius-users-bounces+ywang10=fsu.edu@lists.freeradius.org [mailto:freeradius-users-bounces+ywang10=fsu.edu@lists.freeradius.org] On Behalf Of Herwin Weststrate Sent: Monday, July 21, 2014 4:49 AM To: freeradius-users@lists.freeradius.org Subject: Machine authentications with proxy-inner-tunnel and NPS as backend This isn't really a problem with FreeRADIUS, but maybe someone else here has ever tried this. A short description of our setup: we're trying to use 802.1X on WLAN, with the access points using FreeRADIUS as backend, authenticating via PEAP. FreeRADIUS is configured to use the proxy-inner-tunnel virtual server for this requests, and uses Active Directory 2012R2 as a RADIUS backend (NPS). With user authentication, this works like a charm once you've changed the policy to accept MSCHAPv2 outside of PEAP too. When trying to use this same setup with a machine authentication, the backend replies that the username or password is incorrect. When we're acting as a normal proxy instead of an inner-tunnel-proxy, it just works without any changes on the client pc. Has anyone ever tried something like this and got the setup working? -- Herwin Weststrate - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Herwin Weststrate -
Phil Mayers -
Wang, Yu