Wednesday, April 29, 2015

Windows Certificate Autoenrollment Triggers

It's been a while since my last post but today I'm back with a new post to clarify how certificate autoenrollment works in a Windows environment. To be more precise, what triggers this process and how does it work when you're using a client offline? As you know, the certificate autoenrollment feature is very handy to automatically request and renew both user and machine certificates for various reasons so sit back and read on.

First off, what triggers the certificate autoenrollment? This is defined in the Task Scheduler in the following location.


Browsing to CertificateServicesClient, the following tasks are defined by default.


One of the tasks (UserTask-Roam) is disabled by default so let's skip that one and have a look at the other ones. In principle, the two remaining tasks are the same. The one major thing that sets them apart is with what account they are executed. As the name suggests, SystemTask is executed with the System account and UserTask is executed with currently logged on user account. So, what triggers these tasks to execute?


As can be seen, there are three triggers configured for these tasks.
  1. On an event
  2. At task creation/modification
  3. At startup/At logon
Ignoring the second trigger as it's quite obvious when that one triggers, let's have a look at the third one. As it suggests, it executes at startup for the SystemTask and at logon for the UserTask and then repeats every 8 hours. This seems pretty straight forward but aren't we all told that updating group policies also triggers a certificate autoenrollment? This is where the first trigger comes into play.


As soon as event id 1503 from the source GroupPolicy is raised in the System eventlog, it will trigger the certificate autoenrollment. This is true for both user certificates (UserTask) and machine certificates (SystemTask). So when is this event raised? Normally, it is raised at startup, user login and every 90 minutes with a 30 minute offset (i.e. 90 +/- 30 minutes). Filtering the system log for event id 1503 shows that this event is raised quite often.


So, what's the use of this information. Well, let's say you have a number of users who rarely comes into the office and you don't use DirectAccess (why wouldn't you?) but another third party VPN provider that uses certificates as a secondary factor for authentication. Are the certificates being processed for autoenrollment? That depends on how long the users stay connected to the VPN. An easy method for making sure that the certificates stay fresh is to execute something when the user connects to the VPN service that triggers the certificate autoenrollment. How about the command "gpupdate /force /wait:0"? Yes, adding the switch /force will indeed raise the event 1503 which in turn will trigger certificate autoenrollment. Brilliant!

No comments:

Post a Comment