Certificate deployment question for 802.1x wireless radius deployment for EAP-TLS

We are planning to deploy 802.1x wireless radius to our access points and have a couple questions regarding certificate deployment. We chose to require certificates (TLS) vs passwords (MS-CHAP v2).

Currently we aren't deploying certificates to the domain, but we do have an enterprise Certificate Authority infrastructure in place for this purpose and potential purposes(2008 R2).

The purpose and needs for the certificate template I am seeking to create are just going to be used for client authentication for 802.1x. We will also need to deploy/install certificates for our mac users and potentially mobile devices.  

During testing, I duplicated the default 'user' certificate template in our domain seems to be sufficient for our needs, but I fear this template may be opening some security risks in the future, which I would appreciate someones opinion on. I also noticed by default, the private key is exportable, is this a concern? If so, what?

Any opinions for such a scenario and deployment are appreciated, thank you!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Randy DownsOWNERCommented:
Here is an interesting article on the subject.

If you're ok with and understanding of the overhead of managing client certificates, implement EAP-TLS as it is not vulnerable to these types of attacks.
Install a certificate signed by an internal CA that is trusted by all wireless users on the RADIUS server.
Avoid using RADIUS certificates signed by public CAs.
Enforce validation of RADIUS certificates and manually select the internal CA to be trusted. Do this centrally, via tools like Active Directory Wireless Group Policies if possible. Ensure help-desk personnel and users are not capable of modifying this configuration since it has a way of becoming disabled when people are troubleshooting wireless issues.
As always, ensure that a strong password complexity policy is uniformly applied to all users, with no exceptions.
Jakob DigranesSenior ConsultantCommented:
For security concerns, EAP-TLS (within PEAP session) is by far the most secure solution for (wireless) authentication.
MsChap V2 is in fact broken, however - this is no concern when exchanging this within a PEAP session.
EAP-TLS is not broken.
As mentioned in the article, this needs to be assured:
- Use Radius with a internal certificate.
- use authentication mechanism of PEAP as EAP method. With PEAP the client PC (supplicant) will create a symmetric encryption key, use radius serves public key to decrypt this and exchange this with radius server - and all other communications between that particular station and radius server are encrypted with this symmectric key
- supplicant should validate server certificate, and thus making sure that the radius server is the correct one, and that the certificate for the radius server is signed by a trusted ROOT ca
- within that secured tunnel, when choosing EAP-TLS as inner method a preferably unique certificate will be used for authenticating client

When it comes to certificates, there's a couple of  things to consider.
You can use User template, but whne duplicating this, choose Win2008 server.
Do not allow for exporting private key (!) - you really don't want that.
as default, certificates uses 2048 bit key - not broken by far yet

Enrolling certificates is chosen based on security permissions on template - autoenroll permission. I'd recommend using a dedicated wireless user group for this, and also using the same group for granting access in RADIUS server
Enable auto enrollment through GPO. And - if you intend ONLY to use these certificates for wireless authentication, do not enable credential roaming, but if these will be used for signing and encryption - you MUST enable credential roaming.
In brief - credential roaming enabled make sure that a users certificate are copied to user object in AD and the same certificate are enrolled to all domain joined PCs/TS Desktops that the user logs on to, which is essential if certificate is used for S/Mime in email, or file encryption. For auth only, this is not essential, but it allows for easier management of certifcates

For enrolling to MAC/BYOD devices, you'd need some kind of either 3rd party software, of (rather complicated) setup using Microsoft Simple Certificate Enrollment Protocol (https://www.microsoft.com/en-us/download/details.aspx?id=1607)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
Some consideration

First, having certificate is definitely a stronger EAP types and fare better protection against brute-force attacks, dictionary attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP, version 1). So going for TLS cert is good.

Second, enroll certificates only to the computers and users to whom you want to grant network access through RADIUS clients. You do not have to autoenroll certificates to all members of the Domain Users and Domain Computers groups. Use of smart cards for client user is preferred (and not constraint by specific machine) though there are additional cost for h/w (card/reader), the private key stays in the card (not exportable).

Third, exposure of client cert private key being exportable should be best avoided if you are using EAP-TLS or PEAP-TLS without smart cards. Do have autoenroll client or computer certificates to domain member client computers. In a way, I see this is to avoid manually via cert web req (not avail in Win2012 R2) by login into other domain machine and as having to go for "Mark keys as exportable: Selected". This can increase exposure since you still need to "transport" the pfx to install in the machine.  

802.1X Authenticated Wireless Deployment Guide

Deploying Computer and User Certificates
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.