One of the key factor of success during any migration project is to make end user experience as smooth as possible. In a large heterogeneous environment that’s always a challenge. So while working on the Active Directory cross forest migration project, I noticed that post test migrations, user’s pc wouldn’t latch on to wireless network and I would get the “Unable to connect to the network”. A simple restart didn’t fix this issue.
This particular client was using Windows Server 2003 IAS (Internet Authorization Service), yes you read it right windows server 2003, there are quite a no. of small medium business that are still running on Windows Server 2003 which has reached end of its life last year, July 2015.
IAS only authenticate users in local domain, this was the reason why a authentication request coming from a different forest would fail.
One of the tool that has helped me narrow down issue is NPS Log viewer. It nicely parse the IAS logs and present into easy to understand information.
After some research & investigation, we came out with the Action Plan.
On Source Forest/Domain
- Create a Remote Radius Server Group: The wizard is easy to follow.
- Add a New Radius Server Group
- Specify the Remote Radius Server IP
- Specify the Shared Secret
- Ensure that Authentication & Account ports are open between the source & destination Radius server
- Create Connection Access Request Policy: This policy identify the request coming from Access Point and decides weather to forward the request to remote NPS [Network Policy Server, Windows Server 2012 R2] server or authenticate locally. I used the username attribute to identify the domain part of domainusername of request coming from Target forest. Once the policy is created, go to the policy properties > Edit Profile > Authentication and check forward authentication request to Remote Radius Group
That’s about it in Source Forest/Domain
On Target Forest/Domain
- Create a Radius Client: You would create a new radius client and specify the IP of Source Domain Radius IP, specify the shared secret that was set in source domain Remote Radius Server Group.
- Create Connection Request Policy: Create a connection request policy and ensure that you select Authenticate locally.
- Create Network Access Policy : Create a Network Access Policy that will grant accept incoming request to the network. You may few variable here
- Under Conditions, you can select users to be a member of certain group to who can connect to the network.
- Under Constraints > Authentication we used PEAP & EAP-MSCHAP-V2 authentication protocol. Remember, you would need to setup internal PKI or you can go with trusted 3rd party Client-Server authentication certificate for clients to connect successfully
That’s about it. Once this was setup, I could now connect to the Secure Wi – Fi network during transition face. Eventually, the Server 2003 IAS would be phased out and only Server 2012 R2 NPS will be used in conjunction with Cisco AP.
Now you can see the successful Access-Accept and Access-Request on the Source NPS logs after getting successfully authenticated by Target NPS.
Hope this helps!