I am going to cover how to deploy Virtual Smart Cards. In this section I am going to perform a simplified deployment using Active Directory Certificate Services and tpmvscmgr.exe. In a complex environment you may wish to use additional tools such as scripts and Forefront Identity Manager to assist in your deployment. Later on I will be discussing how to implement FIM CM and use that to manage Virtual Smart Cards. Although, you can deploy Virtual Smart Cards without FIM CM, I wouldn’t recommend it because much of the management including unblocking a smart card cannot be done easily without a tool such as FIM CM.
The deployment steps I am covering are also covered the document Understanding and Evaluating Virtual Smart Cards, which is necessary read for anyone deploying Virtual Smart Cards. The document can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=29076
Before I cover the actual deployment I feel that it is important to understand Smart Card related Group Policies. First of all the Smart Card related group policies can be located at the following location in the Group Policy Editor: \Computer Configuration\Administrative Templates\Windows Components\Smart Card.
Below are the GPO settings available via Group Policy:
Allow certificates with no extended key usage certificate attribute
These Group Policy settings are described in detail, here: http://technet.microsoft.com/en-us/library/ff404287(v=ws.10).aspx
· Active Directory
· Domain Controllers must have a valid certificate for use with Smart Card Logon. The following article covers the requirements for the certificate: http://support.microsoft.com/kb/281245
· An Enterprise Certification Authority running on Windows Server 2012 or Windows Server 2012 R2. Steps for setting up a PKI on Windows Server 2012 is available here: http://blogs.technet.com/b/xdot509/archive/2013/03/22/installing-a-two-tier-pki-hierarchy-in-windows-server-2012-wrap-up.aspx
· Windows 8.0 or Windows 8.1 domain joined computer that has a TPM that is version 1.2 or greater.
· Certification Authorities issuing Smart Card logon certificates must be in the NTAuth store.
In order for Smart Card logon to work, any domain controller that may receive a Smart Card logon needs to have a certificate installed. The specific details of what need to be included in that certificate are listed here: http://support.microsoft.com/kb/281245. However, there are Certificate Templates that are built into Active Directory Certificate Services that can be used for this purpose. Below are the 3 default templates that can be used:
Domain Controller: Domain Controllers will automatically enroll for a certificate based on the Domain Controller template if it is available on a CA. The Domain Controller template is a Version 1 template. If a certificate is requested using this template it will include the DNS name of the Domain Controller in the Subject and Subject Alternative Name. Additionally, the DS Objet Guid for the domain controller will be included in the Subject Alternative Name extension. The resulting certificate will also include Client Authentication and Server Authentication in the Enhanced Key Usage extension.
Domain Controller Authentication: The Domain Controller Authentication is a Version 2 template and can be used with autoenrollment to deploy a certificate based on this template to all Domain Controllers. If a certificate is requested using this template it will include the DNS name of the Domain Controller in Subject Alternative Name. The resulting certificate will also include Client Authentication, Server Authentication, and Smart Card Logon in the Enhanced Key Usage extension.
Kerberos Authentication: The Kerberos Authentication is a Version 2 template and can be used with autoenrollment to deploy a certificate based on this template to all Domain Controllers. . If a certificate is requested using this template it will include the DNS name of the Domain Controller, the shortname of the domain, and the DNS name of the Domain in Subject Alternative Name. The resulting certificate will also include Client Authentication, Server Authentication, Smart Card Logon, and KDC Authentication in the Enhanced Key Usage extension.
If you do not have a certificate on your domain controllers, you will get an Event 29 warning event for Kerberos-Key-Distribution-Center, followed by an Error event 19 logged.
Below are steps that show an example of how certificates can be deployed to domain controllers to support Smart Card logon. It is just an example. There are a number of considerations that must be made when determining how certificates are deployed to domain controllers. Although, autoenrollment is the easiest way to deploy certificates to domain controllers there are instances where it might not be appropriate. Some considerations include whether other certificates such as 3rd party certificates are installed on domain controllers and whether autoenrollment would interfere with the use of those certificates.
A group policy must be created to enable the autoenrollment client. Here, I am going to create and enable a GPO on the Domain Controllers container.
First, open the Group Policy Management Console (gpmc.msc)
In the Group Policy Management Console, expand the Domains node, and then the node with the name of the domain. Locate the Domain Controllers container. Right click on the Domain Controllers container and from the context menu select Create a GPO in this domain, and Link it here…
Next, enter the name you have chosen for the GPO, and click OK.
In the Group Policy Management Console, locate the newly created GPO. Right click on the GPO, and select Edit from the context menu.
Expand Computer Configuration, then Policies, and then Security Settings. Then select Public Key Policies. In the Object Type pane, double click on Certificate Services Client – Auto Enrollment.
This will open the Enrollment Policy Configuration. To enable autoenrollment perform the following steps:
1. Change Configuration Model to Enabled
2. Check Renew expired certificates, update pending certificates, and remove revoked certificates
3. Check Update certificates that user certificate templates
The next step is to add the Certificate Template to any CAs that will be required to issue certificates based on the template. In the example below, I will be adding the Kerberos Authentication template to a CA.
In the Certification Authority Management Console (certsrv.msc), right click on Certificate Templates. Then select New, then Certificate Template to Issue from the context menu
On the Enable Certificate Templates menu, select Kerberos Authentication and click OK.
The Kerberos Authentication Certificate Template is now available on the CA.
First open pkiview.msc
Once Enterprise PKI (pkiview.msc) opens, right click on Enterprise PKI and select Manage AD Containers… from the context menu.
When the Manage AD Containers window opens, select the NTAuthCertificates Tab. Ensure that the CA(s) issuing Virtual Smart Card certificates are listed here. If your CA is not listed, click the Add… button to add its certificate.
First, open the Certificate Template MMC by launching certtmpl.msc.
Once the Certificate Template MMC is open, select the Smartcard Logon template, and select Duplicate Template from the context menu.
You will then be presented with the Compatibility Tab. Select Windows Server 2012 R2 as the Certification Authority.
You will then be notified of features that will now be enabled in the Certificate Template. Select OK.
Under Certificate recipient, select Windows 8.1 / Windows Server 2012 R2
Next, we move on to the General Tab. Under Template display name, enter a name for the Certificate Template. And under Validity period choose how long you would like the Virtual Smart Card certificates to be valid. 1 year is common for both Smart Card and Virtual Smart Card certificates. This is because the certificates are used to logon and gain access to resources, so we want to keep the validity period as low as practically possible.
On the Request Handling Tab, select Signature and smartcard logon as the purpose. Once you make this change, verify that Prompt the user during enrollment is selected. For Virtual Smart Card certificate renewals, the user needs to be prompted, because they will have to supply their VSC PIN when renewing their certificate.
You will receive the following prompt: Changing the certificate purpose may change various cryptographic settings such as minimum key size, algorithms, and cryptographic service providers. After you change the certificate purpose, select the Cryptography tab to review and, if desired, modify the new cryptographic settings.
Click, Yes.
On the Cryptography Tab, select the Requests must use on of the following providers radio button. Then select Microsoft Base Smart Card Crypto Provider. Ensure that this is the only CSP selected. Note: When using the CSP the Maximum key length allowed is 2048-bit. Although the UI may allow you to enter a larger key size, the resulting certificate will have an RSA key pair no larger than 2048-bit.
Alternatively, you can use a Key Storage Provider (KSP) instead of a Cryptographic Service Provider (CSP). You would want to make this change if you need to use one of the ECC algorithms (more on this later). To choose the KSP, under Provider Category select Key Storage Provider. Then select the Requests must use one of the following providers radio button. Then check Microsoft Smart Card Key Storage Provider.
Next, onto the Security Tab. You will want to determine which users you want to have the ability to enroll for the Virtual Smart Card certificate. Once you make that determination, you will want to put that set of users in a security group and add them to the permissions on the certificate template. In my example, I used the Authenticated Users group, which is there by default. You will then want to give Read and Enroll permission to the group you wish to allow for enrollment. This completes the configuration of the Certificate Template. Click OK, to save your changes.
Now you will have to make that certificate template available on each Certification Authority that you want to make available for issuing. On each Certification Authority, open the Certification Authority Management Console (certsv.msc). Navigate to Certificate Templates. Right click on Certificate Templates then from the context menu select New, then Certificate Template to Issue.
In the Enable Certificate Templates menu, select the Virtual Smart Card template you created. In my example, the template is named Virtual Smart Card. Then click OK.
You should now see your Certificate Template available on the Certification Authority.
I am going to cover the steps for manually creating the Virtual Smart Card. To create the VSC we will use tpmvscmgr.exe.
On the machine on which you want to create the Virtual Smart Card, run the Command Prompt in the context of Administrator.
Depending on your settings you may be prompted by User Account Control, if so click Yes.
Below is an example you can use to create the Virtual Smart Card. You may want to alter the command based on your desired settings. The create option of course tells the command to create a VSC.
The /name switch gives a name to the VSC.
The /Pin option allows you to configure the PIN. If you specify Default the PIN will be set to 12345678, alternatively you can use the PROMPT option if you wish to be prompted for a PIN.
The /adminkey option will generate an administrative key that can be used to unblock the VSC. You can specify DEFAULT to specify the default key, RANDOM to create a random key, or PROMPT to be prompted for a key.
Please see the following article for additional information on tpmvscmgr.exe: http://technet.microsoft.com/en-us/Library/dn593707.aspx
In the example below, the following command is used: tpmvsmgr.exe create /name myVSC /pin default /adminkey random /generate
Once your VSC is created, it will be given a Smart Card Reader Device Instance ID, as seen below. The trailing number in the Instance ID will increment with each additional Virtual Smart Card that is created on the system. This completes the steps required for manually creating a Virtual Smart Card.
Enrolling for Virtual Smart Card Certificate
Once you have created your Virtual Smart Card, you will then need to enroll for a certificate. Previously, I gave an example of creating a certificate template for use with Smart Card Logon. In this example, I will be enrolling for a certificate based on that template. On the machine with the Virtual Smart Card, open the User Certificates Management Console (certmgr.msc)
In certmgr.msc, you can enroll for a certificate by right clicking on Personal then from the context menu selecting All Tasks then Request New Certificate… This will open the Certificate Enrollment wizard.
Once the Certificate Enrollment wizard opens, click Next.
On the Select Certificate Enrollment Policy page of the wizard, click Next. Note: If you have configured an alternate policy for use in conjunction with Certificate Enrollment Web Services then you may have to select the Enrollment Policy that is associated with CEWS.
Next, on the Request Certificates page of the wizard select the check box next to the certificate template for which you are attempting to enroll. Then click the Enroll button to enroll for the certificate. In my example, I have chosen the Virtual Smart Card template that I created earlier.
You will then be prompted for the PIN associated with the Virtual Smart Card. Enter the PIN and then click OK.
When enrollment succeeds, you will be presented with the Certificate Installation Results page. Click the Finish button.
Now with a Virtual Smart Card created and a Smart Card Logon certificate on the Virtual Smart Card, you now should be able to logon with a Virtual Smart Card. Lock or Logoff the workstation, depending on your situation. Then select Security Device form the menu of Sign-in options. Then enter your pin and hit the Enter key.
A user may at times wish to change his/her Virtual Smart Card PIN. This is especially true if all Virtual Smart Cards are pre-provision for the user. To change the PIN, the user can hold down CTRL + ALT + DEL, while logged on with the Virtual Smart Card. The user then would select Change a password.
In order to change the PIN, the user will then have to enter their existing PIN, the new PIN, and then confirm the new PIN.
Summary
In this article I covered the steps for preparing for deployment of Virtual Smart Cards, and how to manually deploy Virtual Smart Cards. In an upcoming posting, I will cover how to deploy Virtual Smart Cards with FIM CM.
Given the recent breaches on companies both large and small, there has been an increased focus on security and secure authentication. This combined with the adoption of mobile devices to increase the productivity of the mobile worker has left many organizations looking for a way to secure authentication for mobile devices. For mobile devices such as Surface, Windows Phone, Windows Laptops and Windows Tablets there is already a solution that was first introduced in Windows 8, called Virtual Smart Card.
In Windows, we have a number of ways that users can logon to Windows. These enterprise type options available are Password, Fingerprint, Smart Card, and Virtual Smart Card. Most mobile devices such as tablets and phones do not possess a Smart Card reader or a Fingerprint reader, so those options are not typically available. Of course, the user can long in with their domain password, but if you want to increase the security of the authentication, you can use Virtual Smart Card.
Virtual Smart Card leverages the secure storage and cryptographic capabilities of the Trusted Platform Module (TPM) to create a Virtual Smart Card in the TPM that securely stores the private key of the Smart Card Logon certificate to enable login via Virtual Smart Card.
When a user has Smart Card Logon configured, they simply select Security Device from the list of login options, and enter their PIN, much like they would do with a physical Smart Card. This logs them onto Windows and potentially the domain using the certificate stored in the TPM.
As you can see this gives users on mobile phones and tablets a convenient way to login securely to the device and the corporate network.
Virtual Smart Card logon is similar to Smart Card Logon in that it uses PKINIT to use a certificate to authenticate the user to a domain controller via Kerberos.
The following diagram illustrates the logon with a Virtual Smart Card
1. User Selects Security Device at login, and enters their PIN for the virtual smart card.
2. Client generates a PA_PK_AS_REQ. The request includes a copy of the Smart Card Logon certificate, User Principle Name, and Time Stamp. Information included in the request such as User Principle Name and Time Stamp are signed with the Private Key associated with the Smart Card logon certificate. The PA_PK_AS_REQ is submitted to the Domain Controller (Key Distribution Center).
3. KDC validates the request by validating the signature in the request with public key included in the request. The KDC then maps the request to the associated user account.
4. KDC generates a Ticket Granting Ticket (TGT) and sends a PA_PK_AS_REQ back to the client. The PA_PK_AS_REQ includes a session key that is encrypted with the public key from the users's smart card logon certificates.
5. The client can now use the TGT to request service tickets to access resources.
First, we need to discuss the Trusted Platform Module, since the TPM is the device that makes Virtual Smart Card technology possible.
Trusted Platform Module is a cryptographic device that is attached at the chip level to a PC, Laptop, Tablet, or Mobile Phone. The TPM securely stores measurements of various states of the computer, OS, and applications. These measurements are used to ensure the integrity of the system and software running on that system. The TPM can also be used to generate and store cryptographic keys. Additionally, cryptographic operations using these keys take place on the TPM preventing the private keys of certificates from being accessed outside the TPM.
Endorsement Key (EK): Key embedded in the TPM by manufacturer. Private key is embedded in the TPM and cannot be extracted from the TPM. The public key is contained in a certificate. The use of the EK is limited to prevent privacy abuses where an organization could discover the owner of a device by repeated use of the EK. Instead, Attestation Identity Keys are generated to be used in place of the EK. Endorsement Keys are signed by a Trusted Platform Module Entity or TPME, which can be thought of as a type of "Root CA" for TPM Endorsement Keys.
Storage Root Key (SRK): Generated when ownership is taken of the TPM. Storage Root Key is stored locally on the TPM and protects storage on the TPM.
Attestation Identity Key (AIK): Keys generated by the TPM that are linked to the Endorsement Key. These keys are used to prove the identity of the TPM and hence the device.
Later on, we will take a look at Key Attestation. Since each TPM has an Endorsement Key that is “burned in” to the TPM and time of manufacture it is possible to associate a device with an Endorsement Key or an Attestation Identity Key. This allows an organization to add additional security based on the identity of the device via the TPM.
1. User takes ownership of the TPM
2. Shared Secret is established between the User and the TPM
3. EK is requested and shared secret is protected by the EK. The Shared Secret is stored in the TPM. The user also has knowledge of this Shared Secret. The Shared Secret is often referred to as “owner authorization data”.
4. The final phase of taking ownership results in the Storage Root Key (SRK) being created within the HSM.
Some aspects of the TPM can be managed via Group Policy. Group Policies related to the TPM can be located at the following location within the Group Policy Editor: \Computer Configuration\Administrative Templates\System\Trusted Platform Module Services.
The following settings are available via Group Policy:
· Turn on TPM backup to Active Directory Domain Services
· Configure the list of blocked TPM commands
· Ignore the default list of blocked TPM commands
· Ignore the local list of blocked TPM commands
· Configure the level of TPM owner authorization information available to the operating system
· Standard user Lockout Duration
· Standard User Individual Lockout Threshold
· Standard User Total Lockout Threshold
This setting configures the machine to backup TPM owner authorization data to Active Directory. The TPM owner authorization data is required in order to perform a number of functions on the TPM. In order to use this setting the Domain Controllers must be Windows Server 2012. If the domain controllers are Windows Server 2008 R2, there are schema extensions that must first be applied to Active Directory. Additional information on the related Schema Extensions are available here: http://technet.microsoft.com/en-us/library/jj635854.aspx.
This group policy allows blocking of TPM commands. You have to enter the TPM Commands that you would like to block. Commands re blocked by command number.
This group policy disables the default list of blocked commands which includes: TPM_SetOwnerInstall, TPM_SaveState, TPM_Startup, TPM_KeyControlOwner, TPM_PhysicalEnable, TPM_PhysicalDisable, TPM_LoadManuMantPub, TPM_ReadManuMaintPub, TPM_SetOperatorAuth, TPM_ContinueSelfTest, TPM_PhysicalSetDeactivated, TPM_ForceClear, TPM_SHA1Start, TPM_SHA1Update, TPM_SHA1Complete, TPM_SHA1CompleteExtend, TPM_Init, TPM_Extend, TPM_CreateCounter, TPM_ChangeAuthOwner, TPM_SetOwnerPointer, TPM_PCR_Reset, TPM_SaveContext, TPM_LoadContext, TPM_SaveAuthContext, TPM_SaveAuthContext, TPM_SaveKeyContext, TPM_Terminate_Handle, TPM_GetCapabilitySigned, TPM_GetOrdinalAuditStatus, TPM_GetAuditEventSigned, TPM_ReleaseCounterOwner, TPM_IncrementCounter, TPM_ReleaseCounter, TPM_LoadAuthContext, TPM_LoadKeyContext, TPM_ReadCounter, TPM_Evict Key, TPM_DisablePubekRead, TPM_Reset, TSC_ResetEstablishmentBit, TPM_TakeOwnership, TPM_CertifySelfTest, TPM_DirRead, TPM_DirWriteAuth, TPM_GetAuditEvent, TPM_LoadKey, TPM_ChangeAuthAsymFinish, and TPM_ChangeAuthAsymStart.
If this group policy is configured it will ignore the blocked list of commands configured by default in Windows including TPM commands blocked by Group Policy.
Specifies how much TPM authorizations data to store in the registry:
Full: Stores TPM owner authorization, TPM administrative delegation blog, and the user TPM user delegation blob in the registry.
Delegated: Stores the TPM administrative delegation blob and the TPM user delegation blob in the registry
None: No owner authorization data is stored locally.
Standard user Lockout Duration
The TPM has anti-hammering technologies to prevent a brute force attack on the TPM. The anti-hammering protections block the user from sending TPM commands after a certain number of failed authorizations in a certain period of time. Again, the lockout is brought about by a certain number of authorizations in a certain period of time. This setting controls the “period of time” aspect. In other words, administrators can configure the period of time for which fail authorizations will be counted.
Standard User Individual Lockout Threshold
The TPM has anti-hammering technologies to prevent a brute force attack on the TPM. The anti-hammering protections block the user from sending TPM commands after a certain number of failed authorizations in a certain period of time. Again, the lockout is brought about by a certain number of authorizations in a certain period of time. This setting controls the number of failed authorizations by an individual user aspect. If a user exceeds the number of failed authorizations configured by this setting is the amount of time configured by the Standard User Individual Lockout Threshold setting, they will be blocked from issuing commands to the TPM for a period of time configured by the Standard User Lockout Duration setting.
Standard User Total Lockout Threshold
The TPM has anti-hammering technologies to prevent a brute force attack on the TPM. The anti-hammering protections block the user from sending TPM commands after a certain number of failed authorizations in a certain period of time. Again, the lockout is brought about by a certain number of authorizations in a certain period of time. This setting controls the number of failed authorizations by an all users aspect. If all users combined exceed the number of failed authorizations configured by this setting is the amount of time configured by the Standard User Individual Lockout Threshold setting, they will be blocked from issuing commands to the TPM for a period of time configured by the Standard User Lockout Duration setting.
There are a number of administration tasks that you may have to perform to manage the TPM. I will be covering the following administration areas: Turning on the TPM, Clearing the TPM, Retrieving the Owner Authorization Password from Active Directory, and Resetting a TPM that has been locked out.
The first step is to turn on the TPM in the BIOS. I used my Dell Venue 8 Pro for the testing. In order to access the BIOS on the Dell Venue Pro 8, you power down the device and hold down the Volume Down Button for a few seconds. Once in the BIOS, I select the Security Tab. Then within the Security screen, I then select PTT. This brings up TPM Configuration. Under TPM Configuration, I can enable fTPM as seen in the picture below.
Figure 1
In this example, I am going to cover the steps to Clear the TPM. I will then show how after the TPM is cleared you can save a copy of the Owner Authorization Password when the password is not being backed up to Active Directory. In other words, I have the Turn on TPM backup to Active Directory Domain Services setting disabled in Group Policy.
So, first as seen in Figure 1, I have the TPM management MMC open (tpm.msc). I am going to click on the Clear TPM… link in the Action Menu.
Figure 2
As seen is Figure 2, this brings up the Manage the TPM security hardware wizard. I am prompted to restart the computer to clear the TPM. So, I click Restart.
Figure 3
After the reboot, I receive the following prompt as seen in the picture below:
A configuration change was requested to clear this computer’s TPM (Trusted Platform Module)
WARNING: Clearing erases information stored on the TPM. You will lose all created keys and access to data encrypted by these keys.
Press F12 or Volume Up to clear the TPM
Press ESC or Volume Down to reject this change request and continue
Figure 4
What this prompting really does is prove that I have physical ownership of the device before the TPM is initialized.
Next, I log in. And the Manage the TPM security hardware wizard reappears and informs me that the TPM is ready.
Figure 5
In Figure 5, we see that we have the option to Remember my TPM owner password. So, to save the TPM Owner Password, click on that link. You will then be prompted to save the password as a .tpm file, as seen in Figure 6.
Figure 6
And below is screenshot of the contents of that file:
Figure 7
In this section, I am going to cover Clearing the TPM when the TPM information is backed up to Active Directory using the Turn on TPM backup to Active Directory Domain Services setting disabled in Group Policy. I am also going to cover some issues you may run into while performing this action.
I have the TPM management MMC open (tpm.msc). I am going to click on the Clear TPM… link in the Action Menu.
Figure 8
Figure 9
Figure 10
You will notice that unlike when I cleared the TPM that was not being backed up to Active Directory I do not have the option to backup the TPM Owner Authorization password. This is because this password can be retrieved to Active Directory.
Figure 11
When clearing the TPM you may run into some issues if you are backing up the TPM to AD. I chose to clear my TPM and after a reboot I got the error:
Unable to turn on TPM security Hardware
The TPM was not turned on due to an Active Directory backup failure. Please contact your system administrator for assistance.
Figure 12
Two issues can cause this error in my experience. The first is the obvious issue of the fact that you do not have network connectivity to the Active Directory Domain. If that is the case run through your normal troubleshooting steps for network connectivity issues.
The other issue that can occur is if the machine account does not have proper permissions in Active Directory. In my example, I had removed my machine from the domain and rejoined it with the same name after deleting the computer object for that machine. I got the error above and so I looked in the System event log.
In the event log, I noticed the TPM-WMI warning. The details of the warning included the error code 0x80070005, which of course is Access Denied.
Figure 13
So, I opened up ADSIEdit on a domain controller, viewed the properties on the associated TPM object, and saw that there was a SID listed and the computer account was not listed.
Figure 14
So, I replaced the SID with the actual computer account.
Figure 15
However, the initialization of the TPM never finished because of the AD backup error. So, in the TPM management console, I had to click on Prepare the TPM...
Figure 16
And run through the wizard to complete the initialization of the TPM.
Figure 17
If you configure the Group Policy setting Turn on TPM backup to Active Directory Domain Services you probably as I did want to know how to get the TPM Owner Authorization password, so that you can use it to reset a TPM lockout or use it to change the TPM Owner Authorization password.
So, let us first understand how this works. In Active Directory, there is a Computer object associated with the machine. On the Computer object there is an attribute named msTPM-TpmInformationForComputer. That attribute lets you locate the TPM Device Object that is associated with the computer. On the TPM Device Object, you can then locate the msTPM-OwnerInformation attribute and extract the hash of the TPM Owner Authorization password. You can then insert that hash in a text file and use the hash to change the Owner Authorization password or to reset a TPM lockout.
So, here in my example you can see the contents of the msTPM-TpmInformationForCopmuter attribute for my computer named MYDELLVENUE:
Figure 18
As you can see, it shows me the Active Directory location for the associated TPM Device Object. I then navigate to that object in ADSIEdit.msc.
Figure 19
I then open the msTPM-OwnerInformation attribute and copy the string, which is a hash of the TPM Owner Authorization password.
Figure 20
In order to use the hash, I need to insert it into a specially formatted xml document that has a .tpm extension. The format of the document is illustrated below. Where you would insert your TPM Owner Authorization Password Hash where the string TPMOwnerAuthorizationHashGoesHere:
<?xml version=”1.0” encoding=”UTF 8”?> < tpmOwnerData> < ownerAuth>TPMOwnerAuthorizationHashGoesHere</ownerAuth> </tpmOwnerData>
If you need to change the TPM Owner Authorization Password that can be completed using the TPM Management Console. First, open the TPM Management Console (TPM.msc). Then in the Action Pane click on Change Owner Password…
This will open the Manage the TPM security hardware wizard.
Figure 21
On the Change TPM owner password screen of the wizard you can select I have the owner password file if you have .tpm file that has the hash of the TPM Owners Authorization password or if you have the actual password you can select I want to enter the owner password.
Figure 22
In my case I selected I have the owner password file. I am then prompted for the location of the associated .tpm file. I then select Create New Password.
Figure 23
On the next page of the wizard, I have to choose to Automatically create the password (recommended) or Manually create the password. I chose to Automatically create the password (recommended).
Figure 24
I am then presented with the new TPM Owner Authorization password. I click on Change Password to initiate the change.
Figure 25
Finally, I am notified that the Password change completed
Figure 26
The TPM has built in anti-hammering technology. Which essentially means that the TPM will lock itself out when invalid data is presented a number of times over a certain time threshold. If you are using a Virtual Smart Card, a number of invalid PIN entries can cause a TPM to lockout. The number of failed attempts and the time threshold are controlled with the following Group Policy settings: Standard user Lockout Duration, Standard User Individual Lockout Threshold, and Standard User Total Lockout Threshold.
My example below illustrates resetting the TPM lockout with the owner password file.
In the TPM Management Console, I click on Reset TPM Lockout…
Figure 27
On the first page of the Manage the TPM security hardware wizard, I am prompted to either supply the owner password file or the owner password. I chose, I have the owner password file.
Figure 28
I then select the owner password file and then click on Reset TPM Lockout.
Figure 29
I am then notified that the TPM lockout reset completed
Figure 30
If you use the wrong TPM Owner Authorization password, you will get an error like this:
Figure 31
And if you lockout the TPM because you entered the wrong TPM Authorization Owner password, you will get the following error:
Figure 32
If you wish to use PowerShell instead of the GUI to manage your TPM, visit the following website for the list of TPM PowerShell commands: http://technet.microsoft.com/en-us/library/jj603116.aspx.
In this blog posting, I covered an overview of the Trusted Platform Module (TPM). I also covered management of the TPM through the TPM Management Console. In the next blog posting, I will cover how to deploy Virtual Smart Cards.
-Chris
Wow!!! It’s pretty awesome to see the continued evolution of Windows Phone!
I have posted in the past about some really cool features such as NFC and DataSense. But recently there have been a lot of interesting applications released for Windows Phone.
This morning when I woke up and checked my Windows Phone (HTC8X on Verizon) the so called GDR3 update was ready for installation.
First, we have Office Remote: http://research.microsoft.com/en-us/projects/officeremote/
I was able to use Office Remote a couple times last week for some presentations. Office Remote can work with PowerPoint, Excel, and Word. My primary use case is PowerPoint.
First, there is an add-in for Office 2013 that needs to be installed as well as a Windows Phone App. The download links for both locations are available here: http://research.microsoft.com/en-us/projects/officeremote/
In PowerPoint for example you then start Office Remote.
Then you have to pair your phone over Bluetooth. Once your phone is paired you can start the Office Remote App and connect to your phone.
Then you can advance slides using your phone, read presentation notes, and even use a virtual “laser pointer” on your presentation.
I personally am not an Instagram user, but I know this is one of those “gotta have” apps for a lot of folks. Well Instagram Beta is now available here: http://www.windowsphone.com/en-us/store/app/instagram-beta/3222a126-7f20-4273-ab4a-161120b21aea
Vine is a very interesting app that lets you create and share Vine videos, which are of course 6 second videos. Vine has been available for a couple weeks now on Windows Phone and is available here: http://www.windowsphone.com/en-us/store/app/vine/f9e6f07e-e47e-47f5-806d-55d4f79f2b60
Waze is a navigational app that uses social to provide updates on traffic, congestion, and other information related to one’s commute. Waze is available here:http://www.windowsphone.com/en-us/store/app/waze/f07f83eb-a8a4-49fd-8946-c67a9349e062
And last but not least Nokia released the Lumia 1520 on AT&T. the phone is a 6 inch “Phablet” with an amazing 20 megapixel camera.
What a great time to be a Windows Phone owner!
Now, that we have created our first VM we want to get familiar with the Management Tools. For the purpose of this blog posting, I will be covering the Management Tools presented by the Web Interface. Specifically, I will be covering the management tools for Virtual Machines.
Once you login to Windows Azure (https://manage.windowsazure.com) you will be presented with the management website. This website has tools for managing both Windows Azure Platform as a Service (PaaS) and Windows Azure Infrastructure as a Service (IaaS). I will be focusing on tools used to manage Windows Azure VMs in other words Windows Azure IaaS.
Note: I have obscured some personal/private information in the screenshot below for security reasons.
After you create your first VM, click on All Items
You will notice a number of items that were created when you created your first VM.
Storage Account: There is a storage account created to stored the Virtual Disks created by your VM. This same Storage Account will be used every time you create storage in that same region. If you install VMs in multiple regions you will see multiple storage accounts.
Cloud Service: There is a cloud service created. A cloud service is a logical container that originated with Windows Azure PaaS. If you want to create multiple VMs and make it easier for them to communicate with each other you can install them in the same Cloud Service. You can also configure Virtual Networks to accomplish this as well.
Default Directory: This refers to the Windows Azure Active Directory (WAAD) you can leverage for authentication.
Next, if you click on your Virtual Machines you will see a listing of VMs you have created.
You will see a menus at the bottom of the screen that provides a number of options.
CONNECT: Allows you to connect to the Virtual Machine via RDP.
RESTART: Restart the OS for the selected VM
SHUTDOWN: Shutdown the OS for the selected VM.
ATTACH: Attach a Virtual Disk to the VM.
DETACH DISK: Detach a Virtual Disk from the VM.
CAPTURE: Allows you to capture an image of the VM, that can be used to create new VMs.
DELETE: Delete the selected VM.
There is also a menu at the top of the screen.
By default Virtual Machine Instances are selected. When Virtual Machine Instances is selected you see a list of your VMs.
If you select a Images you will see a list of images. Images are used for creating new Virtual Machines. From this screen you can also create an image or import an image from the VM Depot.
If you select CREATE AN IMAGE you can import an image from VHD as seen below.
In order to create an image you must have previously uploaded a VHD to your Windows Azure Storage Account.
The VM Depot is a community drive location where individuals can upload images they have created. If you would like to create a image based on an OS or configuration that is not available and Windows Azure you can look in the VM Depot to see if someone has already created an image that meets your needs.
If you click on DISKS you can view your Virtual Disks. There are also 3 options in the menu at the bottom of the screen: CREATE, EDIT CACHE, and DELETE.
Create allows you to create new Virtual Disk from an existing VHD.
Edit Cache allows you to modify whether caching applies to reads or reads and writes.
Delete allows you to delete the selected Virtual Disk.
If you click on the Virtual Machine name, it will take you to a page that provides additional information, monitoring, and configuration options.
After clicking on the Virtual Machine name you will be presented with a page that displays a number of resources including links to tools, support, and learning resources.
If you click on DASHBOARD you will be able to view basic monitoring and information about the Virtual Machine.
If you click on Monitor you will see the amount of resources used by the Virtual Machine. The specific resources that can are monitored are CPU, Disk, and Network usage.
From the Endpoints page you can Add, Edit, and Delete endpoints. The Endpoints page allows you to map external facing ports to the ports on the Virtual Machine. For example after creating a virtual machine ports for RDP and PowerShell are available over the internet and mapped to a port on the Virtual Machine.
The configure page allows you to change the Virtual Machine Size. Of course pricing is based on Virtual Machine Size, so changing the size will effect the cost. The Virtual Machine sizes that are currently available are listed in the table below:
On the configure page you can also add the virtual machine to an availability set. An availability set provides high availability for a Virtual Machine. When you VMs to an availability set, the Virtual Machines are located in different fault domains to minimize downtime.
The purpose of this blog posting was to cover the management interface for Windows Azure, specifically for Virtual Machines. There is much more in the way of management tools available, for managing things like networking, storage, Windows Azure Active Directory, and more. I will be covering these additional management tools in upcoming blog postings, in addition to proving more detail on the management tools I covered in this blog posting.
So, in my previous blog posting I covered how to create your first Virtual Machine in Windows Azure IaaS. In that blog posting we used the QUICK CREATE method. In this blog posting, we will be performing similar steps using the Virtual Machine from the Gallery wizard. Creating a VM “From Gallery” is pretty straightforward, however, I wanted to cover it for the sake of completeness.
To start the Wizard, select the Virtual Machine node, and the click New.
Navigate to COMPUTE, then VIRTUAL MACHINE, and than FROM GALLERY.
This will then bring you to a wizard that will guide you through creating your first Virtual Machine. You can build a Virtual Machine from Platform Images. Platform Images are the base images provided by Windows Azure. You can also use My Images if you have uploaded your own images. And finally you can use My Disks from Virtual Machines you have created in the past.
As you can see by the list of images you can in fact run non-Microsoft Operating Systems in Windows Azure. So, select the image you would like to use to create your Virtual Machine.
Below are a list of the OS images available at the time of writing this blog:
-Windows Server 2012 Datacenter -Windows Server 2012 R2 Preview -Windows Server 2008 R2 SP1 -Sharepoint Server 2013 Trial -SQL Server 2014 CTP1 Evaluation Edition On Windows Server 2012 -SQL Server 2014 CTP1 Evaluation Edition On Windows Server 2012 R2 -SQL Server 2012 SP1 Enterprise On Win2012 -SQL Server 2012 SP1 Enterprise On Win2K8R2 -SQL Server 2012 SP1 Standard On Win2012 -SQL Server 2012 SP1 Standard On Windows Server 2008 R2 SP1 -SQL Server 2012 SP1 Web On Windows Server 2008 R2 SP1 -SQL Server 2008 R2 SP2 Enterprise Windows Server 2008 R2 SP1 -SQL Server 2008 R2 SP2 Standard Windows Server 2008 R2 SP1 -BizTalk Server 2013 Enterprise -BizTalk Server 2013 Evaluation -BizTalk Server 2013 Standard -Visual Studio 2013 Ultimate Preview -openSUSE 12.3 -SUSE Linux Enterprise Server 11 SP2 -SUSE Linux Enterprise Server 11 SP3 -Ubuntu Server 12.04 LTS -Ubuntu Server 12.10 -Ubuntu Server 13.04 -OpenLogic CentOS 6.3
My recommendation would be Windows Server 2012 or Windows Server 2012 R2, and click the arrow to continue to the next step in the wizard.
On the second page of the Wizard, you will configure the image version, Virtual Machine Name, Size, Username and Password.
Image Version: For the image you selected there may be multiple version. These version are denoted by date. It is recommend that you select the latest version (default) as it is going to be the “latest and greatest”.
Virtual Machine Name: You will need to enter a name for the virtual machine instance.
Size: You need to choose the size of your Virtual Machine from a Processor and Memory perspective. This is very important for two reasons. First you want to size the machine appropriately to handle the workload. Second, the pricing differs by the size. And even if you are using a trial account you only have so much in credits to use during the trial.
The options you have for sizing at this time, are:
-Extra Small (Shared core, 768 MB memory) -Small (1 core, 1.75 GB memory) -Medium (2 cores, 3.5 GB memory) -Large (4 cores, 7 GB memory) -Extra Large (8 cores, 14 GB memory) -A6 (4 cores, 28 GB memory) -A7 (8 cores, 56 GB memory)
New User Name: The name of the local user account you would like to create.
New Password: The password for the local user account you would like to create.
On the next page of the wizard there is some additional configuration required. You will need to configure the following.
Cloud Service: If this is your first Virtual Machine you will have to create a new Cloud Services which is a logical and network container. If you have previously installed a VM or created a Cloud Service you install the VM in the existing Cloud Service which will place it in the same container as the previous VM, which will make it easier to access from a network prospective.
Cloud Service DNS Name: This is the name of the Cloud Service you are creating.
REGION/Affinity Group/Virtual Network: You can specify the Region, Affinity Group or Virtual Network. Region specifies the Region in which the Windows Azure datacenter is located. Current regions available are:
-North Europe -West Europe -East US -West US -Southeast Asia -East Asia
Virtual Networks are networks that you create that give you control over the IP addressing of your environment as well as ensure connectivity between the VMs. I will be covering this in more detail in future blog posts.
“An affinity group is a geographic grouping of your cloud service deployments and storage accounts within Windows Azure. An affinity group can improve service performance by locating computer workloads in the same data center or near the target user audience.” http://www.windowsazure.com/en-us/manage/services/storage/what-is-a-storage-account/
Storage Account: You can configure the new VM to be created in an existing storage account or an automatically generated storage account. Typically the VHDs will be stored in the same storage account if the VMs are housed in the same Region.
Availability Set: You can choose No availably set, create a new availability set, or add the VM to an existing availability set. Availability Sets are used to add high availability. For example if you create two web front ends and put them in the same availability set, they will both run in different fault domains. This minimizes the loss of the service if one of the VMs were to fail or a component with the fault domain failed.
Finally, you can configure what ports are available externally. You can also map the ports on the Private IPs to a port on the Public Virtual IP (VIP).
There is additional information on creating your first virtual machine in my previous blog posting. After you finish your selections, provisioning of the VM will start, as seen below.
Once your virtual machine has been provisioned, you can click connect to connect to the virtual machine via RDP (assuming you created a Windows VM). If you created a Linux VM you can connect via SSH. I will cover this in an upcoming blog.
Once you click connect, you will be prompted to open an RDP file, as seen below. Click Open to open the RDP file.
Then you will have to click connect to connect and acknowledge the security warning.
You will then get another security warning due to a certificate error. This is due to the fact that the RDP connection is protected with a self-signed certificate. Click Yes to acknowledge the security warning.
And, after a few seconds you will be connected to your Windows Azure VM via RDP. You can now manage the Virtual Machine as you would any other server.
Conclusion
In this blog, I covered creating a Windows Azure VM from the Gallery. The purpose of these first couple blogs have to give you the steps for creating a VM in Windows Azure.
Upcoming blog postings will get more advanced including topics like Networking, Storage, Management, and Monitoring.
In the previous two blog postings (Getting Started with Windows Azure: Part 1 Introduction and Getting Started with Windows Azure: Part 2, What are Cloud Services?) I discussed how to get a Windows Azure Trial account as well as some background information on cloud computing and Microsoft’s Cloud Services. In this blog posting I am going to talk about how to get started with Windows Azure IaaS. I am going to cover some basics and how to create your first Virtual Machine in Windows Azure IaaS.
Once you have your Azure Trial setup you can login to your account here: https://account.windowsazure.com/Home/Index
So, let’s create are first Virtual Machine!
The steps I am going to cover for creating your first Virtual Machine are very basic and just to get you familiar with Windows Azure IaaS and the management portal. Eventually, you are going to want to become more familiar with managing Networks, Storage, and Cloud Services. I will cover these topics in upcoming blog posts. We will also eventually cover how to import your own Virtual Machines and how to connect your On Premise network to Windows Azure.
To create your first Virtual Machine you can either click on CREATE A VIRTUAL MACHINE or + NEW.
This will bring up a menu. You have to options Quick Create or From Gallery. I would recommend for your first Virtual Machine that you choose Quick Create.
This will open a form you can fill out to create the Virtual Machine.
DNS Name: You will need to create a DNS Name. This DNS name bust be unique in the coudapp.net namespace.
Image: You will have to select an OS image.
At the time of writing this blog posting the following Platform Images are available:
Size: You need to choose the size of your Virtual Machine from a Processor and Memory perspective. This is very important for two reasons. First you want to size the machine appropriately to handle the workload. Second, the pricing differs by the size. And even if you are using a trial account you only have so much in terms of credits to use during the trial. You can use the Pricing Calculator to determine pricing: http://www.windowsazure.com/en-us/pricing/calculator/.
Reference: http://msdn.microsoft.com/en-us/library/windowsazure/dn197896.aspx
Region/Affinity Group: Then you will need to choose a Region or Affinity Groups. The current region options are:
When finished select CREATE A VIRTUAL MACHINE.
Once you create the Virtual Machine it will take a few minutes to provision.
Once it is created you can view the disk that was created click on Disks.
When you create your first virtual machine it also creates a Cloud Service. A Cloud Service is a logical and a network boundary.
After your VM has been created, you can connect to it by clicking the CONNECT link.
You will then be prompted on an RDP file.
You can then Connect via RDP.
You will be prompted for credentials. Those credentials are created when you provision the VM. You will then be prompted to acknowledge a certificate error, by clicking the Yes button.
Voila!!! You have created your first Azure IaaS Virtual Machine.
“Windows Azure is Microsoft's application platform for the public cloud.” In other words Windows Azure is a platform that allows organizations to have their applications run in the public cloud.
Public Cloud is a service that provides a platform for running applications and services. Characteristics of a Public Cloud is that it uses shared resources that can be allocated and de-allocated on demand. From a pricing standpoint customers are usually charged by their usage of those shared resources.
The term Private Cloud is used to differentiate it from a Public Cloud. Generally it is the same concept as a Public cloud but usually owned by the same company that is using the resources. However, much like a Public Cloud resources are usually abstracted, and can be allocated and de-allocated on demand.
The Public Cloud offers several advantages. One advantage is that a customer does not have to maintain a datacenter and hardware to support their applications as this is handled by Public Cloud Service Provider. Usually, cloud services such as PaaS or Platform as a Service can speed the time that it takes to implement applications. Additionally, Public Clouds can offer a great deal of High Availability and Failover. Also, since resources are only allocated as needed, these services in many cases can be cheaper then if implemented in a Private Datacenter.
Microsoft has Windows Azure which provides both Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Microsoft also offers products such as Windows Intune and Office 365 which are Software as a Service (SaaS). And of course you can install our platforms on Premises or in a Private Cloud.
The graphic below illustrates the differences between On Premise, PaaS, IaaS, and SaaS.
On Premises and Private Clouds can be run with Microsoft Software and Operating Systems. Specifically you can use Windows Server and System Center to implement your Private Cloud. More information is available here: http://www.microsoft.com/en-us/server-cloud/private-cloud/default.aspx
Infrastructure as a Service essentially allows you to install Virtual Machines in the Public Cloud. You then have control over the OS, Middleware, Runtime, Data, and Application portions of the stack. This makes it easier to move On Premises applications and workloads to the Public Cloud. More about Windows Azure IaaS in my next blog post. Windows Azure IaaS is the technology I will be writing about in this blog series.
Platform as a Service delivers the underlying platform on which you install and run your applications. In Windows Azure PaaS most of the stack is provided, and you provide the Applications and Data. Platform as a Service is generally the preferred method of running applications in the Public Cloud as this type of service offers better performance, availability, and scalability.
Software as a Service has been around for quite a while now. SaaS is essentially applications hosted by a third party. Examples of Microsoft SaaS are Windows Intune and Office 365. The advantage to SaaS is that your organization just needs the staff to administer the software, but does not need to run all the underlying hardware, networks, OS, and application. In the example of Office 365 this potentially reduces the cost to provide email for the organization.
The purpose of this posting was to give a high level background of Cloud Services and Windows Azure. In my next posting I will begin my focus on Windows Azure IaaS.
Regular visitors to my blog know that I am an expert in Public Key Infrastructure (PKI). That has been my focus for many years now. I also have a strong background in Active Directory, previously working for the Directory Services support team at Microsoft. As Microsoft transitions to a Services and Devices company, I must transition my skill sets as well. I will continue to periodically blog and talk about PKI. However, a majority of my focus is going to be on cloud technologies such as Azure.
So, this is Part I in which will hopefully turn out to be a long running series on Azure. I will be talking about Windows Azure from the perspective of an IT Professional.
If you are interested in learning about Windows Azure, the first step would be to sign up for a Windows Azure account. You can sign up for a Free Trial here:
http://www.windowsazure.com/en-us/pricing/free-trial/
The Trial listed above is currently limited to 1 month.
However, if you have certain MSDN Subscriptions you can currently get an ongoing trial account here:
http://www.windowsazure.com/en-us/pricing/member-offers/msdn-benefits/
In my last blog posting I covered viewing PKI related Active Directory Objects. In this blog post, I am going to cover the steps necessary to backup and recover AD Objects. The group responsible for Active Directory in your organization should have the capabilities to both back up and restored Active Directory objects. However, I wanted to cover the steps involved for those who may not be familiar with the process. This description of backing up and restoring Active Directory objects covers the steps to perform a backup and restore using the built in back up tools in Windows Server 2012. If your domain controllers are hosted on an older OS the steps will be slightly different.
The process for Restore is called an Authoritative Restore. When you restore a domain controller from a backup and do not perform an authoritative restore it will simply replicate the current state of Active Directory from other Domain Controllers. To ensure the object you want to restore is not overwritten, and is instead replicated out to other domain controllers, an Authoritative Restore needs to be performed. An Authoritative Restore effectively increases the USN number of the object forcing it to be replicated out to other domain controllers instead of being overwritten.
Before backing up Active Directory you first need to install the Windows Server Backup feature. To start the installation of Windows Server Backup go to the Manage menu in Server Manager and select Add Roles and Features.
When the Add Roles and Feature Wizard opens, click Next.
On the Installation Type page, click Next.
On the Server Selection page, ensure the proper server is selected and click Next.
On the Server Roles page of the wizard, click Next.
On the Features page, select Windows Server Backup and click the Next button.
On the Confirmation page, click Install.
On the Results page, click Close.
Now that you have Windows Server Backup installed, you can open it by selecting the Tools menu in Server Manager, and selecting Windows Server Backup.
Once the Windows Server Backup management console opens select Local Backup and then select Backup Schedule…
On the Getting Started page of Backup Schedule Wizard, click the Next button.
On the Select Backup Configuration page, select Custom.
On Select Items for Backup page, click Add Items.
Select System State and click OK.
Then click Next.
On Specify Backup Type, select the appropriate backup schedule, and click Next.
On the Specify Destination Type, select the appropriate Destination and click Next.
In my case I have selected a local disk, so I am going to select the appropriate disk, and clicked Next.
Since I selected a local disk, it is letting me know that it will reformat the drive.
On the Confirmation page select Finish.
Then on the Summary page of the wizard click Close.
Oops, I “accidentally” deleted my FourthCoffee Computer certificate template. So, now let me Authoritatively Restore the template to recover it .
So the first step is to boot one of the domain controllers that have been backed up in Directory Services Repair Mode. In order to do this I reboot the Server. As the Server is booting up I press F8 to bring up the Advanced Boot Options menu. On the Advanced Boot Options menu I select Directory Services Repair Mode.
I then have to log onto the Domain Controller with the DSRM password.
Once logged into the Domain Controller, you will need to start Windows Server Backup. From the Actions pane, I select Recover…
Since, in my scenario I backed up to a local drive, I select This server on the Getting Started page of the Recovery Wizard, then I click Next.
I select the appropriate backup on the Select Backup Date, and click Next.
On the Select Recovery Type page, I select System state, and click Next.
On the Select Location for System State Recovery page, I click Next.
I acknowledge the warning by click OK.
On the Confirmation page, I click Recover.
I acknowledge the warning by clicking Yes.
After restoring the backup I boot in DSRM mode.
I login to the Domain Controller with the DSRM password.
After I login I am prompted that the system state restore finished successfully.
I know need to authoritatively restore the FourthCoffee Computer template.
When prompted I click Yes to continue the Authoritative Restore.
The restore completes successfully.
After the restore, I rebooted the Domain Controller and my FourthCoffee Computer template was now available.
In this blog posting I covered the steps necessary to backup up a Domain Controller. I also covered the steps necessary to restore an AD Object that is deleted. In this scenario I restored a Certificate Template that was accidentally deleted.
This video covers the steps necessary to migrate a two tier PKI to Windows Server 2012. This video replaces my previous videos covering these steps. For those that watched Part I, II, and III of my previous upgrade video series and just want to see the content that was supposed to be in Part IV, you can start the video at the 24:20 mark.
Now that I have Windows 8.1 installed on both my Surface and laptop (Lenovo T430s) I have some time to work on some blogs. I am going to continue on the “Operating a PKI” series. However, I did want to cover Disaster Recovery in a series of blogs as well. I will of course cover backing up and recovering Certification Authorities as well as other topics. I wanted to start of with recovering PKI related data that is stored in Active Directory. But first, let’s identify what data is stored in Active Directory.
So, let's start with a discussion of what PKI information is stored in Active Directory. Some important PKI related information that is stored in Active Directory is configuration information. Configuration information is stored in the Configuration Partition of Active Directory. For those not familiar with Active Directory, it is important to note that the Configuration Partition is replicated to every domain controller in the forest. This has some implications. For example, we will see that Certificate Templates are stored in the Configuration Partition. This means that Certificate Templates are “shared” throughout the forest. So, if you have different parts of the organization that have their own domain and even their own PKI, they will all use the same list of Certificate Templates. Specifically, PKI configuration information is stored in
There are a couple of tools that can be used to view the Configuration Partition. The first is ADSI Edit (adsiedit.msc). ADSI Edit can be installed by installing Active Directory Remote Server Administration Tools (RSAT). To view the Configuration Partition, first run adsiedit.msc. Once ADSI Edit opens, right click on ADSI Edit, and select Connect to… from the context menu.
Once Connection Settings opens, select Configuration from Select a well known naming Context:
Expand Configuration, then CN=Configuration, <RDN of the forest>., then CN=Services, and finally, CN=Public Key Services.
You will see the following containers and objects:
Below is a decryption of the containers and objects:
AIA: Short for Authority Information Access. This is where CA Certificates are stored. If the AIA extension is configured to use LDAP (Active Directory), certificates are fetched from this location if required for chain building.
CDP: Short for CRL Distribution Points. If you choose to use LDAP (Active Directory) as a CDP repository this is where CRLs are stored and then fetched if needed to check revocation status..
Certificate Templates; This is where Certificate Templates are stored. Certificate Templates are used for certificate enrollment when using an Enterprise CA.
Certification Authorities: this container is where Root CA certificates are stored.
Enrollment Services: Enrollment Services container contains Enrollment Services object. Each Enterprise CA publishes an Enrollment Service object. This object is used by enrollees to find Enterprise CAs during enrollment and to locate which Enterprise CAs host the Certificate Template the enrollee is attempting to enroll for.
KRA: The public key of Key Archival certificates are stored in this container.
OID: A container that holds OID information used by Certification Authorities.
NTAuthCertificates: The NTAuth Container contains CA certificates that are trusted for issuing certificates for authentication such as Smart Card logon.
Additional information on these containers is available here: http://technet.microsoft.com/en-us/library/cc783853(v=WS.10).aspx
Viewing these containers is also possible through the Active Directory Sites and Services MMC (dssite.msc).
To view the Services Container, open dssite.msc. Once the MMC opens, select Show Services Node from the View menu.
Then expand Services, then Public Key Services.
Enterprise PKI
To view the Public Key Services container, first start Enterprise PKI (pkiview.msc). Enterprise PKI is installed on the Certification Authority if you chose to install management tools. You can also install the Active DIrectory Certificate Services Remote Server Administration Tools on a management machine. To view the Public Key Services container, first start Enterprise PKI (pkiview.msc). Right-click on Enterprise PKI, and select Manage AD Containers… from the context menu.
Once Manage AD Containers opens, you can view each container by clicking on the corresponding tab. I really like viewing the AD containers, because you get a better understanding of what is contained in these containers.
If you have a Certificate Template configured to Publish certificate to Active Directory, a copy of the certificate will be copied to the userCertificate attribute on the computer or user.
There are a couple ways to view the userCertificate attribute. The method I will mention here is using Active Directory Users and Computers.
So, first launch Active Directory Users and Computers (dsa.msc). Once ADUC opens, open View menu, and then select Advanced Features.
Next, locate a user account for which you would like to view the userCertificate attribute.
Double-click on the desired user account and select the Published Certificates tab. You can now view what certificates have been published to the userCertificate attribute on that user account.
If you want to view the attribute directly, you can without using ADSI Edit. Simply select the Attribute Editor tab on the user account. Then navigate to the userCertificate attribute. This same step can be used for viewing the userCertificate attribute for user accounts.
If a user wanted to view what certificates they have published to their user account. They can open certmgr.msc on their computer and navigate to Active Directory User Object, as seen below.
Group Policies
There are a number of settings that can be configured by Group Policy. Some of these settings include Autoenrollment, Automatic, Certificate Request Settings, EFS Settings, and Credential Roaming.
PKI related settings for the computer are located under \Computer Configuration\Windows Settings\Security Settings\Public Key Policies as seen in the illustration below.
PKI related settings for the computer are located under \User Configuration\Windows Settings\Security Settings\Public Key Policies as seen in the illustration below.
Your organization may have many Group Policies so you will have to determine which policies contain PKI related settings. If you are unsure which policies have PKI configuration you can use the Resultant Set of Policy tool to help determine this. Locate a machine which you believe is receiving the PKI related Group Policies. If you are looking for user related policies you would log in with a user account you believe are receiving PKI related Group Policies. I will use a Computer related policy to illustrate how this can be done.
Once you are logged into the proper machine run RSOP.msc. You will have to be logged in as an Administrator of the machine to view Computer related policies. In my example, once RSOP.msc opened, I viewed all of the settings under \Computer Configuration\Windows Settings\Security Settings\Public Key Policies. Only one of the settings was configured. So, I double click the setting to open it. Then I click on the Precedence tab to determine which policy has configured the setting as seen below.
You can also use other tools like gpresult if you are familiar with them. In “my” environment we can see that Autoenrollment was configured by a policy named Computer Autoenrollment.
Next, I am going to locate the Group Policy in the Group Policy Management Console (gpmc.msc). So, I look under Group Policy Objects in the GPMC, and locate the GPO. As you can see, I can view where the GPO is linked, what security filters are applied, and if any WMI filters are applied.
Group Polices are made up of two components: Group Policy Template (GPT) and the Group Policy Container (GPC). The GPT is stored in Sysvol. Sysvol is a file structure that is replicated amongst Domain Controllers. The GPC is stored in Active Directory. When GPO is applied a client use the GPC to determine which GPOs are applied and where to locate the GPT. the client then loads the GPT to determine what settings need to be applied. And those settings are applied by Client Side Extensions (CSEs).
If you want to locate the GPT and GPC you can follow these steps. Again I will be using my test environment as an example of how to do this. First I click on the Details tab for the Group Policy that I found earlier. I then locate the Unique ID as seen below. The Unique ID for this GPO is 6D5EB75D-356B-488B-91CE-8A032E66E993.
In order to locate the GPT, I navigate to \\fourthcoffee.com\SYSVOL\fourthcoffee.com\Policies and locate the Unique ID for the GPO as seen below.
In order to locate the GPC, I open ADSI Edit (adsiedit.msc). I connect to the Default Naming Context as seen below:
I then expand DC=Fourthcoffee,DC=com, then CN=System, and then CN=Policies. As you can see in the screenshot below I can then see the Unique ID that I had previously located.
The purpose of this blog postings was to help someone not familiar with Active Directory locate where PKI related information is stored in Active Directory. It is critical that this information is understood so that you can understand what needs to be backed up and why. In the next blog I will discuss how to back up this information.
This video covers the steps necessary to revoke orphaned certificates. Additional information on this topic is available at http://blogs.technet.com/b/xdot509/archive/2013/06/18/operating-a-pki-revoking-orphaned-certificates.aspx.
Orphaned certificates are certificates that are issued by a Certification Authority, but after issuing the certificates the Certification Authority has no knowledge of the certificates. This situation most commonly occurs after the restore of a Certification Authority.
is illustrated in the graphic below. In this example the CA is backed up at Time 0. After the backup the CA issues certificates. At Time 1 the CA fails. At Time 2 the CA is recovered from the backup taken at Time 0. The problem here is that after the restore there is no record of certificates issued after the backup, but before the restore. These are known as orphaned certificates. The problem with orphaned certificates is that they are valid, but you have no record of issuing them. And if you have no record of issuing them, you have no way to revoke them if necessary. However, if you have the SMTP module running, you have a list of certificates issued during this time. And although going through a mailbox to determine what certificates you have issued is not the most convenient way to do determine this, at least you have a record. You can also use the information in the email of issued certificates, specifically the Serial Number to revoke these certificates if necessary.
Revoking Orphaned Certificates: A Walkthrough
The steps for revoking the orphaned certificate is to:
Below is a walkthrough or revoking expired certificates.
On my Certification Authority I have issued a total of 7 certificates under Issued Certificates.
I then backup the CA Database
I then requested an a certificate from the CA. I now have a total of 8 certificates listed under Issued Certificates.
After requesting the certificate I restored the CA Database. As you can see in the screenshot, I am missing the certificate that was issued after the backup.
Since, I have the SMTP Exit Module installed on the CA, I know I have a record of the certificate that I issued. So, I check my email to find the serial number of the certificate.
So, next I want to create a certificate with the same serial number. So, I run the following command on the Certification Authority that issued the original certificate:
“certutil –sign <SerialNumber> <CertificateName>” Where <SerialNumber> is the serial number of the original certificate and <CertificateName> is the name I wish to give the certificate.
I then get prompted for the certificate (Private Key) I want to use to sign the certificate with. I choose the CA certificate, and click OK.
After I select the certificate my command completes successfully, as seen below.
Next, I want to import the certificate into the CA’s Database. To do this I run the following command:
“certutil –importcert <CertName>”, where <CertName> is the name of the certificate I created in the previous steps.
As, we see in the screenshot below I now have an additional certificate in Issued Certificates with the serial number of the orphaned certificate.
I then right click on that certificate, select All Tasks, then Revoke Certificate
I choose a reason for the revocation, and click OK.
Next I can run “certutil –crl” on the CA to force the publication of a new CRL. And as you see in the screenshot below the “orphaned” certificate is included in the Revocation List.
If I want to verify the certificate is showing as revoked to clients I can run “certutil –verify –urlfetch <CertName> > <OutputFileName>” to check validation for the certificate.
And when I review the output, I see the certificate is showing as revoked.
In the steps above, I covered how to revoke orphaned certificates. It is important to note that you have to have some way to keep track of issued certificates in order to be able to do this. I have used the SMTP Exit Module to track issued certificates.
I am back to discuss the SMTP Exit Module. The SMTP Exit Module is a very useful monitoring tool, yet so many are unaware of the SMTP Exit Module. In this blog posting I am going to answer the following questions and address the following topics related to the SMTP Exit Module:
Essentially after a certificate or CRL is signed by the CA,, the CA notifies any Exit Modules that are available of this event. Exit Modules then take some action when a certificate or CRL is signed. These can include actions like logging the certificate or CRL to a SQL Database, or sending an email alert. Additional actions that can trigger an exit module include a certificate request being submitted to the CA and awaiting approval, a certificate request being denied by the Certificate Manager, a On Hold revoked certificate being unrevoked, stopping of the Active Directory Certificate Services service, and starting of the Active Directory Certificate Services service. Additional information on Exit Modules are available here: http://technet.microsoft.com/en-us/library/cc783853(v=WS.10).aspx and here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa388214(v=vs.85).aspx.
The SMTP Exit Module sends email alerts. By default it sends email alerts when:
The first reason to use the SMTP Exit Module is for monitoring the actions taking place on the Certification Authority. Even if you don’t monitor the emails in real time, you will have an audit log if you will, in a mailbox.
The second reason is illustrated in the graphic below. In this example the CA is backed up at Time 0. After the backup the CA issues certificates. At Time 1 the CA fails. At Time 2 the CA is recovered from the backup taken at Time 0. The problem here is that after the restore there is no record of certificates issued after the backup, but before the restore. These are known as orphaned certificates. The problem with orphaned certificates is that they are valid, but you have no record of issuing them. And if you have no record of issuing them, you have no way to revoke them if necessary. However, if you have the SMTP module running, you have a list of certificates issued during this time. And although going through a mailbox to determine what certificates you have issued is not the most convenient way to do determine this, at least you have a record. You can also use the information in the email of issued certificates, specifically the Serial Number to revoke these certificates if necessary. I will cover the process for revoking orphaned certificates in an upcoming blog post.
The first step is to copy a batch file that will configure the SMTP Exit Module. The SMTP Exit Module for Windows Server 2003 can be copied from here: http://technet.microsoft.com/en-us/library/cc773129(v=WS.10).aspx. For Windows Server 2008, 2008R2, and 2012 the SMTP Exit Module can be copied from here: http://social.technet.microsoft.com/wiki/contents/articles/2004.active-directory-certificate-services-smtp-exit-module-for-windows-server-2008-r2-example.aspx. I am using the SMTP Module for Windows Server 2008 R2 as an example.
As mentioned on the web page for the Windows Server 2008 R2 Exit Module, you will need to make some modifications to the script before running it.:
Before using the batch file below, ensure that you make appropriate replacements:
http://social.technet.microsoft.com/wiki/contents/articles/2004.active-directory-certificate-services-smtp-exit-module-for-windows-server-2008-r2-example.aspx
Also, if there are some alerts you do not want receive, you can REM them out in EventFilter section of the script.
Once you have configured the script, you can execute it with elevated permissions on the CA to install the SMTP Exit Module.
Once the SMTP Exit Module is installed you can view the settings in the registry. The settings are located at HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ExitModules\CertificateAuthority_MicrosoftDefault.Exit\SMTP
Advanced Configuration of the SMTP Exit Module can be performed by editing the registry.
If you go to the following location in the registry you can edit the SMTP Server, SMTP Authentication Method, and EventFilter: HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ExitModules\CertificateAuthority_MicrosoftDefault.Exit\SMTP
As mentioned in the script the settings for SMTPAuthenticate are:
EventFilter is a bit more complicated. The EventFilter setting is normally configured by the script in this section of the script:
:Setup_CA_For_Exit_Module // Section for turning events on or off. In this case, on. certutil -setreg exit\smtp\eventfilter +EXITEVENT_CRLISSUED certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTDENIED certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTISSUED certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTPENDING certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTUNREVOKED certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTRETRIEVEPENDING certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTREVOKED certutil -setreg exit\smtp\eventfilter +EXITEVENT_SHUTDOWN certutil -setreg exit\smtp\eventfilter +EXITEVENT_STARTUP
Each EventFilter setting has a value associated with it. For example the command certutil -setreg exit\smtp\eventfilter +EXITEVENT_CRLISSUED will set the EventFilter Decimal value to 32, assuming all of the other lines in this section of the script are REM’d out. The command certutil -setreg exit\smtp\eventfilter +EXITEVENT_CERTDENIED will set the EventFilter Decimal Value to 4 assuming all of the other lines in this section of the script are REM’d out. So, if the Decimal value of the EventFilter setting is 36, this would mean both CRLISSUED and CERTDENIED eventfilter is enabled. If all eventfilters are enabled the Decimal value will be set to 511, which the sum of the Decimal values for all of the settings. The table below gives the values for each setting:
The settings for Denied, Issued, Pending, Retrieve Pending, Revoked, and Unrevoked are configured at their corresponding registry key located at:
HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ExitModules\CertificateAuthority_MicrosoftDefault.Exit\SMTP\Templates\Default\
Is used to assign variables to the column rows that are desired to be included in the BodyFormat. A list of database columns is available in this article: http://technet.microsoft.com/library/Cc783853.aspx, under the section titled Schema of the Certificates Database. For example if I wanted to include information from the columns Request.RequestID and SubjectKeyIdentifier I would set the value of this registry setting to:
Request.RequestID SubjectKeyIdentifier
When I configure the BodyFormat setting Request.RequestID would be referenced by a %1 and SubjectKeyIdentifier by a %2. The number increments for each row added in the list.
Includes a list of information that will be included in the email. The variables used here come from the list of database columns listed in the BodyArg registry setting.
This is the SMTP address you wish to have listed in the From field of the email.
Much like BodyArg this setting configures variables that will be used in the TitleFormat setting. The default is SanitizedCAName. Ironically, SanitizedCAName is not a column in the database as far as I am aware.
Includes the text that will be included in the Title of the email. TitleFormat uses variables that are defined in TitleArg setting.
This is the SMTP address you wish to send the email to. If you would like to send the email to multiple recipients you will need to configure a distribution group that includes those recipients. You would then set the To setting to send emails to that distribution group.
CRL issued
Denied Certificate Request
Certificate Issued
Pending Request
Retrieved Certificate
Revoked Certificate
Unrevoked Certificate
Service Shutdown
Service Startup
This blog posting covered installing and configuring the SMTP Exit Module. In my next blog posting I will cover the steps necessary to revoked an orphaned certificate. Below is a video that covers the same material covered in this blog posting.
Shortly after I posted PKI Tip: Certificate Store Shortcuts, Tom Aafloen (@TomAafloen) let me know of another easy way to access the Certificate Stores in Windows 8 & Windows Server 2012.
Step 1. Hold down the Windows key on the keyboard and press the W Key (Windows key + W key) to search settings.
Step 2. Type cer in the search box
And in the results you will see “Manage user certificates”, you can select this if you want to open the Certificates MMC targeted for the current user.
You will also see “Manage computer certificates”, you can select this if you want to open the Certificates MMC targeted for the local machine.
For those that spend time managing certificates I wanted to highlight some shortcuts for certificate management.
For a while now we have been able to directly access the Certificate MMC targeted for the Current User by launching certmgr.msc.
Which opens up the Certificate MMC targeted for the Current User as seen below.
However, until Windows 8 / Windows Server 2012 there has not been an easy way to open up the Certificates MMC targeted for the local computer. In the past you had to perform the following steps:
(Windows 7) Click Start Button, type mmc.exe, press Enter key, in the MMC go to File in the menu bar, Click Add/Remove Snap-in…, select Certificates, click Add, select Computer account, click the Next button, select Local computer, click the Finish button, and then finally click the OK button.
Yeah, a lot of work just to open up the Certificates MMC targeted for the local computer.
In Windows 8 / Windows Server 2012 we just need to do the following:
Type certlm.msc and hit the Enter key.
And Voila, Certificates MMC targeted for the Local Computer!
With some work you can now enable this in down-level clients such as Windows 7.
If you navigate to C:\Windows\System32\ on your Windows 8 machine you will find certlm.msc.
Copy certlm.msc and paste it into C:\Windows\System32 on a Windows 7 machine for example.
Now, when you want to access the Local Computer certificate store through the MMC on your Windows 7 machine, you just have to launch certlm.msc!
There are some effects that CA Certificate Renewal has on OCSP. OCSP provides revocation checking information for clients. For, each CA an OCSP Responder has a Revocation Configuration. Each Revocation Configuration has an OCSP Signing Certificate associated with it. The private key of the OCSP Signing Certificate is used to sign OCSP Responses so that clients can verify the authenticity of those responses.
As explained in the following article: http://technet.microsoft.com/en-us/library/cc754774.aspx
Online Certificate Status Protocol (OCSP) Response Signing certificates need to be signed by the same certification authority (CA) key that was used to sign the end-entity certificates that they provide status for.
After a CA key is renewed, the CA will be using the new key to sign newly issued certificates. In the period between the time a CA certificate is renewed and the expiration date of the original CA certificate, the CA cannot issue or renew OCSP Response Signing certificates, which may prevent an Online Responder from signing OCSP responses.
The solution to this issue is to configure the CA to issue certificates based on information about the issuer in the request. In other words the OCSP Responder normally sends information about the issuer in the request so that the CA can sign the new OCSP Response Signing certificate with the same key pair it was previously signed by. So, we just need to configure the CA to honor these requests. In fact if you have an OCSP Responder setup in your environment, you may have noticed this event in the Application Log:
In order to enable this feature you need to run the following command on the CA and then restart the CA Service: “certutil -setreg ca\UseDefinedCACertInRequest 1”
So, once you run this command your existing Revocation Configuration will be able to properly renew it’s OCSP Signing Certificate, even after the Issuing CA Certificate is renewed. However, if you do need to renew your CA Certificate with a new key pair you do need to setup a new Revocation Configuration to support that new key. Instructions for configuring a Revocation Configuration are available here: http://blogs.technet.com/b/askds/archive/2009/06/29/implementing-an-ocsp-responder-part-iii-configuring-ocsp-for-use-with-enterprise-cas.aspx.
To summarize you will need to perform the following actions to enable your OCSP to support a Issuing CA whose certificate has been renewed with the same key pair:
To illustrate the end result, we can view the original Issuing CA Certificate:
Notice that the Subject Key Identifier matches the Authority Key Identifier in my original OCSP Signing Certificate:
Here is my renewed CA Certificate:
Once I renewed my CA Certificate, configured my CA as mentioned earlier, and configured a new Revocation Configuration you can see that the Subject Key Identifier in the new CA Certificate matches the Authority Key Identifier field in OCSP Signing Certificate for the new Revocation Configuration:
This is my third blog article relating to CA Certificate Renewal. Hopefully, these articles have given you the information you need to understand CA Certificate Lifecycles, the impact of renewing a CA Certificate, and how to successfully renew your CA Certificates with minimal impact to your environment.
Here are links to the previous two articles:
Operating a Windows PKI: Certification Authority Certificate Lifecycle and Renewals
Operating a Windows PKI: Renewing CA Certificates
In the previous blog posting (Operating a Windows PKI: Certification Authority Certificate Lifecycle and Renewals) I covered considerations for the CA Certificates lifecycle and when CA certificates should be renewed. In this blog posting, I am going to cover some additional considerations and walkthrough the process of renewing CA Certificates.
Two important things to remember. If you renew a CA certificate, you are going to have multiple CA certificates, the previous certificate and the renewed certificate. If you renew a CA certificate with a New Key Pair, the CA is going to have to sign multiple CRLs. It will have to sign CRLs with the previous key, assuming that CA certificate is time valid. Also, the CA will need to sign CRLs with the new key pair.
To ensure that the renewal works properties you must have the CRLPublicationURLs registry key configured properly. Specifically, when you configure the CA to publish CRLs or to list an HTTP location in the CDP extension you will want to ensure that the CRLNameSuffix property is defined. For example, below is the post-configuration script for a Root CA:
certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://pki.fourthcoffee.com/certenroll/%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
In this line:
1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl
And this line:
2:http://pki.fourthcoffee.com/certenroll/%%3%%8%%9.crl
You will notice that there is a %%8 before %%9.crl. After these scripts are run the additional % signs will be stripped. The additional % are required for the script since it is a batch file. So, the resulting variable is %8. The variable %8 stands for CRLNameSuffix. This variable will tell the CA to affix an incremental number to CRL files if they are signed by a new key pair. So, the CRL signed by the CAs first key will be named “FourthCoffee Root Certification Authority.crl”. The CRL signed by the second key will be named “FourthCoffee Root Certification Authority(1).crl, and so on.
In rare circumstances you may want to change how long CA Certificates are valid for, when renewing the CA certificate. So, let’s use the example of a two tier PKI hierarchy. If you want to modify the validity period for the subordinate/issuing CA, you will have to modify the ValidityPeriodUnits and ValidityPeriod settings on the Root CA. These two registry settings will determine for how long the Root CA issues certificates. Validity PeriodUnits is set to a number and ValidityPeriod is set to a measurement of time. For example, if ValidityPeriodUnits is set to “10”, and ValidityPeriod is set to “Years” the Root CA will issue certificates that are valid for 10 years. Both of these settings are located in the registry at HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\. Optionally, the registry can be configured with the “certutil –setreg” command.
To change the Validity Period for the Root CA you can configure a CAPolicy.inf. To create a CAPolicy.inf file that changes the lifietime of the certificate to 30 years, you would type the following into a text file, and save it with the name CAPolicy.inf in the C:\Windows directory,:
[Version] Signature= "$Windows NT$"
[Certsrv_Server] RenewalValidityPeriod=Years RenewalValidityPeriodUnits=30
Then you would renew the CA certificate.
However, I have not been able to alter the resulting CA certificates lifetime using this method. I have, only tested this with Windows Server 2012. It is my understanding that his has worked in previous versions of the OS but have not been able to verify. Additional information on the CAPolicy.inf file is available here: http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx
The following steps can be taken to change the Key Size for a renewed CA certificate. First, it should be noted that if you are changing the key size, you are changing the key. Therefore, to increase the Key Size you will need to renew the CA certificate with a new key pair.
The first step is to create a CAPolicy.inf file on the CA for which you wish to increase the Key Size. The format of the file, is as follows:
[Certsrv_Server] RenewalKeyLength=4096
You can change the RenewalKeyLength to the size of the key desired.
Next, you will renew the CA certificate with a new key pair. Instructions for CA Certificate renewal, will be covered later in the article.
I have had one situation where a customer wanted to change the Hash Algorithm for a CA Certificate. The customer had installed an Issuing CA. The Issuing CA’s certificate used SHA-256 as the hash algorithm. The customer wanted to change the hash algorithm to the less secure, but more compatible SHA1. Assuming, a two-tier hierarchy, you can change the Hash Algorithm in the CA certificate on either the Root or Issuing CA by modifying the following registry key HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\CSP\HashAlgorithm on the Root CA and then renewing either the Issuing or Root CA, depending on which one for which you are changing the Hash Algorithm.
The customer I was working with had the Hashing Algorithm on the Issuing CA set to SHA-256. So, we changed the HashAlgorithm registry key on the Root CA from “SHA256” to “SHA1”.
The video below covers the steps required to renew a Root CA Certificate.
The video below covers the steps required to renew a Root CA Certificate
You should now have the information and steps you need to understand CA Certificates Lifecycle and how to renew CA Certificates.
Certification Authority Certificate Lifecycle and Renewals
In this blog post I am going to discuss managing the Lifecycle for CA Certificates as well as cover the actual process to renew CA Certificates.
If an organization is looking to deploy a new PKI, we usually first discuss the type of overall design in terms of hierarchy. There are typically 3 types of hierarchies that we see deployed. There is the Single Tier PKI Hierarchy which consists of a single CA that is both a Root and Issuing CA. There are several drawbacks with a Single Tier Hierarchy including the fact that it is not a very secure or scalable solution. Then there is a Two Tier PKI Hierarchy. A Two Tier PKI Hierarchy is a more secure solution since the Root CA is kept offline, which prevents it from being compromised via the network. A Two Tier Hierarchy also is much more scalable since you can always add additional Issuing CAs to the hierarchy to meet the organization’s needs. There is also a Three Tier Hierarchy. A Three Tier hierarchy is typically used in very large organizations that either require a more complex solution or need the 3 tiers to meet some security objective.
Typically a Two Tier hierarchy meets most organizations needs in terms of both security and scalability. So, for the remainder of this blog posting I will be discussing certificate lifetimes in relation to a Two Tier PKI Hierarchy. Once a customer has decided the overall type of design, we then start to discuss the various configuration options for the Certification Authorities. One of those discussions is around the lifetime of the CA Certificates and RSA key pairs. When discussing these lifetime there are several things to take in to consideration. Typically, I discuss the certificate lifetimes based on a “bottom to top” approach. My first question typically is: How long of a lifetime do you plan on issuing end-entity certificates for? A lot of organizations are familiar with getting 1 year or 2 year certificates from a 3rd party CA. So, most customers typically plan on issuing end-entity certs for 2 years. If you are pretty comfortable with issuing certificates for 1 or 2 years that does have some implication for the lifetimes of the CA certificates and RSA key pairs.
The implication for CA certificate lifetimes and RSA key pairs is around enrollment. If you are going to want to issue certificates for either 1 or 2 years, you will most likely want to have your Issuing CA be valid for at least double that period of time. So, this would lead to a discussion on potentially have either a 4 or 5 year lifetime for the Issuing CA Certificate and RSA key pairs. So, why should the lifetime of the CA certificate be twice the lifetime of the issued certificates? Well, the answer it turns out is pretty simple. An Issuing CA cannot issue certificates that are valid for longer than its own lifetime.
So, based on this information we know that the Issuing CA will need to have at least a lifetime of 2 years if we are issuing two year certs. However, if you make the CA only valid for 2 years you will only be able to issue 2 year certs on the first day that the Issuing CA is created. This is because on the following day the CAs certificate lifetime will be 1 day short of two years. So, at this point you would only be able to issue certs that are valid for 1 day short of 2 years. So, in this scenario as the CAs lifetime gets shorter and shorter the validity period of issued certificates gets shorter as well.
So, in order to give the CA a long enough validity period to actually be useful we typically make the Issuing CAs cert valid for at least twice the lifetime of issued certificates. Using the same example of issuing 1 and 2 year certificates we can clearly see that making the CA certificate valid for 4 or 5 years will give us a decent amount of time before the CA certificate needs to be renewed. However, you will still eventually run into the situation as described above, where the CA can no longer issue certificates for the full intended lifecycle. So, how do we handle this? What we do? The answer shortly.
When having the discussion around CA certificate lifetimes one of the other questions I have is: Are there situations that may come up where you may have the need to issue certificates for more than 2 years? And it turns out for a lot of organizations there are situations where issuing 3, 4, or even 5 year end-entity certificates make sense. These situations typically involve devices that require a great deal of administrative effort to both request a certificate and then install the certificate once it is issued. Some examples are non-domain joined Windows machines, network appliances, laptops or mobile devices for remote workers. In many situations, organizations may either not have the staffing to replace certificates on these devices every 1 or 2 years, or may not find it financially feasible to do so. In these types of situations you may increase the lifetime of end-entity certificates to reduce the administrative or financial burden that comes with replacing these certificates more often.
If you are going to issue certificates let’s say that are valid for up to 5 years, again you need to consider implementing a CAs whose certificates lifetime is twice or more than twice the lifetime of issued certificates. This design typically forces organizations to consider having Issuing CAs whose certificate validity period is 10 Years. So, now that an organization has decided that it’s issuing CA certificate is going to be valid for 10 years, what about the Root CA? Well for pretty much the same reason as discussed previously the Root CAs certificate validity period is going to be at least twice that of the Issuing CA. This usually leads to the decision to have a Root CA, whose certificate is valid for a period of 20 years.
Let’s continue to use the scenario of have a Root CA valid for 20 Years, an Issuing CA valid for 10 years, and issuing end-entity certificates that have a validity period for up to 5 years. So, once my Issuing CA certificate exceeds 5 years in age, I am going to run into the issue where I am no longer able to issue 5 year certificates. How do we handle this situation? In order to provide adequate lifetime for the CA to issue full term certificates, we renew the Issuing CA certificate at it’s half-life.
Below is a graphic that illustrates the CA Certificate Lifecycle (click graphic to expand):
So, remember this example outlined in the graphic above is of a Two Tier PKI Hierarchy with an Offline Root CA, and an Issuing CA. Below is the timing of the CA Certificate Renewals:
The purpose of his blog posting was to give a better understanding of when CA Certificates are renewed and why. In my next posting, I will cover some additional considerations for CA Certificate Renewal and cover the steps necessary to renew a CA Certificate.
Today, I am going to discuss removing expired certificates from the CA database. Every time a CA issues a certificate it also stores a copy of the issued certificate in the CA database. Overtime the certificates that the CA issues expire. Once the certificate expires it is no longer valid. Therefore, once a certificate expires you can safely remove it from the CA database. The one exception to this is if have Key Archival configured on the CA. If you are archiving private keys, you may not want to remove expired CA certificates from the CA database.
Important Note: You should backup the CA including the database and log files prior to deleting any certificates from the database.
Today’s current date is 5/10/2012, and you can see in the screenshot below that I have several issued certificates that are expired.
So, to remove the expired certificates from the CA Database I can run the following command:
certutil –deleterow certs 5/10/2012
As you can see in the screenshot below, 16 rows were deleted.
Now, if I look at the Issued Certificates container in the Certification Authority management console I see that my expired certificates are no longer there.
Note: The certutil command listed above will only delete ~3000 certificates at a time. So, if you have a lot of expired certificates you will have to rerun the command several times.
Also, if you want to delete any failed or pending requests that were submitted prior to the current day you can use the following command:
certutil –deleterow <today’s date in mm/dd/yyyy format> request
So, I covered the steps for removing expired certificates from the CA database. I also covered removing pending and failed requests from the CA database.
I am looking for a list of topics to cover in future blog postings. So, if you have a topic you would like me to cover, please submit a comment or contact me at @chdelay on Twitter.
In my customer engagements I get a lot of questions around what tasks an organization should be doing in terms of operation and maintenance for their PKI. So, in this blog series I am going to cover the operational and maintenance aspects of a PKI.
Below is the list of topics I plan on covering in this Blog Series:
If there are any additional topics you would like me to cover, please submit a comment to this blog posting or tweet me @chdelay.
I currently have a Windows Phone 8 device, specifically the HTC 8X. One the features in this phone is Near Field Communications (NFC). I had heard a lot about NFC so I wanted to try it out. So, I bought some NFC tags from Amazon. I found the tags by searching for windows phone 8 nfc tags on Amazon. It cost me about $10 for 5 tags. Below is a picture of the NFC tags:
In order to use the tags I downloaded NFC Launchit from the Windows Phone Store. NFC Launchit lets you launch applications and perform actions when you tap your phone a NFC tag.
So, I opened NFC Launchit.
After the application opened, I tapped on Start.
I wanted to configure or write to the NFC tag so that when I tapped it, my phone would launch my blog website. So, I selected Launch website, from System Apps.
I then entered the URL of my blog which is http://blogs.technet.com/b/xdot509/, and tapped on the check mark.
Next, I held my phone up against the tag to write this information to the NFC tag.
Once the tag was written to, I was presented with the following screen.
So next, I wanted to test the tag and NFC Launchit. So, I tapped my phone against the tag, and was prompted on whether I wanted to receive content, and I tapped accept.
And as expected Internet Explore launched and navigated to my blog. I stuck the NFC tag to my laptop, and now anytime I want to open my blog I just have to tap my phone against the tag and tap accept.
This video is Part 3 in a 4 part video series on the steps required to upgrade an existing PKI from Windows Server 2003 to Windows Server 2012. Although the steps demonstrated cover upgrading Windows Server 2003, the same steps could be used to upgrade Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012. This video covers the steps required to backup a Subordinate Enterprise CA and then decommission that CA in preparation for the migration.
If you have difficulties viewing this video, you can also view it here: http://www.youtube.com/watch?v=ox61aZXACHQ
This video is Part 2 in a 4 part video series on the steps required to upgrade an existing PKI from Windows Server 2003 to Windows Server 2012. Although the steps demonstrated cover upgrading Windows Server 2003, the same steps could be used to upgrade Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012. This video covers the steps required to complete the migration of the Root CA.
If you have any issues with viewing the video on this website, it can also be viewed here: http://www.youtube.com/watch?v=2bkcM135kho
This video is Part 1 in a 4 part video series on the steps required to upgrade an existing PKI from Windows Server 2003 to Windows Server 2012. Although the steps demonstrated cover upgrading Windows Server 2003, the same steps could be used to upgrade Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012. This video covers the steps to backup an existing Root CA, which is the first step in the migration.
If you have any issues with viewing the video on this website, it can also be viewed here: http://www.youtube.com/watch?v=wdyCPF3gOJc