none
EAP-PEAP-MSCHAPv2 Realm Stripping RRS feed

  • Question

  • Hi,

    I'm having some problems here to get our Wifi setup working. The setup basically comes down to this, we're using PEAP-MSCHAPv2 as authentication mechanism and the native Windows WZC clients to setup the connection and to provide the credentials.

    There would be no problem if we were just using this on our own internal network/domain but because we're a school we want to participate in the Eduroam project which means we have to be able to authenticate users with the following username format: domain.country\username or username@domain.country. The NPS setup I have now only seems to be able to handle logins with the format of: usernam, domain\username or username@domain. This doesn't work with the Eduroam setup because they need the realm part to do the necessary proxying between the participating institutes and so they need the countrysuffix part in the outer identity.

    If I use another wirelessclient on the clients (like the Intel PROSet) I'm able to configure the outer and inner identity differently which, technically speaking, would be a solution if it were not that a lot of our students can't use the Intel PROSet becausen they have a non Intel wifichip.

    I've also seen that it's possible to do some attribute manipulation in NPS in the CRP but it seems to me that this only manipulates the outer identity part and not the inner part because then the authentication still fails. I tried this on the username by using the pattern ".*\\(.*)" and replacing it with "DOMAIN\$1", the manipulation seems to work according to the eventlogs but the authentication still fails.

    Any ideas on how to handle this?

    Thursday, April 1, 2010 12:26 PM

All replies

  • Hi,

    Have you read this topic and used the techniques described?

    http://technet.microsoft.com/en-us/library/cc731342(WS.10).aspx

    I may not fully understand your scenario. Are the users, and the NPS both members of the domain DOMAIN but they are supplying credentials as: user@DOMAIN.country? What is the primary DNS suffix on client computers?

    Thanks,

    -Greg

    Saturday, April 10, 2010 5:40 AM
    Owner
  • I think am also having this problem.

     

    It looks like the realm stripping only affects the outer PEAP identity.

     

    The realm stripping works fine with IAS on windows 2003 server.

     

    Monday, December 13, 2010 5:33 PM
  • I also have problem with real stripping, server 2008R2 and with IAS on 2003R2 to.

    any suggestion?

     

    Thursday, March 3, 2011 10:43 AM
  • Hi

    I suggest starting your own thread and explaining the problem in detail.. This way we cn work on the issue after having better understood your scenario and set up :)


    tech-nique
    Thursday, March 3, 2011 2:55 PM
  • hi jeles

     

    realm stripping works for me on win2003 with IAS.

     

    one answer is to revert to windows 2008 (non R2). realm stripping works with that.

    or alternatively, use freeradius on linux.

     

    i opened a case with the UK academic support people. they spoke to microsoft and confirmed the way NPS works has changed from the way IAS worked on windows 2003 and NPS on windows 2008 (non R2). both of these allow realm stripping to work.

     

    so, unless microsoft change the way NPS works in windows 2008R2,   back to the way it used to work in win2008R1/IAS on win2003, we cant use it.

    the solution i am looking at is to use freeradius on linux.

     

    Thursday, March 3, 2011 4:16 PM
  • ncl,

     thank you very much for quick answer.  i already setup IAS on server 2003r2, and everything is working fine.

    regards,

    jelesp

    Monday, March 7, 2011 10:59 AM
  • In a typical Microsoft fashion this is a feature, not a bug..

    NPS authenticates the user against the UPN. By default this is the username@domain. This default however can be changed by adding a UPN suffix to the AD forest.

    This is done in "Active Directory Domains and Trusts". When you right click on the root item (which is Active Directory Domains and Trusts) which sits on top of the tree and click on properties, you can add the UPN suffixes you need.

    This however is only half of the solution. You now have to go to "Active Directory Users and Computers" and change the UPN suffix for the users you want to use in eduroam to the new UPN suffix you have created. This can be done by first selecting all users this applies to and then ricght-click and select propertiets. There you can change the UPN suffix.

    Users can now use eduroam with the correct realm, but still log in with the original domain name!

    Like in our case our domain is hsleiden.intra but we have two alternate UPN suffixes  hsleiden.nl for staff and student.hsleiden.nl for students.

    Each group of users we have set the UPN suffix to the correct group but the can all still login using @hsleiden.intra or HL\<student name>

     

    Hope this helps,

     

    Jan Willem Smeenk

    Hogeschool Leiden

    The Netherlands

     

     

     

     

    Tuesday, May 31, 2011 1:00 PM
  • Hi.

     

    I am one of the engineers that worked with NCL on the eduroam issue with realm stripping and I just noticed this thread. As way of an update to you all.. I am currently working with another uk site to resolve this problem.

    While adding a UPN suffix is a fix for this problem (we don't think you need to change the primary UPN suffix), it also works if you have  2008 box at the front that proxies back to another in the background.

    The official line from Microsoft is below and confirms that in NPS the realm stripping is only designed to be used when proxying requests from front to back. So this is by design and not classed as a bug.

    The behavior with regards to local processing of realm stripping rules has changed between IAS in 2003 and NPS in 2008 in order to support NAP within PEAP. The reason realm stripping rules are available at the Connection Request Policy (CRP) level is to support RADIUS Proxy, to specify that if a connection request realm name matches a specific string, then forward the request to a different RADIUS server, and change the realm name to a different string as appropriate. Here is some documentation on Realm Replacement as related to NPS:

    http://technet.microsoft.com/en-us/library/cc731342(WS.10).aspx

    Realm replacement for PEAP could be done for locally authenticated (not proxied) connections in 2003 IAS because the network authentication was always done at the Network Access Policy level rather than at the CRP, but this was never intended functionality of realm stripping rules. With the introduction of Network Access Protection (NAP) in Server 2008 NPS, the PEAP authentication must be done at the CRP level to support inclusion of the Statement of Health (SoH) in the access request. Further changes in 2008 R2 NPS introduced support for PEAP Identity Privacy, which also requires processing of authentication at the CRP. The changes made to PEAP cause local realm stripping to no longer work, since the identity presented at the CRP does not match the identity seen at the Network Policy level.

     

    Realm stripping still works as intended in NPS for RADIUS Proxy, but the way it functioned for local processing in IAS can no longer be implemented due to changes needed for NAP and PEAP ID Privacy. To accomplish the desired behavior using NPS, either switch to EAP-TLS for authentication, which does not have the concept of an outer and inner identity, or simply deploy NPS as a RADIUS proxy in the way the functionality was intended. Configure the realm stripping rules on a front-end NPS server to modify the identity specified in the Access-Request, and then forward it to a second NPS server for authorization and authentication. This allows for full functionality available in PEAP and addresses the unique needs for the customer environment.

    Thursday, July 28, 2011 4:16 PM
  • I am one of the engineers that worked with NCL on the eduroam issue with realm stripping and I just noticed this thread. As way of an update to you all.. I am currently working with another uk site to resolve this problem.

    Hi - like some of the other posters on this thread, I'm also wanting to use NPS with eduroam. It seems like the two options I have are:

    1. Use UPNs and make sure that what prefixes the @ not only matches the UPN but also matches the domain account name so that when the suffix is stripped, NPS still matches the account name when the domain is prefixed, i.e. fred@abc.com => fred => dom\fred.
    2. Use another RADIUS server (either an older Windows one or FreeRADIUS or similar) as the primary server for the WiFi system. It then forwards @abc.com authentication requests to the NPS (2008 R2) and all the other requests upstream to the national eduroam servers.

    Is that correct? Is there any way of getting this to work with JUST NPS 2008 R2?

    Regards

    Philip

    Tuesday, August 23, 2011 7:36 AM
  • Philip.

     

    I am waiting for an official comment myself on this issue, but hope to have something in the next few days.

    We have found that using Server 2008 NPS at the front end and 2003 IAS in the back works, as does adding a second UPN to the users. Using a second UPN should mean that you only need to deploy a single NPS server. As soon as I have more information, I will post here and let you know.

    Tuesday, August 23, 2011 3:06 PM
  • We have found that using Server 2008 NPS at the front end and 2003 IAS in the back works, as does adding a second UPN to the users. Using a second UPN should mean that you only need to deploy a single NPS server. As soon as I have more information, I will post here and let you know.


    The problem I've got with the UPN approach is that at the moment I have it following the same pattern we use for our email addresses, e.g. fred.bloggs@abc.com. But we have the account names just set to the user's first name, e.g. fred.

    If the first part of the UPN does not match the account name, this workaround doesn't work - at least, in the testing I've done, it doesn't. If I need to set something in the NPS to get it to work then please advise.

    I'm not sure about your front end/back end setup. Are you saying that the 2008 R2 NPS receives the request from eduroam/local WiFi APs and then proxies that request on to 2003 IAS? If so, I had hoped it would be the other way around as I had started to think that I could use FreeRADIUS as the point that receives all of the authentication requests, handles the reformatting of the addresses and then forwards the local ones on to the 2008 R2 NPS server and everything else on to eduroam.

    Regards

    Philip

    Tuesday, August 23, 2011 4:12 PM
  • I have now got a working solution. It may be that what I've implemented is what was described above, in which case I apologise!

    So the main step is to use UPNs. The UPN suffix needs to match the realm used in the eduroam infrastructure.

    The user logon name (which forms the pre-@ part of the UPN) does not have to match the pre-Windows 2000 user logon name IF you remove the attribute editing piece that traditionally removes the portion from the @-sign onwards.

    So, in other words, a traditional eduroam deployment says that you match (.*)@(.*) and replace it with $1, which is the first component. This needs to be removed from the NPS connection request policy so that the entire entry is passed for authentication. That way, the entire entry is then matched against the UPN and the system can then match it against the user's account.

    You still need to have the connection request policy match .*@<your realm> against the User Name so that the CRP only executes for locally authenticated names.

    Please note that if you still strip the realm off and only pass the first part of the name, this will fail because the inner identity will become domain\username but the outer identity will be the original entry and they won't match. By leaving the realm on, so long as the entire string matches the UPN, the inner and outer identities remain the same.

    This overcomes my initial concern about dotted usernames because I'm now matching the entire UPN and not just the user logon name.

    Wednesday, August 24, 2011 10:57 AM
  • Hi.

     

    I just wanted to drop a note back to this thread to let you know we have been working with some of the senior support escalation engineers to explain the changes from IAS to NPS and why this problem has been induced.

     

    Please keep in mind that RADIUS and hence IAS and NPS are designed to accept authentication for their own domain, or proxy this to another RADIUS box that can accept the authentication if it is a remote domain / realm. Realm stripping is used to present a simplified name to the remote RADIUS box and is not intended to be used for manipulating the domain name, or realm.

    Also note that the changes were made to increase security by preventing Man In the Middle attacks. Therefore it is worth considering the security of any solution you use that does work in this situation, as it MAY be less secure.  

     

    Change in behaviour of realm stripping rules from IAS to NPS.

     

    The behavior with regards to local processing of realm stripping rules has changed between IAS in 2003 and NPS in 2008 in order to support NAP within PEAP. The reason realm stripping rules are available at the Connection Request Policy (CRP) level is to support RADIUS Proxy, to specify that if a connection request realm name matches a specific string, then forward the request to a different RADIUS server, and change the realm name to a different string as appropriate. Here is some documentation on Realm Replacement as related to NPS:

    http://technet.microsoft.com/en-us/library/cc731342(WS.10).aspx   

     

    Realm replacement for PEAP could be done for locally authenticated (not proxied) connections in 2003 IAS because the network authentication was always done at the Network Access Policy level rather than at the CRP, but this was never intended functionality of realm stripping rules. With the introduction of Network Access Protection (NAP) in Server 2008 NPS, the PEAP authentication must be done at the CRP level to support inclusion of the Statement of Health (SoH) in the access request. Further changes in 2008 R2 NPS introduced support for PEAP Identity Privacy, which also requires processing of authentication at the CRP. The changes made to PEAP cause local realm stripping to no longer work, since the identity presented at the CRP does not match the identity seen at the Network Policy level. In 2003 IAS we do not check to verify that the inner and outer identities match. With NPS on 2008, we now check to make sure those match, it was added as a security precaution to prevent man in the middle attacks.

     

    NPS and IAS realm stripping was never intended to be used for local authentication, only for remote such as external users from external domains needing to authenticate.

     

    However, there is a supported workaround.

     

    To accomplish the desired behavior using NPS, either switch to EAP-TLS for authentication, which does not have the concept of an outer and inner identity, or add a UPN suffix to the domain for each additional domain name you need to resolve. This will add an alias to each user and when it checks the account, it will then match since the account has that UPN associated with it.

     

    Tuesday, September 6, 2011 8:24 AM
  • Hi Alphasnooper,

    Firstly I would like to thank you for the information you have provided. But for me and for many more I am guessing worldwide the way in which NPS is implemented on Windows Server 2008 R2 is going to unfortunately force people to move to use Free Radius or to downgrade to Windows Server 2003 (for me I think to have to downgrade to an older version is a workaround maybe but definitely not a solution). "Eduroam (Educational Roaming) is an implementation of an infrastructure which facilitates roaming educational users to gain Internet access at other member sites by authenticating against a server hosted at their own institution". Radius servers are used for this initiative and we have been trying to implement Eduroam using Networ Policy Server (NPS) on Windows Server 2008 R2. For Eduroam the worldwide standard for an end user to connect and get internet access is to enter user@domain.country for the username. The fact that we have two different sub-domains means that even using realm stripping in NPS on a  radius proxy, the inner identity will always be user@domain.country instead of user@subdomain.domain.country. Therefore NPS throws a user credential mismatch error in the NPS logs. I understand why Microsoft have changed the way radius is done. I just can't believe there is no solution within Windows 2008 R2 NPS that will facilitate Eduroam. In some wireless clients there is an option of entering an outer identity along with the username and password and this will work fine if you have the user@subdomain.domian.country for the inner identity and then use the Eduroam standard user@domain.country for the outer/roaming/anonymous identity. So you would think possibly you could get away with this as most of the newer operating systems have the option for the roaming identity (with the exception of windows xp). But just when you think that might work you try test with Window 7 and it turns out the it has a roaming identity but does not allow the use of the "@" symbol and therefore this will not work for Eduroam. If you can possibly come up with a solution that might work can you please post it otherwise we will have to go the alternative route of using FreeRadius. Thanks.

    Friday, April 20, 2012 1:58 PM
  • Hey Alphasnooper,

    Why is it not be possible to manipulate or strip the inner identity once the tunnel has been terminated on the radius server?

    The Authorization provides the compulsory tunneling to the specific endpoint i.e. Radius Server

    Once this tunnel has been terminated, could the inner and outer identity not be matched at this point followed by realm stripping before the authentication takes place?

    This could be an impossible suggestion but I am just trying to understand, why it is done the way it is.

    Thanks

    Friday, April 20, 2012 2:22 PM
  • Hi Lunfly

    I don't know if this will help but I have managed to implement support for eduroam with the Windows Server 2008 R2 NPS.

    The first requirement is that the username that users enter must match the UPN configured for their account. In our environment, we have configured each user's UPN to match their email address, thus making it easier for them to remember. But you can pretty much have whatever structure you want - all that is required is that you have a connection request policy for each different realm/suffix you want to support, and then one more CRP for all requests that are not resolved locally by your servers. Then, you have a single network policy that handles the local authentication requests.

    For the local CRPs, I have configured these so that they match the username to .*@dante.net where dante.net is the domain portion assigned in the UPN within Active Directory Users & Computers. That then authenticates locally. I then have an "eduroam upstream policy" which matches usernames of ".*@.*" and a called station ID of ".+:eduroam$" (which is configured on the wireless access points to add eduroam to the station ID). That CRP is configured to forward the request to my upstream servers (JANET in my case).

    The last piece is the network policy which simply matches the user as a member of the authorised group of users.

    The key to getting this to work really lies with getting the UPN into the desired format. You are not limited to one UPN suffix per domain either. Using ADSI Edit, you can define as many UPN suffixes per OU as you like, thus giving you more flexibility around possible subdomains in use.

    Hope that helps.

    Philip

    Monday, April 23, 2012 2:12 PM
  • Hi.

    Just to confirm I don't work directly for Microsoft support, so cannot answer some of your questions. However, my company was setup by Microsoft to help UK education customers, so we picked this up from a couple of customers who reported the problem.

    We worked directly with the distributed systems team and senior support / WINSE engineers in Microsoft who told us the reasoning behind the change from 2003 to 2008 was becasue they needed to intigrate NAP into the equation and to eliminate the risk of man in the middle attacks. They looked at the eduroam process and came up with the workarounds given.

    NB> This only affects internal authentication when realm stripping is needed. External authentication is not affected and hence the core functionality of eduroam. Internal realm stripping can be addressed by using a UPN suffix internally.

    The statement we were given is below:

    Realm replacement for PEAP could be done for locally authenticated (not proxied) connections in 2003 IAS because the network authentication was always done at the Network Access Policy level rather than at the CRP, but this was never intended functionality of realm stripping rules. With the introduction of Network Access Protection (NAP) in Server 2008 NPS, the PEAP authentication must be done at the CRP level to support inclusion of the Statement of Health (SoH) in the access request. Further changes in 2008 R2 NPS introduced support for PEAP Identity Privacy, which also requires processing of authentication at the CRP. The changes made to PEAP cause local realm stripping to no longer work, since the identity presented at the CRP does not match the identity seen at the Network Policy level. In 2003 IAS we do not check to verify that the inner and outer identities match. With NPS on 2008, we now check to make sure those match, it was added as a security precaution to prevent man in the middle attacks.

    NPS and IAS realm stripping was never intended to be used for local authentication, only for remote such as external users from external domains needing to authenticate.

    Tuesday, April 24, 2012 10:11 AM
  • Thanks Philip, I am thinking the UPN suffix is looking like our only solution. 
    • Edited by lunfly2012 Tuesday, May 15, 2012 2:18 PM
    Tuesday, May 15, 2012 2:16 PM
  • thanks alphasnooper
    Tuesday, May 15, 2012 2:17 PM
  • we moved to freeradius.
    Wednesday, May 16, 2012 9:38 PM
  • we moved to freeradius. that "just works".

    Wednesday, May 16, 2012 9:41 PM
  • Dude THANK YOU this is gold!

    I was struggling integrating NPS with FreeRadius in the eduroam context for days, your post finally helped

    Wednesday, September 2, 2015 10:17 AM
  • I know this is a really old thread, but I just came across it today. 

    I have my 2008R2 NPS server set up and working with eduroam, but I need to specify a different realm name and from this thread I learned that it only works when you forward the request to another radius server. Ok, no problem, I have another 2008R2 NPS server. 

    As long as the forwarded request does NOT match a connection policy on the remote NPS server the attribute changes are made as entered. I see it in the logs. It looks great! I was excited! Once I made a connection policy to match what I needed, the attribute changes are no longer in place and no longer work. WTH? Break the connection policy, poof, attribute changes look like they are supposed to. Fix the connection policy and back to no realm changes.

    I can't just set up a FreeRadius server. I'm setting up a 2012R2 NPS now to see if this realm passing issue is fixed, and I can do that faster (I hope).

    I am just saddened that as long as I don't have a good connection policy on the remote NPS server I see in the logs that my realm changes are there, it is beautiful. I fix the connection policy and the original realm is back in the logs.  I can't see how this is a designed feature/working as designed.

    Edit: Crap. The same behavior exists when you forward the request to a 2012R2 NPS server. What the heck?!? As long as there is a broken connection policy, the logs on the target NPS server has the correct realm changes. As soon as you make the connection policy valid, the logs show no realm changes, they are gone and back to the original realm.

    So that leaves teaching users a different username@x.y to type in to the SSID, or setting up a non-MS radius server, or changing every user's UPN (what else does that break in our daily llives?).

    • Edited by tishward Friday, April 8, 2016 4:13 PM
    Thursday, April 7, 2016 5:15 PM