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.
- On an event
- At task creation/modification
- At startup/At logon
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