locked
Computer Certificate Enrollment Sequence For Wired 802.1x Authentication RRS feed

  • Question

  • Hi

    We're in the process of implementing 802.1x wired authentication 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 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.

    Just for my own understanding, when does a newly built machine process the enrollment request for a computer certificate?  Is a reboot required for the certificate request to fully process?  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?  We have tried gpupdate /force and certutil -pulse and neither of these commands made the certificate appear prior to rebooting the system.

    Thanks

    Josh

    • Changed type jdbst56 Monday, August 8, 2016 5:48 PM
    Monday, August 8, 2016 5:30 PM

Answers

  • I wanted to come back and give an update on this.  As I had mentioned before, it 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 for the certificate anyway just to be safe.  Thanks for all the replies on this one.

    Thanks

    Josh

    • Proposed as answer by Amy Wang_ Friday, August 12, 2016 1:10 AM
    • Marked as answer by jdbst56 Friday, August 12, 2016 1:28 PM
    Thursday, August 11, 2016 10:41 PM

All replies

  • Hi Josh,

    Based on my understanding, the certificate should appear after running GPupdate /force.

    I suggest you look into Application log to see what happens when Autoenrollment takes place.

    We will need to set  new registry key to turn on more detailed autoenrollment auditing:
    In HKCU\Software\Microsoft\Cryptography\Autoenrollment and HKLM\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.

    After that, run GPupdate /force, then check Application event log.

    More information for you:

    Troubleshooting Certificate Autoenrollment in Active Directory Certificate Services (AD CS)

    http://social.technet.microsoft.com/wiki/contents/articles/3048.troubleshooting-certificate-autoenrollment-in-active-directory-certificate-services-ad-cs.aspx

    Best Regards,
    Amy


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, August 9, 2016 12:54 PM
  • Also check the template you use to be sure that Domain Computers has Read, Enroll and Autoenroll checked in the security tab. As Amy said, the gpupdate /force will bring the certificate down via GPO Computer Configuration as you've configured, without a reboot.
    Tuesday, August 9, 2016 4:49 PM
  • Amy/Bill,

    Thanks for your replies.  If I add a computer to the domain and run gpupdate /force prior to rebooting, should I see the certificate at that point?  I'm wondering if my issue is the fact that the join domain process is not fully completed until the reboot is performed.  I tried to add the enrollment configuration to the registry and ran gpupdate /force right after I joined the PC to the domain but it would still not actually show any certificate in the store until a reboot is performed.

    This sequencing is important for 802.1x because if the certificate is not present before the EAP policy is enforced, the Cisco ISE policy server will blackhole the machine.

    Thanks

    Josh

    Tuesday, August 9, 2016 7:03 PM
  • In most cases, you have to set up a quarantine network that will allow connectivity to the CA in case the certificate is not deployed.

    Alternatively, builds should take place on a VLAN that does not implement 802.1x authentication.

    Either way, your build process should include verification that the certificate is in place before the computer is released into the wild.

    Brian

    Tuesday, August 9, 2016 7:06 PM
  • Thanks for your response Brian.  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 to reimage a system.

    If we allowed the quarantine network to connect to the CAs, would they also have to be able to connect to the AD domain controllers as well?  Is there an AD authentication being done as part of the enrollment and issuance of the certificate?

    Thanks

    Josh

    Tuesday, August 9, 2016 8:12 PM
  • Yes, they would need DNS and Kerberos to authenticate (certificate templates are based on permissions). So plan for connections to a DC and to the CA.

    Brian

    Tuesday, August 9, 2016 9:32 PM
  • Yes, they would need DNS and Kerberos to authenticate (certificate templates are based on permissions). So plan for connections to a DC and to the CA.

    Brian

    Thanks Brian.  I was afraid of that.  Opening that level of access on a blackhole VLAN probably negates much of the benefit of 802.1x from a security standpoint.  I would be interested to hear from others with ISE/802.1x experience if there are any other solutions to our dilemma.  What's interesting is that this setup appeared to be working fairly reliably for a few months.  We would use MS-CHAP auth to put the machine on a "build" VLAN.  The machine would stay on that VLAN until the build completed and reboot which it would then pull the certificate down and then process the GPO for 802.1x supplicant and switch the VLAN assignment over to our production workstation VLAN.  For whatever reason, it seems like things got out of sequence recently so either the certificate pull is taking longer and/or the machine GPO is processing quicker and allowing 802.1x to configure itself for EAP auth prior to the cert getting there.  I did not know if there was some sort of timer or grace period on the ISE policy server or switch side that would allow the machine to stay on our build VLAN for a bit longer to ensure the certificate is processed prior to enabling EAP auth.  We have thought about using a startup script or SCCM push that would check for the presence of the certificate prior to changing the auth to EAP on the workstation, but this would not be as clean and reliable as using a straight GPO configuration.

    Thanks

    Josh

    Tuesday, August 9, 2016 10:24 PM
  • The main issue is that there is no trigger for autoenrollment. It happens when it happens. And appears to be happening (on some machines) after the application of the GPO enforcing certificate-based auth.

    What if you used a group membership for the GPO, that is only applied after a check is passed to confirm the certificate is in the machine store?

    Brian

    Wednesday, August 10, 2016 1:24 AM
  • The main issue is that there is no trigger for autoenrollment. It happens when it happens. And appears to be happening (on some machines) after the application of the GPO enforcing certificate-based auth.

    What if you used a group membership for the GPO, that is only applied after a check is passed to confirm the certificate is in the machine store?

    Brian

    Thanks Brian.  When you say there is no trigger for autoenrollment, does that include joining the domain?  What we found interesting is that although the certificate does not appear in the store until a reboot is performed, the timestamp on the certificate is shortly after the computer joins the domain.  Perhaps the reboot is needed to fully process the domain membership and pass the kerberos credentials through to the CA in order to download the certificate?

    We probably will have to use some sort of script as you recommended to do a detection of the certificate before processing the EAP policy.

    Thanks

    Josh

    Wednesday, August 10, 2016 2:14 PM
  • I wanted to come back and give an update on this.  As I had mentioned before, it 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 for the certificate anyway just to be safe.  Thanks for all the replies on this one.

    Thanks

    Josh

    • Proposed as answer by Amy Wang_ Friday, August 12, 2016 1:10 AM
    • Marked as answer by jdbst56 Friday, August 12, 2016 1:28 PM
    Thursday, August 11, 2016 10:41 PM
  • Hi Josh,

    Glad to hear that the cause is found and thank you for sharing with us!

    Here are some scripting forums below for you in case assistance is required regarding scripting:

    The Official Scripting Guys Forum

    https://social.technet.microsoft.com/Forums/scriptcenter/en-US/home?forum=ITCG

    MSDN Scripting Forum

    https://social.msdn.microsoft.com/Forums/en-US/home?forum=scripting

    Windows PowerShell Forum

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverpowershell

    Best Regards,

    Amy


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Edited by Amy Wang_ Friday, August 12, 2016 1:12 AM
    Friday, August 12, 2016 1:11 AM