!!BryanOR writes:
In our environment we actually created a login script (.vbs) that not only enabled/verified folder encryption on target locations, but also built into it a check for user certificate check for "best valid certificate" while updating to a status file located within the user's profile and then FTP or TFTPing the status file to a central location for easy parsing and management of encryption status for all users and machines in our environment.

!!!Script logic (simplified):
  • At login the script runs in the user's context.
    • It checks the Registry to see if the user has run the script on this system before.
    • If not, the script writes some info and exits.
    • This was to address the issue whereby it takes 60 sec. (default time frame) for the user to receive their auto-enrolled CA EFS Cert (when logging on to a system for the first time, and using local - not roaming - profiles).
    • If the user has not yet received a certificate and the script hadn't exited, then EFS would not detect a domain CA EFS cert, and would generate the self-signed local EFS cert.
  • So, at the second logon the script again checks the Registry, determines that the user has run the script once before and verifies that the user has a valid domain-issued EFS cert.
  • If yes the script then checks for the presence of some specific applications like Office, Outlook, etc. If any of these is found to be running, the script prompts the user to close these applications before proceeding.
  • The script continues enabling/verifying that the targeted folders (My Documents, Outlook, etc) are being encrypted and if not the script enables folder encryption and encrypt all subfolders and files. (Any errors are written to a status file.)
    • When performing encryption the script utilizes the UNIX touch.exe utility to capture all "Last Modified" dates prior to encryption and once encryption is complete, the script re-applies the original "Last Modified" dates (so that "Last Modified" dates are not lost).
  • If a user has received a new certificate, the script then (through a best-valid-cert logic) updates the EFS registry setting with the new certificate's thumbprint and sets a flag in the Registry for the script to "rekey" all encrypted data at the user's next logon.
  • At the next user logon the script notifies the user that an update is required to maintain their encrypted files and the script then rekeys all of their data.
  • Status and old/new certificate thumbprints are captured and written to the status file.
  • "Last Modified" dates are again maintained.
  • If needed, the script is also utilized at sites to decrypt users' encrypted data during PC migration operations.

The only dependencies of the script are the touch.exe and of course capicom.dll (for the scripting objects).

To verify best valid certificate we enumerate all certificates and select best certificate. Then compare thumbprints. If not using best…update hash and mark for pending rekey at next logon.

Partial logic:
' ** Enumerate all certificates and select best certificate
For Each objCert in objCertStore.Certificates
txtArchived = objCert.archived
txtThumbprint = objCert.Thumbprint
txtValidFrom = objCert.ValidFromDate
txtValidTo = objCert.ValidToDate
txtIssueingCA = objCert.GetInfo(1)
txtTemplateName = objCert.Template.name
txtHasPrivateKey = objCert.HasPrivateKey
txtValid = objCert.isvalid
' """""""""""""""""""""""""""""""""""""""""""""""""""
' ** Select Best Certificate
if (txtArchived = FALSE) AND (DateValue(txtValidFrom) <= Now()) AND _
(DateValue(txtValidTo) > DateValue(txtBestValidTo)) AND _
(Instr(UCASE(txtIssueingCA), "IssuingCAName") > 0) AND
(Instr(UCASE(txtTemplateName), "EFS") > 0) And _
(txtHasPrivateKey = TRUE) AND _
(txtValid = TRUE) Then

txtBestValidTo = txtValidTo
txtBestCertThumbPrint = txtThumbprint
End If

All credit for this script goes to our script god "Chuck D"

Since I have taken over the script I have only need to add a few checks and balances for the capicom.dll and to included enabling the users desktop folder for encryption---very tricky.

Last edited Oct 30, 2007 at 5:27 AM by MikeSL, version 1


BryanOR Nov 9, 2007 at 4:49 PM 
Good morning all,
So let’s start chatting.... As discussed before, the EFS Assistant is a great utility. It allows for targeting specific/multiple locations to enable encryption. The option of identifying specific file types to encrypt is nice as well, but on some systems this can bog down the system. This is one benefit over our in house script solution. If we want to add more locations, other then the users My Documents and default outlook folder, I have to update our script. Adding the new location is easy, its adding the error checking that can be somewhat of a pain. One of the locations that we have been targeting for encryption is the users desktop folder. With EFS Assistant, it CAN’T actually enable the desktop folder for encryption because it is locked, so at every login it will just encrypt everything in it…great. I found away to do this with our script solution, but it is not the best way to go about doing it. I actually under the users context, kill the explorer.exe process, enable the desktop folder for encryption and then restart the explorer.exe process. I have tested this with no issues in several different cases. The only time it was not enabled was if another process had a handle on or in the desktop folder. I don’t like the idea of killing the explorer process but as long as there is checking involved to verify it is restarted under the user context, it works great and only takes a second. With the folder being enabled for encryption, then everything created on the desktop is automatically encrypted, where with the EFS Assistant, it looks to encrypt the desktop folder and all of it contents every time the user logs on or it does a scan. Since the desktop is primarily used as the working area files are constantly being moved back and forth. If they are putting big files there it can slow login time….at least that is what I have noticed……

Certificate management: “possible integration of this tool with the EFS Assistant”
So if managing user EFS certificates were not an issue, I would most likely implement the EFS Assistant in our environment, but managing EFS certificates is a big issue. What should happen, is that if a user receives a new EFS certificate, and it has been issued by an identified trusted Domain Certificate authority, and EFS is enabled on the system , then Windows should prompt the user that a new EFS certificate has been received from a trusted source and ask the user if they would like to use the new certificate. If the user chooses yes, then it should update the hash and then prompt the user that an update is required on there encrypted files to use then new certificate and whether to update (re-key) all there encrypted files with there new certificate now or schedule it to run at next user logon. This will insure from a recover stand point that the user or Admins only needs to be concerned with a single certificate.
If the user says no, then it should not prompt the user again unless two events take place. One is if the user again receives another more current, valid, trusted EFS certificate or two, by default at about 4-6 weeks from there current certificate expiring or the Root certificate\issuingCA expiring, assuming Autoenrollment is enabled and some additional setting, the user will auto-re-enroll for a new EFS cert.
One benefit to our in house script is that this is built in to our script. after the user has encrypted the targeted location, at every logon the script just verifies that the targeted locations are still enabled for encryption and looks in to the users personal store to see if they have received a new certificate. If they have then is will compare all certs to the currently used certificate. If it is found that there is a new more valid trusted certificate, it will update the EFS hash and prompt the user at next logon that an update is required and it will re-key all encrypted data with the new key. Now if there is a new certificate and it is not from our trusted domain issuing CA then it is not considered a valid cert.