Assume an MS-AD only environment, Windows 7 clients, 2008/12 R2 servers etc. Wireless security preference is for EAP-TLS, with host AND user certificates (for total visibility). Also assume cert-auto-enroll for users and hosts is happening.
In this model, consider a user logging on to a wireless-only connected laptop (host-eap-tls-auth'd, just booted). In this scenario, the default Windows (no supplicant) behaviour is to disconnect the user after the AD login, because the user hasn't enrolled on THAT laptop for a cert quickly enough. This can be resolved by jacking into the wire, and waiting for the user cert (usually provoked by another logon, or gpupdate).
Of course, this isn't a "perfect world" solution.
So, my question is whether anybody has come up with a "silver bullet" for this?
In my mind, I've toyed with a few theories, but not tried them yet. I'm curious to know if anybody has, and what success was achieved? At a raw level, I was thinking within AD, perhaps some kind of hold-off timer might work by a GPO alteration or reg-hack? Beyond that, perhaps a third party supplicant would be assistive? One that allowed a similar "hold-off-untill-cert-retrieved" feature?
Note that the customer in this scenario doesn't have much money. So supplicants would have to be cheap. And of course, something like Clearpass overlay isn't commercially viable. Also note that the AD is somewhat large, and unpredictable in terms of "how long" before AD pushes the user cert down to the host.
I have had similar issues with a customer in the auto-certerficate renewal process after one year. A fairly high percentage of clients fail to renew their certs, and then.....no network. When that happens, they need to pull the machine off the shop floor and take it to a wired connection.....not ideal.
The issue is definately a windows issue, but hard to get to the bottom of it.
The initial setup of the machine is via a cable so it can get the machine cert etc, but would be good to know if there are other ways as you say.
If the customer does not have a lot of money, EAP-PEAP is perfectly acceptable if the trust settings are locked down with group policy on the clients. There is absolutely no need for the complexity of EAP-TLS in an environment where there is not enough money to pay someone to manage certificates.
Most organizations go with Machine-Only certificates and forego user visilbility, which matches the exact same experience if you are plugged in wired. There is no way around a user having to be plugged in wired before getting a user EAP-TLS certificate; if you want to get creative, you can identify multi-user machines and make them machine authentication only vs. machines that have only a single user and have them login only once to get their certificate, but the overhead is unwarranted.
Thanks for the view Michael.
CJ, good points. I had a similar dialogue (in terms of what you've said) with the customer myself prior to posting.
I should be honest and add a couple of other points to complicate it (was trying to keep it simple in the first post to provoke creative suggestions).
1. The PEAP(MSCHAPv2) option was ruled out by their security team due to "policy" (MSCHAPv2 being broken etc.).
2. They have Apple laptops (business owned) as well as MS, that aren't in AD.
3. It's not Aruba gear (sorry, cheeky I know, but the best minds are in these forums). This and the last point means no host-enforce.
4. They want to avoid staff using their own AD creds on their own devices on this service without approval (good plan to keep out virus riddled laptops).
So, this leads us to the EAP-TLS option as being the only viable one I believe? The process being auto-enroll for bulk users/hosts, and web-enroll for approved Apples (probably based on user-creds again). We actually have set it all up this way, and it's 99% there.
The gap the customer was left with was subsequent new user logins on machines without a wire. These scenarios are rare of course. As I suspected, this is an immovable object. Hence my post looking for silver bullets.
I'm in this exact scenario and am curious if there has been a "silver bullet" found since posting/replying?
We have a school scenario where multiple users log into the machines and they want to use EAP-TLS for the user authentication. However, the users aren't able to get the cert to authenticate to the wireless because they're not able to connect to the wireless (chicken/egg).
Is there any Group Policy setting that would failthrough to use PEAP/MS-CHAPv2 in the event EAP-TLS is unavailable?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.