802.1x authentication with heterogenous clients

  • 3
  • Question
  • Updated 3 years ago
  • Answered
I have set up an SSID using WPA2-802.1x authentication. I'm using Microsoft NPS as the Radius server. We have a mix of clients including Mac, iOS, Android and various versions of Windows. I am struggling with different client behaviors with respect to the certificate presented by the the Radius server.

Mac clients allow you to install the Radius server's certificate in your keychain, and you're good to go. Windows will not join the network without unchecking the "validate server certificate" option which is buried several submenus down.

I know that the Microsoft way would be to install their CA service and generate a root CA which is disseminated to the domain members via Microsoft magic. However, I can't assume that my clients will be domain members, nor that they will be using the Microsoft wireless client.

Is there a platform agnostic way of installing a server certificate that will work with all clients? I would be happy to purchase a commercial cert if I knew it would work for all (or almost all) potential clients?
Photo of Daniel Oxenhandler

Daniel Oxenhandler

  • 8 Posts
  • 0 Reply Likes
  • frustrated

Posted 5 years ago

  • 3
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
For your use case, purchase one or more commercial certificates and trust the root that they derive from. (Remember to then contain the trust that flows in clients to the CNs of your certificates.)

Don't use a self signed certificate and worry about how you're going to distribute it to clients.
Photo of Daniel Oxenhandler

Daniel Oxenhandler

  • 8 Posts
  • 0 Reply Likes
Nick,
Thanks for your response. Could you elaborate on this any?

  • Should the CN of the cert match the hostname of the Radius server?

  • Will the Microsoft clients still need manual configuration to trust the root cert, even for a commercial cert?

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
You can use a CN of your choosing as long as it is is a domain name that you control, or under a domain name that you control. The host name / domain name of the RADIUS server isn't relevant or involved.

For a Microsoft client, you will need to enable certificate validation and tick the check box next to the appropriate root. Also remember to constrain to your certificate(s) CN(s).

For Windows XP clients, you may need to install the root certificates update package if the root is not available. (For this reason, it is often worth choosing a CA where the root is always trusted if possible.)

http://www.microsoft.com/en-gb/downlo...

(Also available through Windows Update as an optional update.)

For later Windows clients, the root certificate update process is automatic.

Third party tools exist to assist with the supplicant configuration process if you think it is too involved, but I won't mention them here.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes

Nick, I am definitely not disagreeing with you.  It took me several weeks to get all this going with the NPS server and, after going through all of this, it is very obvious that:

  • NPS is a "lite" RADIUS server and should only be used for basic configurations.  It appears to get "confused" when multiple EAP types are deployed.
  • A huge amount of time could have been saved by deployed a "fully featured" RADIUS server/appliance, which would not have experienced these issues. 
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Really sorry, I wrote those responses while rather under the influence of red wine. Sorry if they came over as being too terse and perhaps verging on unfriendly! :( Apologies!

FreeRADIUS and Radiator are certainly far better RADIUS servers for larger, more complex deployments. I don't have any experience with the other offerings.
(Edited)
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
Not a problem mate.  Hopefully the conversation will help some people who are having issues with 802.1X authentication using a Microsoft NPS server.
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
I'm still confused tho as all of these comments above manipulate the group policy / wireless policy to get the clients working.. (If I understand correctly) With BYOD you have no control over them with group policy so unless you manually setting up wireless profile security settings on all devices the whole connection process might not be as seamless as it sounds..

Apple devices I notice connect with a warning when I enabled domain users authentication (after their user name and password was typed in.. I got it working on all laptops but as I say the security warning error was something I didn't want employees to see -- You know how they panic. The wireless policy sorted this out as well as to authenticate using computer authentication (as I only had allow domain computers to connect) 

It seems even tho they were working on a domain computer the policy wouldn't let them connect as user authentication was still probably being used by default.. When I changed the wireless policy to use computer authentication it worked, Obviously all laptops had to then have a lan cable plugged in and gpupdate command run for them to get the wireless profile. After that all was good..  

So no laptop which is not a domain computer can connect in our environment and all wireless access points have a GUEST wifi SSID which puts them on a private VLAN where they just get internet. (VLAN taggin etc on all AP and switches.

Works to keep our network that more secure. I would have loved to get this working without a wireless GPO policy but this just wasn't the case for me. 
Photo of Shaun van Tonder

Shaun van Tonder

  • 2 Posts
  • 0 Reply Likes
Hi Guys.

I just wanted to respond in case I can help others with the same issue.

I have sorted out the Trust Anchor issue displayed on Windows & clients when connecting to Windows NPS Server (Server 2008r2) using Wireless WPA Enterprise.

I bought a 3rd  Party Certificate from Geotrust as we didnt want the admin headache of having a Local CA in house. (In case of upgrades or failure)

I am not using group policy to configure my wireless clients.

The wireless GPO does take the message away but once again we have 6 AD sites and configuration of all the Access points etc is a pain so I didn't want to use the Wireless GPO setting.

I imported the Geotrust Global CA cert into the NTAuth store on the domain controller and made sure it was replicating to the laptop, but still no joy.

After a month of messing around at home on a duplicate setup I finally found my issue. I opened my certificate and I notice the following as attached.

The certificate chain had 3 links. The last link being my CN server name then Geotrust DV SSL CA G4 then finally the Geotrust Global CA.

Once I also imported the Geotrust DV SSL CA G4 certificate to the NT Auth store and allowed replication its now working 100 percent.

I hope this helps anyone in the same situation. As mentioned I am only using NPS server with the 3rd Party Cert in the PEAP policy. I have the Access Point listed in the clients section and configured as WPA - Enterprise with the IP address of the NPS server.

All works 100 percent and all domain computers connect without the Warning.

Cheers

Shaun 
Photo of Daniel Oxenhandler

Daniel Oxenhandler

  • 8 Posts
  • 0 Reply Likes
Thanks, Nick. You've been very helpful.

I will play around with this, but it sounds like someone (me/the user) will have to go into the properties dialogue and check the correct root cert to make this work on Windows, even with a cert from a known provider. I was hoping for something less complicated, like on the Mac.

Cheers,
Daniel
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
On a Mac, for 10.7 and later, you still need to install an appropriately configured MobileConfig to do 802.1X correctly/securely.

In 10.6, the process and configuration is no better than for WIndows.

In 10.5 and earlier, 802.1X authentication is always performed in an insecure manner as it is not possible to configure the trusted root and CNs via the user interface.

Good luck! :)
Photo of steven

steven

  • 32 Posts
  • 2 Reply Likes
Hi,

As far as I know, the CN should reflect the FQDN of your NPS server. Therefore I hope your domain doesn't end with .local, .internal or an equivalent of this. Reason being the public CA's don't issue certificates for these domains.

Please note the NPS does have some requirements for the server cert. Consult your certificate issuer for the details.

Windows by default trust all certificates issued by the CA's listed in the configuration of your wireless network. You don't need to mark the public CA.

Steven
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Steven,

That's not the case. The FQDN of a server running a RADIUS service has no involvement in the 802.1X process with a TLS-based EAP such as PEAP. As such, you're free to choose what certificate you wish to present.

From a consistency perspective, it can be argued that they should match but there is no conceptual requirement for this.

You're quite correct that it does have to be a CN that a commercial CA will issue.

Nick
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
Nick

We have a .local domain and need an officially signed certificate for our NPS.

Are you saying that the certificate I can choose under PEAP properties (in NPS) can be a real certificate which is signed by an offical CA (e.g. wlan.myofficaldomain.com)?

Will the clients accept this? I am asking because I did some tests withmy .local domain and they failed. I issued a different certificate wlan.mydomain.local und told the NPS to use this. My Windows 7 clients were unable to connect to the NPS then. Switching back to the domain controller cert (NPS is installed on a DC) made it working again.

So does your suggestion work or not ?

BTW, This was on a Windows 2008 R2 Domain with NPS 2008 R2

Regards,
Oliver
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yup, works perfectly...

You're obviously got a gremlin somewhere that you need to work out. Did you check the supplicant configuration on the client you were testing with?

The domain is decoupled from the actual certificate that you present in the PEAP process, it is completely unrelated.

You are therefore able to use a certificate that is from a public CA without any issues.

The clients do all accept this. This is done in many deployments today.

(They should obviously be configured to constrain to both the CA's root and the CN of your certificate to ensure they are not MITM vulnerable.)

I have NPS deployed today with certificates from Thawte.

Nick
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
Hi Nick

My situation is as follows (or my customer ones). He has a Windows 2008 (not R2) domain ending in "domain.ads". The NPS is installed on a Domain Controller itself. On a second Domain Controller there is Microsoft Certificate Services installed (Enterprise). So the MS CS automatically deploy Certificates to the Domain Controllers (as well to the DC with NPS installed).

So at the moment when clients connect they get the DC1.domain.ads certificate presented which for sure is untrusted for all non-domain devices such as smartphones or BYOD notebooks. Therefore these users must install the CA Certificate first which for many of them is too complicated to achieve.

So what you say, is I can get a "real" certificate wlan.domain.ch (my customer is in Switzerland and owns the domain domain.ch / domain is a fake name not the real one :-) ) and select this one for PEAP.

The certificate process is totally decoupled from the Domain Controller and it's certificate it uses to communicate LDAPS (which uses the DCs FQDN) as an example?

One thing I didn't understand correctly is

>> (They should obviously be configured to constrain to both the CA's root and the >> CN of your certificate to ensure they are not MITM vulnerable.)

Must the Clients (e.g. Smartphones, BYOD) be configured specially for this to work ? That would not be good as those people are no IT-Geeks.

I mean if the public certificate is signed by a major CA which is part of Windows, Smartphones, etc. and the CN would be wlan.domain.ch this would be fine?

Sorry for asking some questions again but if this works it is a simple and straight forward solution. I just want to understand it.

Regards,
Oliver
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It depends on the use case:

1) If you define working as just getting a connection that is usable, you do not need special supplicant configuration for it to 'just work'.

If you, however, define working as getting a connection that is both usable and secure, all clients must have their supplicant configured.

The reason that you always need special configuration for a secure deployment is that:

a) There is nothing to check the certificate against, it's not done against the SSID, so you have to specify the names yourself.

b) Nothing stops a certificate being generated from an arbitrary root that anybody could create unless you constrain to the expected one.

Major CAs are not magically exempted from this. (Effectively, it's a design flaw in supplicants and EAPs that we commonly use today, such as EAP-TLS, EAP-TTLS and EAP-PEAP.)

This is going to be the case until we see HotSpot 2.0 widely supported both on APs and clients.

Things like CloudPath's XpressConnect exist for this reason to assist in the on-boarding process.
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
Hi Nick

Thank you for your explanations

But now I am totally confused...

What does this mean:

>> If you define working as getting a connection that is usable in a secure manner, all clients must have their supplicant configured.

Let me explain:

Our customer has a Wireless network based on CISCO APs and a Cisco WLAN Controller. The WLAN Controller is configured to use the NPS 2008 for Radius authentication. The whole thing is configured to use 802.1X.

So when users connect (Windows 7, Smartphones / non-domain members) they must enter their Active Directory Username/Password and the NPS compares this against a special Windows Security Group membership. If successful NPS returns a speceial CISCO AV-Pair with the correct VLAN configuation to the WLAN Controller who then switches the wireless client into this VLAN. From this point a normal DHCP Discover is started and the client gets its IP address and can access the network.

So we do not use the certificates for client authentication it is just used for the authentication phase with the NPS (at least this is my understanding).

I assume that the later communication (user accessing resources) is not secured (except he uses SSL).

Sorry for being so complicate but this whole Wireless-Client, WLAN-Controller, NPS communication chain is book with seven seals for me :-(

So is this now the easy case where it 'just works' ?

Regards,
Oliver
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2438 Posts
  • 445 Reply Likes
There is no easy way where it just works with 802.1X today in a secure manner. It simply cannot be done.

This is, mostly, the reason why products like XpressConnect exist to help out. To be secure, the supplicant on the client has to be configured, always, in ever case. It cannot be avoided. Without configuration, there is no trust anchor (acceptable roots) nor is there constraints on the trust that flows from that anchor (acceptable names) so there is a MITM vulnerability vector.

A commercial certificate cannot somehow magically help you out here.

(If security is not so important, however, you can forgo this step and you can get away without client supplicant configuration at the risk of that MITM vulnerability.)
Photo of Crowdie

Crowdie, Champ

  • 917 Posts
  • 262 Reply Likes
Oliver, which EAP type is your customer utilising with their 802.1X configuration? (EAP-TLS, EAP-PEAP MSCHAPv2, EAP-FAST, etc.)

If you are not sure what any of these are I strongly recommend you get the excellent CWSP Study Guide (Coleman/Westcott/Harkins/Jackman) and go through chapter 4 - Enterprise 802.11 Layer Two Authentication Methods. The CWSP Study Guide is one of my most used textbooks.
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
At the moment the users select the correct SSID and a username/password prompt appears. They just enter their credentials and are connected (if the Root CA Cert from the internal CA is installed on the clients).

That is the problem. Lot's of people cannot handle the installation of the CA Certificate. And if it is not installed they either get a warning (to accept the unsecure Cert or simply get not conected (depnds on OS)). Configuring the SSID-Profile manually and disabling the CA Cert Check is a no go as well.

So my simple question is. If using an officially signed Certificate wlan.domain.ch (where the CA Certificate is already in the Windows Cert Store) will those clients automatically connect without any warnings (still asking for credentials) ?

Regards,
Oliver
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
This sounds like a EAP-PEAP MSCHAPv2 configuration. The RADIUS server has a certificate installed and this is used to create a tunnel for the supplicant to pass the computer and/or user credentials. The wireless client needs the root CA certificate installed otherwise it will not trust the certificate on the RADIUS server and a "client rejected the certificate" error will be generated.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
They will usually connect without warnings where the root is one that they already trust.
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
Exactly : EAP-PEAP MSCHAPv2

So the answer to my question is yes.

It will work if the Radius (NPS) Certifcate (selected under PEAP Properties) is signed from an official CA which is present in the client certificate store.

Correct?

Regards,
Oliver
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
They will get a prompt about the certificate to confirm that they accept it for security reasons, they just won't have to import the root to be able to anchor trust. It is not a warning though. Perhaps that's splitting hairs.
Photo of Daniel Oxenhandler

Daniel Oxenhandler

  • 8 Posts
  • 0 Reply Likes
Oliver,
In my experience with this scenario, the Windows clients will NOT connect without client configuration, even if the cert is from a trusted CA. I installed a GoDaddy cert on my NPS, which is in the default MS store. However, you have to go several levels into the EAP config on XP and Win 7 and tick some check boxes for the appropriate CA (or disable cert checking, which kind of defeats the purpose) for the client to connect. Unless the clients are domain members, and you can push out group policies, there is no way to make this transparent to the clients.

I wrote some scripts to automate this, which mostly worked, but you still get into scenarios where the laptop has Dell or Intel specific wireless driver that breaks the script. Fortunately I have a pretty small office, and most are on Mac, but this approach does not scale, as they say.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
Daniel, you are correct that a Windows based supplicant will not connect to a PEAP MSCHAPv2 SSID without the Windows based supplicant being pre-configured. For domain devices this is an easy process using Group Policy. However, if you are looking for a BYOD solution PEAP MSCHAPv2 is not suitable for Windows based supplicants.

iOS devices will prompt upon initial association and allow the user to "trust" a certificate that isn't trusted by the iOS devices. This is a poor design by Apple as it makes iOS devices vulnerable to man-in-the-middle attacks.
Photo of Oliver Rehmann

Oliver Rehmann

  • 6 Posts
  • 0 Reply Likes
What does this mean ?

Do I have to tell my customer that therre will be no easy way for BYOD devices to connect to his WLAN which is configured to use PEAP- MSCHAPv2. I mean the internal clients (domain members) are fine but my customer is a school where students bring their own notebooks and smartphones.

Maybe I should give it a try. What are the requirements for an official certificate used by NPS? Can it be simply generated by the IIS Wizard or does it need some special extensions activated?

A certreq.exe command sample would be great.

Regards,
Oliver
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It means that you have to use an assisted on-boarding process via a solution such as CloudPath's XpressConnect if you want to ensure correct, secure configuration of the client and for them to be able to connect without warnings or prompts.
Photo of Brian Freed

Brian Freed

  • 2 Posts
  • 1 Reply Like
I'm glad this thread came back to life, I am working on a very similar situation.

Reading Nicks comments about using a 3rd party cert convinced me that is the way to go.

We have offices all around the world with local AD servers to support the users.

Instead of sending the authentication traffic across the WAN to a central Radius server, we wanted to keep it local.

I am using the internal Radius server of the Aerohive AP's and it's working out great.

We have clients of all kinds connecting, and yes each one has its own little idiosyncrasy but they do all work.

I've installed a 3rd party RapidSSL cert on each AP that acts as the Radius server for the site.

It uses the local AD server for its AAA user Directory setup, and is joined to the domain.

The trickiest part was working out exactly how to properly combine the CA cert with the RapidSSL intermediate (chain) cert.

Working with the clever guys there at Aerohive (thanks Dalan!) I was able to get it working, through proof of concept testing and into pilot.

Right now we have several sites up and running in this configuration with no issues at all with various devices connecting.

Fortunately we never have to monkey around with that "Verify Server Certificate" checkbox in Windows ever again!

Here are the details on what to expect from each client if you set it up this way.

When I say roaming, I mean from one country to another (not building to building)

Windows 7 clients - Pops up a somewhat scary security alert message, to either Terminate or Connect.

When you connect, it checks the GeoTrust Global CA cert and you never see this prompt again, even roaming between sites.

Apple iOS - Pops us a nice alert showing the cert name and asks you to Accept it. You can teach your users what name format to look for.

Once per site when roaming, since each site has a different cert it seems to want to check the path to GeoTrust Global CA each time)

Androids - These are the worst in one way, and easiest in another. The initial screen users see has a lot of config jargon.

But all they need to really do is enter their AD login name and password. Android never prompts to accept the cert. It just auto-accepts it.

If you use the embedded Radius server in the AP and a 3rd party cert, this is generally what you can expect. Your mileage may vary...

BTW - I was told by GeoTrust support that the reason the prompting happens is that Radius doesn't know about chain certs so you must accept it, on some devices.

This is working out well for us so far. For the cost of a cheap cert it should save a lot of frustration for our users.

Looking forward to hearing what other people are doing with their 802.1x implementations!

Brian
Photo of Amanda

Amanda

  • 396 Posts
  • 25 Reply Likes
This is a great conversation that's continued, but slightly from, the main topic, so I created a new topic to continue the discussion. Please reference the new topic here: What are other people are doing with their 802.1x implementations?
Photo of Greg White

Greg White

  • 1 Post
  • 0 Reply Likes
I'd really like to hear more about the solution Brian mentioned.  I'm very curious about the details regarding his quote below.

"The trickiest part was working out exactly how to properly combine the CA cert with the RapidSSL intermediate (chain) cert."

Does anybody know how he got that working?
I'm not concerned with MITM attacks, just looking to control access to an internet only network without using PSK or a Splash page.
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
I have had so much issues with this I just cant work it out..

I have even purchased a cert from Geocert and installed it on the NPS server.

No luck :(

Message as follows:

The server "fbcofp02.falsebay.org.za" presented a valid certificate issued by "GeoTrust Global CA", but "GeoTrust Global CA" is not configured as a valid trust anchor for this profile.

I am open to any tips

Cheers

Shaun
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2438 Posts
  • 445 Reply Likes
If it is a domain joined machine, have you added the root to the NTAuth store on a domain controller?

http://support.microsoft.com/kb/295663
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Hi no I havent.

Do I add the .crt file to the NTAuth stors on the domain contoller only.. ?

And just one domain controller will be fine ?

Do the NTAuth stores replicate ?

Thanks so much

Shaun
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2438 Posts
  • 445 Reply Likes
Hi,

Yes you do and just on one domain controller, it will replicate to all members of the domain.

Nick
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Thanks Nick.

Sorry I'm really new to this... When you refer to the root is it the .pfx file i recieved from the 3rd party CA ?

I have also exported a crt file by right cliicking on the imported .pfx file in the Trusted Route Authorities store.

I was under the impression that I would import the .pfx file into Tusted route cert authorities and export that file ro a .crt file. After this deploy via group policy to the clients trusted route Auth store or even manually double click on it on the windows 7 machine and install it in the trusted Route Authorities...

But I have done all that and no luck..

Any solution will do now as I'm really over it :)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
By root I mean the base certificate that yours derives from - the one that is the trust anchor so to speak.

https://www.geotrust.com/resources/root-certificates/
 
Yours appears to be Root 2 - GeoTrust Global CA from the above URL. You need to import that to the NTAuth store so that the certificate you have purchased can be used for 802.1X authentication purposes with domain joined machines.

The pfx that you have is a container file format, it likely contains the root, your certificate and any necessary intermediaries.

I think you have been given bad advice as you definitely shouldn't have to touch any other certificate stores when using a commercial certificate, certainly not on a per-machine basis!

You also definitely want to ensure that you haven't and don't accidentally deploy the server certificate to clients - especially its private key!
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Thanks so much Nick...

I have a better understanding now of what needs to be done.

So does this mean that because Root 2 - GeoTrust Global CA is not on the trusted CA store on Windows 7 we are getting the pop up message ?

I appreciate your feedback..

Thanks so much.

Shaun
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Windows 7 should be automatically maintaining its root certificate store with the set that Microsoft publish. I highly doubt that GeoTrust Global CA will be missing unless you have purposefully gone out of your way to remove it and/or break that process.

The issue here is the special case that for domain joined machines, you need to ensure that the NTAuth store contains also contains this root for it to work with 802.1X.

You also need to ensure that in the 802.1X profile that you are deploying that you have selected to trust certificates that derive from GeoTrust Global CA and specified the CN that the certificate was issued for as the acceptable server name. I am assuming that you have already done this?
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Sorry I meant that the NTAuth store on Windows 7 machines doesnt contain Root 2 - GeoTrust Global CA ??
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Yeah sorry was me being stupid...

It apparently wanted the .cer extension on the end of the filename...

I will try the Wireless connection again and hope to have success..

Thanks again Nick..

Really appreciated,

Shaun
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2438 Posts
  • 445 Reply Likes
Have you configured the wireless connection profile to constrain to the root and specified the server name (the CN which will be one of the SANs in your certificate)?
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
No I havent... Do you also need to deploy a wireless profile to the clients with the validate server certificate option as well as trust these servers ?

I was hoping I didnt have to deploy wireless profiles on machines..

I take it this is just to make sure they dont connect to any rogue servers posing as the NPS Server...



Shaun
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2438 Posts
  • 445 Reply Likes
It is really, really easy to do via group policy so it is no big deal - if you don't have correctly configured profiles on end machines you'll end up with a security vulnerable deployment to rogue servers and may still see popups (I am not clear on this point) - you ought to actually validate the certificate is from the expected root and has the server name that you are expecting... :P
(Edited)
Photo of Shaun Van Tonder

Shaun Van Tonder

  • 17 Posts
  • 0 Reply Likes
Yes true it is but we have 5 different sites with lots of access points on each site, so it could beome a bit messy :)