Sheridan Posted July 25, 2016 Posted July 25, 2016 We've just installed some new wireless kit to replace some old stuff, we're using the same NPS server for Radius and deploying our root CA via group policy. The NPS Server has a certificated from our CA which is valid and in date. However, our wireless Windows 7 clients won't connect anymore - they come up with the error: "The server presented a valid certificate issued by , but is not configured as a valid trust anchor for this profile." If you load up the certificates on the clients, you can see our CA is a Trusted Root CA in the list, so I'm a bit stumped as what its complaining about?
Guest obsidianpillar Posted July 25, 2016 Posted July 25, 2016 Not sure what it's complaining about. To stop it, I think it's just a case of unchecking "Validate Server Certificate" in the GPO that's applying the Wireless Profile.
Sheridan Posted July 25, 2016 Author Posted July 25, 2016 Not sure what it's complaining about. To stop it, I think it's just a case of unchecking "Validate Server Certificate" in the GPO that's applying the Wireless Profile. That's the odd thing, it's always been unchecked! It's only started complaining since we applied this policy to our new wireless system, which is the same as the old just using different APs.
Guest obsidianpillar Posted July 25, 2016 Posted July 25, 2016 Which "new kit" have you got? Have you tried removing and re-linking the GPO to the clients after a restart to see if it makes a difference? I take it it's the same SSID, Shared Secret etc?
Sheridan Posted July 25, 2016 Author Posted July 25, 2016 We've move from old ruckus kit to new xirrus and basically deployed a new ssid with the exact same security settings as the old ssid (we basically created a new ssid for clarity that we were using the new kit!) The old ssid and new connect to nps on server 2012 which again hasn't been changed. The GPO is a new GPO for this ssid, the old gpos have been removed. Oddly it will connect on Windows 10 and IOS with no warnings, but the Windows 7 won't connect without a warning, and that means the network isn't available on boot, rendering a load of laptops useless. I can't see it being a problem with the xirrus as that is simply pointing to the same NPs server as our old ruckus system did, and other clients seem OK and don't complain about the certificates. Very bizarre.
Guest obsidianpillar Posted July 25, 2016 Posted July 25, 2016 Connect them via Ethernet, give them a reboot after startup. Use the policy "Always wait for the network...." and link it to the Laptop's OU and wait for it to pick up the new GPO? Alternatively, could you grab one of the laptops, manually create a network profile and test that it works, then go to the command line and export the profile the old way (nets wlan show profiles ... export profile etc) save it to a network location and then call it using a batch script at startup?
Sheridan Posted July 25, 2016 Author Posted July 25, 2016 I'm going to try and create the profile manually tomorrow and see what happens. Whatever it means I've got to go around every laptop to fix them now [emoji15]
Guest obsidianpillar Posted July 25, 2016 Posted July 25, 2016 Do you have SSCM? If they all have an Ethernet connection available it may be easier to re-image them, adding the script to a package and then deploying it, or even as a scheduled task to add the profile?
Sheridan Posted July 25, 2016 Author Posted July 25, 2016 No sccm here, it's frustrating as the new ssid is identical to the previous one except in name! I'm tempted to redeploy the old one to see what happens!
Guest obsidianpillar Posted July 25, 2016 Posted July 25, 2016 You could easily do it with MDT, just adding it as an Application. The only reason I referenced SSCM is because you could send a WOL packet to make the deployment less hands on. It'd be interesting to see what happens when you add the other system back.
Sheridan Posted July 25, 2016 Author Posted July 25, 2016 I'm a bit baffled as to why the Windows 10 and IOS devices seem happy to connect - they have the same certificates (ie the one given to the NPS server by the CA, and the root CA) and they work fine! I'm not sure where this is going wrong, the new part of this is the Xirrus part, but the 802.1x setup in there is simple and appears to work with other devices. Annoyingly the Windows 7 clients declare the CA is not a trusted anchor, yet it shows up on the Certificates MMC as a Trusted Root Authority, so that's conflicting information - especially as I've set the wireless policy to not check the server certificate.
Martijn2345 Posted July 26, 2016 Posted July 26, 2016 You're not the only one. We've had exactly this issue show up at two customers yesterday, both also using Windows 7 client and we have not made any changes at all. In one case, the wireless profile is pushed with a GPO. In the other case, it's a guest network that's not pre-configured. We fixed the GPO by selecting the appropriate Root CA under PEAP settings. The strange thing is there were previously no Root CA's selected and the GPO had not been changed since september. We're still looking into what has changed last weekend that triggered the error to start popping up. Possibilities we're looking into are windows updates for Windows 7, windows updates for the Windows NPS server (also DC) and possibly a certificate used (signed by AddTrust). One other coincidence is the NPS/DC auto-enrolled for a new certificate last weekend.
Sheridan Posted July 26, 2016 Author Posted July 26, 2016 Well this gets weirder. I restarted the NPS from home last night and when I tested a couple of laptops this morning they now connect to the new SSID without complaint - using the GPO that I was using yesterday. The restart must be a coincidence, as the W10/Ios clients were working on the new SSID without problems yesterday. I'll have to try a few more and see if it carries on working!
lostsoul Posted July 26, 2016 Posted July 26, 2016 We had something similar after installing a new certificate on our NPS box. Everything looked good, but some clients were logging that error. To fix it I had to remove the old cert from the NPS box, even though it was not in use it was causing the issue. I remember finding a Microsoft KB article about it, turned out it was a know bug.
Guest obsidianpillar Posted July 26, 2016 Posted July 26, 2016 Well this gets weirder. I restarted the NPS from home last night and when I tested a couple of laptops this morning they now connect to the new SSID without complaint - using the GPO that I was using yesterday. The restart must be a coincidence, as the W10/Ios clients were working on the new SSID without problems yesterday. I'll have to try a few more and see if it carries on working! Glad you got it working.
Sheridan Posted July 26, 2016 Author Posted July 26, 2016 Glad you got it working. Not sure what I did though! [emoji3]
Guest obsidianpillar Posted July 26, 2016 Posted July 26, 2016 Not sure what I did though! [emoji3] Behold the common phrase of technicians, system administrators, analysts and everything in between! "I don't know what I did though"
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now