Server 2016 & Windows 10 Radius login on SSID

cigrosskoes05
Here to help

Server 2016 & Windows 10 Radius login on SSID

We are trying to upgrade our Domain Controllers to Server 2016 from 2008 R2 and are having some issues with Radius.  Server 2008 R2 works fine authenticating Windows 7 & 10 machines.  With Server 2016, it works fine authenticating Windows 7, but Windows 10 machines have been unable to authenticate.  We were looking through event viewer and see no logs for connection attempts from the Windows 10 machines.  Only logs relevant is from the NPS accounting log file which doesn't help highlight the issue for us.  The Meraki logs gives us an EAP error.  

 

Client VPN authentication from Windows 7 & 10 machines also have no trouble authenticating against this server.  Granted, VPN isn't utilizing PEAP like the Wireless authentication is.

 

Has anyone run into anything like this?

27 REPLIES 27
PhilipDAth
Kind of a big deal
Kind of a big deal

Look at a successful authentication for Windows 7.  Now look at a failed one for Windows 10.  Did the Windows 10 one use the same policy?  I'm guessing no.  If not them compared your policy match criteria what what is in the event log entry.

Thanks

 

We just confirmed that they are using the same policy.

So both clients are using the same RADIUS policy.  Does the RADIUS server says it allowed or denied the Windows 10 users?

Adam
Kind of a big deal

Got lots of useful stuff to check from these two documents when we were setting it up.

https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_...

https://documentation.meraki.com/MR/Encryption_and_Authentication/RADIUS%3A_Push_a_PEAP_wireless_pro...

 

If your WIndows 7 computers are authenticating and the WIndows 10 ones aren't then it sounds like you verified the first thing which is to make sure they are using the same policy.  Can double check this with rsop.msc from a command line on one of the computers.  Is your policy using user or computer authentication?  If so do you have the policy assigned to only allow certain groups or OU?  If so, make sure your Windows 10 user/computer are in that group/OU.  If user auth try one of the users you used on a Windows 7 computer and login on the Windows 10 computer.  Also may not be a bad idea to hardwire one of the Windows 10 computers to your network and do a 'gpupdate /force' to make sure it has the latest policy versions. 

 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.

We have been through those documents numerous times.  We've set up new policies using them, and it hasn't helped us.  Directions look like they are for Server 2008 R2 and Windows 7.  It looks like NAP is no longer used with Server 2016.

 

We use both user and computer policy.  We do have the policy assigned to only allow certain groups but we test with a windows 7 and 10 machine right next to use with our own account.  It works with Windows 7, and doesn't work with Windows 10.  We've done numerous gpudpate /force, but maybe I'll take another look at our GPO just to make sure there isn't a setting there that they've done away with in Windows 10.

Looking at my Group Policy settings, the only thing that is different is the Encryptions.  Meraki just has AES, but I have 2 AES options.  AES-CCMP, and AES-GCMP.  CCMP is what it is currently set at.  Does anybody know if Windows 10 or Server 2016 works with both of those protocols?  Grasping at straws at this point.

You shoul be using AES-CCMP.  Meraki does not support AES-GCMP.  Most WiFi NICs also do not support AES-GCMP.

We may not be experts at reading the logs,  but it looks like it accepts the computer, but doesn't accept the user - for Windows 10 machines only.  Windows 7 machines and users authenticate just fine.

What group are you permitting in RADIUS?  I often use the group "Everyone" if I want everything to be able to authenticate.

We use something like All Employees.  Not everyone needs to be able to authenticate.

You need to include both the machines and the users.  Does this group contain both?

 

If not, you could include "Domain Computers".

The User policy has a user only group, and the Computer policy contains domain computers.
cigrosskoes05
Here to help

Anything else we should check for?

Adam
Kind of a big deal

Are you running the Network Policy and Access services from your Domain Controllers or from a standalone server?  Have you considered making a dedicated Radius server to decouple your Network Policy Auth from your AD servers?  That way you can update your DC's to 2016 while you troubleshoot the Auth issue?

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.

We're running them from our Domain Controllers.  We haven't really considered it, we aren't that big so that's why we haven't.  IMO we've troubleshot about all we can.  We're just looking now to see if anybody else has had this problem or can confirm it works with Windows Server 2016 & Windows 10 machines.

 

We will look into having a dedicated Radius server to get us by, but I would still like to figure this out.

MRCUR
Kind of a big deal

You'd probably be better off posting in the TechNet forums - https://social.technet.microsoft.com/Forums/en-US/home

 

MRCUR | CMNO #12
Duke_Nukem
Getting noticed

When we transitioned over to Windows 10 we ran into an issue with Win10 machines not connecting to the hidden SSIDs.  They just wouldn't do it.  We had to broadcast the SSIDs for them to connect.  This was with a IAS setup on 2003 and then NPS on 2012 R2.  We're not on 2016 yet, so I can't help ya there.

Some other things to check:

- I assume you're using a group in AD, and putting machines into that?  Make sure your machine builder is adding them into that group.

- Certificates - in your Network Policy on NPS, Constraints tab, Authentication Methods, PEAP - edit. Make sure your certificate is valid and not expired. 

Active Directory and the groups are fine.

 

I did end up posting on TechNet.  Somebody posting said more research was needed.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/d5828598-2cf3-4293-8424-978f7e59e3d7...

 

Hwy guys - its 2019 already. 🙂 any update on this?

 

Having same issue with server 2016 and Windows 10.

 

- we replicated  our existing NPS which works fine with Windows 7 and 10.

 

As we migrate to server 2016, noticed the same issue - Windows 10 cannot join the network.

 

Hope someone from Meraki can help us on this.

Brons2
Building a reputation

well, I was about to upgrade the local DC to 2016, glad I didn't do it yet.  The other DCs in the organization are on 2016 but the local is on 2012R2.  I don't have any problems with Windows 10 clients on 2012 R2.

Nash
Kind of a big deal

@Brons2 I run NPS on Server 2016 at at least a dozen clients without problems. 

 

What problems are you encountering with Win10?

Brons2
Building a reputation

I don't have any issues, but then again I'm not running 2016 on the local site domain controller.

Nash
Kind of a big deal

I'm going to go out on a ledge and suggest not assuming that Win2016's NPS server is busted based off an old post then. Remember, this was originally posted two years ago. A few things have changed since then in Windows-land.

I still follow this topic.  I ended up installing in on 2012 R2 VMs at that time and haven't tried it on a 2016 or 2019 vm since.

PhilipDAth
Kind of a big deal
Kind of a big deal

>I'm going to go out on a ledge and suggest not assuming that Win2016's NPS server is busted based off an old post then.

 

I have many many clients using NPS on Server 2016 and now Server 2019 authenticating Windows 10 clients with zero issues.

 

This is purely related to local setup issues.

Nash
Kind of a big deal


@PhilipDAth wrote:

>I'm going to go out on a ledge and suggest not assuming that Win2016's NPS server is busted based off an old post then.

 

I have many many clients using NPS on Server 2016 and now Server 2019 authenticating Windows 10 clients with zero issues.

 

This is purely related to local setup issues.


Yup! Every time we've had a problem, it has been due to user error. Usually a sysadmin not registering a certificate correctly...

Dip
Just browsing

I was thinking about this too.. Incorrect certificate.not sure though if from NPS side or client..

 

please correct me if I am wrong..

-- the cert stays on the NPS side locally

- and simply validates if the local machine has them

 

About the local PC.

- working fine when connects to corporate SSID [old NPS]

- I deleted the existing cert.. and imported the new cert provided to me..

 

question:

- do I need to delete the existing cert and manually import the new cert?

 

 

in 2016 NPS I noticed the ff:

In Secure Wireless Connections: constraints/authentication method/ Microsoft : PEAP

BY default we have our corporate wlan cert in there.. it didn't work..

 

When selected,  Windows machine does the ff:

 

  1. Connects to test SSID
  2. Windows will provide option to “Connect automatically”  - this does not work and won’t connect
  3. Another option is to “Use my Windows account” – this also does not work and won’t connect
  • Another option is to manually enter the username and password without the domain name. But still does not work.

so I selected the Windows Azure CRP Certificate Generator certificate.

background: we recently moved our machines to Azure..

 

When selected,  Windows machine does the ff:

 

  1. Connects to test SSID
  2. Windows will provide option to “Connect automatically”  - this does not work and won’t connect
  3. Another option is to “Use my Windows account” – this also does not work and won’t connect

 

  • Another option is  to manually enter the username and password without the domain name.  

This worked and showed an option to Show certificate details.  I checked the certificate and clicked OK. I am able to connect to test SSID. though I am not sure if the thumbprint shown in the cert is the correct one..

 

questions:

- do you guys think this is a cert issue? in my opinion, it could be..

so i will get back to our systems team and verify which one is the correct cert since one worked..

- why do I have to manually enter the username/password?

-does anyone have a documentation for server 2016?

 

many thanks!

 

Dip

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels