Active Directory Computer Certificate Enrollment Sequence For Wired 802.1x Authentication EAP-TLS

[joshbilsky]

Hi

We are currently working with our networking group to implement 802.1x wired authentication for Windows 7 workstations with Cisco ISE.  We are using Windows 7 Enterprise SP 1 clients in a Server 2008 R2 domain and the internal Microsoft CA is configured to issue certificates to the computers.  Autoenrollment is configured in the default domain policy.  During our MDT build process, we configure the Windows 7 native supplicant to temporarily use username/password authentication (MS-CHAP) so that it can get the proper network access to join the domain and perform application installation.  We then have a AD group policy baseline that includes the 802.1x certificate-based (EAP-TLS) configuration.  The problem we are experiencing is that it appears that the workstation does not obtain a computer certificate early enough in the build process so that when it reboots after the build is complete, it attempts to authenticate to ISE using a certificate that does not exist on the computer.  Once the machine is in this state, the only way to fix it is to manually reconfigure the supplicant to use MS-CHAP or temporarily move the machine to a non 802.1x-enabled port so that it could connect to the CA and pull a valid certificate.

Unfortunately I'm not familiar with AD certificate services enough to know when a newly built machine is supposed to process the enrollment request for a computer certificate.  From our testing, it appears that the timestamp on the certificate is shortly after it joins the domain, but we do not see the certificate appear under the computer account's personal certificate store until after a reboot.  If this is the case, short of only building the machines on non 802.1x-enabled ports, is there any way to ensure that the certificate is there prior to the reboot?  Is there any delay that can be set in ISE or the network port so that the machine can stay on the build VLAN long enough during the reboot/startup so that the AD certificate is deployed to the machine?

Thanks

Josh

[jkuehl]

i have run into that issue with my deployment using certificate based authentication.  i have had to use a non 802.1x port to get the certificate installed and then move to a 802.1x port to test.  depending on what version of ISE you are running, ISE 2.0 and higher have a certificate provisioning portal that can be used, but you will have to let ISE issue the certificate.

[joshbilsky]

Thanks for your reply. It had seemed like for months we had no issues with our configuration of MS-CHAP for the MDT build and then the GPO switch over to EAP post-reboot. We had noticed client certificate issue in the last week or so, but as of this past Monday, the issue seemed to disappear. We spoke with our sysadmins and they had advised us that they had forgot to purge out the old smart card CRLs which we inject into our DCs to prevent revocation outages in case of loss of internet connectivity. When these CRLs start stacking up in the DCs, it puts a strain on all Kerberos related functions. We know this because we had found out the hard way after an occasion of letting them stack up to the point of all logins to our AD environment had stopped. Anyway, our admins purged the CRLs out this past Monday which we assume took the strain off the Kerberos authentications and thus allowed the client certificates to come down before the EAP policy is set. We may still consider setting up a validation script to check for the certificate before applying the EAP settings as a precaution so that machines don't switch over from MS-CHAP to EAP auth unless they have a valid certificate in their store.  The difficulty with using an isolated non-802.1x network is the additional work it would create for in place imaging of machines. We would prefer for our techs to not have to carry a machine back to their shop in order to reimage a system.

Thanks

Josh