Deploy a CA and NPS Certificate Server (For PEAP with WLC)

[David Watkins]

This is a cut and dry installation of all required roles to accomodate utilizing NPS on a Microsoft 2008 R2 server for PEAP authentication of wireless clients from an 802.1x WLAN on any Cisco WLC.  I see numerous requests regarding this configuration but have not seen a top to bottom example.  I hope this helps!

Please feel free to comment if there are any questions, concerns, or corrections regarding this document.  All of the installation steps were followed based on Microsoft TechNet articles (links provided in document) to deploy an NPS server.

[raun.williams]

Wow, very nice. Good job!

[renoufi]

Great step-by-step DIY guide.

What I'd really like to see are some conditional policy examples based on IP, username, group, etc. I've seen the Microsoft regular expression examples but I haven't been able to make them work in the real world.

[ciscobigcat]

I followed this document but this does not work because it does not tell you that you MUST have all your PCs joined to the microsoft domain. If you have laptop or other wireless devices that are not microsoft-based and also that are not joined to the domain, then this does not work.

The moment you try to login to the wifi network with a windows machine that is not joined to the domain, an error comes up. Basically what you need to do is manually export the certificate from the server and then manually install/import it to the client. Once you do this, then you can login but a lot of warnings will come up.

My question is, how do get around this problem?

[Scott Pickles]

I don't believe the web server installation step prior to the CA installation is necessary.  When you install the CA, if there are any dependent roles (such as web server) it will add them automatically.

[Scott Pickles]

Yes, that's correct you do need to perform the import manually.  The whole point to being a member of the domain is to permit this auto-enrollment and alleviate the manual steps that would similarly be required if you were performing EAP-TLS.  If your machines are not part of the domain, you can install the certificate manually as you did, or you can choose not to validate the certificate.  Without validation you are essentially sending credentials unprotected.  Finally, for non-domain machines, your users need to at the very least have a username and password in the appropriate group in AD, either per user or a common account such as a singular guest user.  I don't believe that the doc needs to be amended to specifically state that the end users and their PCs need to be part of a Microsoft domain because if you understand how MS-PEAP is deployed in a Microsoft environment, you already know that.

[Jon Pletcher]

Can you explain at a high level how certificates work in this scenario?  I have this setup and we are implementing a new PKI infrastructure.  I'd like to make sure I get the certs right for the wireless authentication to still work.

Does each client need a cert (auto-enrolled) and the NPS also needs a cert as well from the same PKI?  And they both need the Trusted Root CA saved?

[derict]

Recently i just implemented a wireless running on WLC with NPS & Radius Server. I just want to know, what is the CA certificate for? Is it only between WLC & Server? As i read it should be for end client as well. My question is, how do we enforce that ONLY user in the DOMAIN & have the CERT installed to only connect to the wireless?

My current environment is that without cert, as long as it passed the 802.11x auth, domain user group and running EAP, then they are connected.

Any idea or comment?

[Scott Pickles]

So there are two different trust relationships here that use certificates.

The first is the relationship between the NPS server and AD.  Since the NPS server is going to be asking AD to validate credentials using 802.1x, there needs to be a trust between the NPS server and the AD server.  If you are running NPS on the DC, then you don't need an explicit certificate because they're on the same box.  However, this is not recommended.  It's fine for a lab environment, but typically your NPS server will be one of several and this really depends on the size of your environment.  Like everything else in a Microsoft server environment, you build servers for the job they are intended to do and provide scalability, redundancy and load sharing.  This also eats up licenses, and MS loves that.  The other reason you run NPS on its own box, other than the security recommendation and splitting out functional roles, is just simply performance.  With that being said, in order to authorize the NPS server in AD and ensure trust and security, the NPS box must have its own cert for the NPS role (issued by the CA) and that cert must chain back to the root CA with trust all the way back.  You won't NEED a certificate on the WLC to make this happen, but it never hurts.  The trust between the WLC and NPS is achieved using the agreed upon pre-shared key and by setting up the WLC as a trusted client in the NPS server.

The next relationship is between the NPS server and the clients, and the certificate performs two functions.  First, and most important, the weakness exposed by prior forms of EAP was that passwords were sent in clear text.  So the purpose of the certificate on the NPS is to build the SSL tunnel in phase one through which further EAP challenges are sent in phase two.  The response to the EAP challenge for identity now flows through an encrypted tunnel.  This is the part where you don't need a certificate on every client unlike EAP-TLS.  You can, however, set this certificate up so that it gets to all of your domain members via auto enrollment and you should do this.  Why?  So that you can perform mutual authentication with the NPS server by validating the server certificate.  The clients will be authenticated by NPS and then the clients will challenge the NPS server to ensure you're not sending information to a server performing a MiM (Man-in-the-Middle) attack.

The downside is that PEAP will still work even without auto-enrollment of the certificate and/or without performing mutual authentication.  If your goal is to authenticate domain level, you have two options:

First you can ensure that any user requesting wireless access belongs to a functional group providing wireless access in your AD.  While this is better than nothing, a user with a domain user and password in that group can access the wireless.  You could set this up and take your iPad and get on the wireless.  Two things will happen.  The iPad will complain that it doesn't know or trust the certificate and you click "Yeah ok whatever."  Then enter credentials and presto you're on.  This client clearly isn't part of the domain and isn't performing mutual authentication.  If you really want to lock it down to domain level devices, you perform machine authentication.  You then specify that not only do the credentials have to work and be a part of the domain, but the machine being used also has to be a part of the domain.  The issues you'll encounter here are performing machine authentication prior to user authentication when you logon to a machine.  I want to say that only Vista machines and later will support this and you have to configure the wireless profile and backend appropriately to support pre-logon auth via wireless.

The improvements to some of these issues comes in the form of current products like Cisco's ISE box that can perform posturing.  In other words, it can detect OS for example and kick any device off immediately that is iOS or Android based.  Or you can indicate that a minimum OS level is required (I believe).  The point is that with a more robust back end you can do a whole lot more.  It becomes more complicated as well, but it's do-able.  The folks over at Lab Minutes do a good job with some videos to help you through this.  I recently was going to setup machine authentication in my organization and to really make it effective you have to set a time limit to force users to re-authenticate.  But the struggle I had was how long?  What if someone comes in at 7 versus 9 am?  When will the re-auth take place?  In the end our team decided that our end users would not like having their connections torn down at different times during the day and being forced to reauthenticate.  You could make the time frame something like 12 hours and hope it doesn't happen during the day when they are working, but we didn't want to take the chance that end users would perceive that as 'not working' and dropping off.  We decided to stick with users in security distribution groups in AD, mutual authentication of the certificates, and put up a guest wireless that shunts directly out to the firewall for mobile devices such as iOS and Android.

Hope that helps.

[derict]

Ok, if i understand correctly, there are no way that i can set to only allow machine with certificate to access to the wireless.

In the current environment, both DC & NPS falls under the same box. Yes, currently only machine in the domain can logon to the wireless based on their "machine authentication". However, i think my problem is as per your "The downside is that PEAP will still work even without auto-enrollment of the certificate and/or without performing mutual authentication". So, there are no way that this can be done so that only machine with certificated installed can be authenticated and access the network/wireless? Another problem is the administrator right is not sufficient and i can only use STANDALONE cert instead of enterprise cert in this environment, which means manual cert installation is required in user's PC.

[Scott Pickles]

Yes, if you built the CA as standard instead of enterprise, nothing you can do there except uninstall the role and reinstall it which is a major pain.  You can perform the machine level authentication though to force the requirement that the machine must be part of the domain.  At that point your machine accounts have to be in an approved wireless container in AD as opposed to end user accounts.  You can just approve the whole computers container in AD, but that's not generally recommended.  Let me see if I can find an example of machine auth in NPS.

[Scott Pickles]

Check these out:

https://community.aerohive.com/aerohive/topics/restrict_non_domain_devices_byod_from_authenticating_corporate_ssid

https://kb.meraki.com/knowledge_base/radius-creating-a-policy-in-nps-to-support-peap-mschapv2---machine-authentication

[grochowskir]

Hi David,

This is a great document indeed.

Thank you.

[jwood.ok]

Interested in if anyone is monitoring this still.  I'd be interested to see a similar document to this based on server 2012.  I have been trying to do this based on the following document:  http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/115988-nps-wlc-config-000.html

And have had some confusion about it, particularly the the fact that in that example the server is a DC, DHCP, NPS all in one.  Couple that with the fact that there is a point where you are supposed to request a "Domain Controller" certificate (page 69) and Server 2012 is not wanting to let me do that has left me lacking.  Would love any insight!

[jaf1985]

This was a good article and led me down the right path.  I had an issue with a 3702E AP that was in rommon mode.  This is the order of commands I used to resolve the issue.

AP-in-ROMMON\
ap:
set IP_ADDR 192.168.xxx.yyy
set NETMASK 255.255.255.0
set DEFAULT_ROUTER 192.168.xxx.yyy
tftp_init
ether_init
flash_init

Recovery Wireles LAN Image Download
tar -xtract tftp://nnn.nnn.nnn.nnn/ap3g2-rcvk9w8-tar.153-3.JPJ3a.tar flash:

more set commands
set BOOT flash:ap3g2-rcvk9w8-mx/ap3g2-rcvk9w8-mx
BOOT=flash:ap3g2-rcvk9w8-mx/ap3g2-rcvk9w8-mx

set MANUAL_BOOT no

See all set commands
set
Boot off above files
boot
Shoud boot to the Recovery file loaded. Used the recovery because it was a smaller file and less chance of getting corrupted. When the AP booted up it connected with the WLC and loaded the current file on the WLC and the AP Joined the WLC.

Good article here too:

https://www.cisco.com/c/en/us/support/docs/wireless/aironet-1200-series/99763-reset-lwappconfig-lap.html#anc8