FreeRadius proxy to MS-NPS for MSCHAPv2 authentication.
Hi, This last week I have been setting up my Aruba environment authenticating users that are in OpenLDAP and all have a Windows Password etc. This installation worked straight out of the box and the part that took most of the time was making a clean setup that I can copy paste to other installations etc and getting to know unlang. So far so good. Now the next question is our partner that is a full M$ shop. They have a Windows ADS environment and all windows users. My first idea was to use proxy.conf to proxy all users with a username of user@domain.com to the MS-NPS server on the Windows ADS. Is this going to work with MSCHAPv2 authentication? I would expect so. If this is going to work my next problem is adding some things to access-accept replies. I need to add: Aruba-User-Vlan = <vlanid> Aruba-User-Role = <authenticated-role> The first one is to set the proper VLAN and the second one is to move the user to an authenticated role of this M$-Shop. Can this be done somewhere in the proxy.conf on the proxy-reply? I really don't want to install Samba on the FreeRadius server and make it authenticate to the ADS, this is because it doesn't scale on the long run if you need to authenticate to more then one ADS environment. I also read that their are some issues with the radius packets that are accepted by the MS-NPS server, with the risk that the packets are dropped at the MS-NPS side. Does someone have a overview of what should be in the radius packets and what should not be in them? Thanks a lot, Jan Hugo Prins
Jan Hugo Prins wrote:
Now the next question is our partner that is a full M$ shop. They have a Windows ADS environment and all windows users. My first idea was to use proxy.conf to proxy all users with a username of user@domain.com to the MS-NPS server on the Windows ADS. Is this going to work with MSCHAPv2 authentication? I would expect so.
Possibly. However, not all packets will contain such a username. They might by "anonymous". As always, read the debug output to be sure.
If this is going to work my next problem is adding some things to access-accept replies. I need to add: Aruba-User-Vlan = <vlanid> Aruba-User-Role = <authenticated-role>
That's what the "post-proxy" section is for. Add the attributes there.
The first one is to set the proper VLAN and the second one is to move the user to an authenticated role of this M$-Shop.
Can this be done somewhere in the proxy.conf on the proxy-reply?
No. See raddb/sites-available/default, the "post-proxy" section.
I also read that their are some issues with the radius packets that are accepted by the MS-NPS server, with the risk that the packets are dropped at the MS-NPS side. Does someone have a overview of what should be in the radius packets and what should not be in them?
Operator-Name. It's a standard attribute that MS doesn't understand properly. The solution is to (a) not proxy it, or (b) update the MS dictionaries. Alan DeKok.
Hi Alan,
Possibly. However, not all packets will contain such a username. They might by "anonymous".
As always, read the debug output to be sure.
So, far all the packets going from the radius server to the DC contain the user-name and the packets coming from the Aruba to the radius server also contain the username, so that seems to be ok for now.
If this is going to work my next problem is adding some things to access-accept replies. I need to add: Aruba-User-Vlan = <vlanid> Aruba-User-Role = <authenticated-role> That's what the "post-proxy" section is for. Add the attributes there.
I found this and it indeed seems to work.
Operator-Name. It's a standard attribute that MS doesn't understand properly. The solution is to (a) not proxy it, or (b) update the MS dictionaries. I haven't seen this attribute yet, but I will keep my eye open for it.
The problem I'm now facing is that I don't seem to get any authentication working. When I use radtest to test the whole radius setup from radius server to DC I get the following which looks ok to me: [root@radius01 ~]# radtest -x -t mschap user01@poc.domain.fqdn xxxxxxxx 172.30.20.16 1812 aixiYax2Vee8pho0 Sending Access-Request of id 241 to 172.30.20.16 port 1812 User-Name = "user01@poc.domain.fqdn" NAS-IP-Address = 172.30.20.16 NAS-Port = 1812 MS-CHAP-Challenge = 0x57c171011e737fa4 MS-CHAP-Response = 0x000100000000000000000000000000000000000000000000000038394ec2dac9ab3d2e76d71779feccca5b80108550e82002 rad_recv: Access-Accept packet from host 172.30.20.16 port 1812, id=241, length=175 Aruba-User-Vlan = 2268 Aruba-User-Role = "authenticated" Class = 0x7e02069e0000013700010200c0a8c91600000000000000000000000001cd31e856b2bb200000000000000051 MS-CHAP-MPPE-Keys = 0x0000000000000000bd1380861c3ea33604446d6b3e05c99d57c171011e737fa4 MS-CHAP-Domain = "\000POC" MS-Link-Utilization-Threshold = 50 MS-Link-Drop-Time-Limit = 120 But when I try to do the same from my laptop trying to do 802.1x through the Aruba it works fine authenticating directly to my radius server / openldap combination but proxying to the AD fails. I have attached the logfiles of the radius server. On the AD I get an error in the eventlog telling the folloing: Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 5/16/2012 12:53:50 PM Event ID: 6274 Task Category: Network Policy Server Level: Information Keywords: Audit Failure User: N/A Computer: DC01.poc.philips.bb Description: Network Policy Server discarded the request for a user. Contact the Network Policy Server administrator for more information. User: Security ID: POC\user01 Account Name: user01@poc.domain2.fqdn Account Domain: POC Fully Qualified Account Name: POC\user01 Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: - Calling Station Identifier: - NAS: NAS IPv4 Address: 172.30.27.1 NAS IPv6 Address: - NAS Identifier: 172.30.27.1 NAS Port-Type: - NAS Port: - RADIUS Client: Client Friendly Name: Radius01 Client IP Address: 172.30.20.16 Authentication Details: Connection Request Policy Name: Use Windows authentication for all users Network Policy Name: Aruba authentication Authentication Provider: Windows Authentication Server: DC01.poc.domain2.fqdn Authentication Type: EAP EAP Type: - Account Session Identifier: - Reason Code: 1 Reason: An internal error occurred. Check the system event log for additional information. Does anyone have an idea what problem I'm facing here? Jan Hugo Prins
Jan Hugo Prins wrote:
So, far all the packets going from the radius server to the DC contain the user-name and the packets coming from the Aruba to the radius server also contain the username, so that seems to be ok for now.
That's good.
The problem I'm now facing is that I don't seem to get any authentication working. When I use radtest to test the whole radius setup from radius server to DC I get the following which looks ok to me:
[root@radius01 ~]# radtest -x -t mschap user01@poc.domain.fqdn xxxxxxxx
OK, that's nice.
But when I try to do the same from my laptop trying to do 802.1x through the Aruba it works fine authenticating directly to my radius server / openldap combination but proxying to the AD fails. I have attached the logfiles of the radius server.
On the AD I get an error in the eventlog telling the folloing: ... Does anyone have an idea what problem I'm facing here?
Ask Microsoft what's wrong with their system. The debug log you posted also shows that IAS is slow and/or discarding packets. Go fix that. Alan DeKok.
Hi,
Ask Microsoft what's wrong with their system.
Never had a situation where Microsoft was answering questions, so I think I have to debug this myself .... found it though.
The debug log you posted also shows that IAS is slow and/or discarding packets. Go fix that. Indeed, the MS Radius server was dropping packets because of a problem with the server. The EAP service was not started and disabled and this resulted in not being able to setup connections. I have it working now.
Thanks. Jan Hugo Prins
On 16/05/12 12:16, Jan Hugo Prins wrote:
Does anyone have an idea what problem I'm facing here?
Wild guess - set "copy_request_to_tunnel = yes" on your EAP method(s). The outer packets contain (amongst others): NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "0023144E6060" Called-Station-Id = "000B866DB51C" Service-Type = Login-User Framed-MTU = 1100 Aruba-Essid-Name = "BBTest" Aruba-Location-Id = "d8:c7:c8:cb:67:0a" Aruba-Attr-10 = 0x544330332d566c6f657232 Since you don't have "copy_request_to_tunnel" set, the inner, and thus proxied, packets don't have these attributes. From experience, NPS policies tend to match on these. Either configure FreeRADIUS to send these attributes (by copying the from outer to inner) or change your NPS policies to not look for them.
participants (3)
-
Alan DeKok -
Jan Hugo Prins -
Phil Mayers