Step 1: First give the NDES Server Read and Enroll permission to the CEP Encryption Certificate Template.

Step 2: Open the certificates MMC targeted to the computer. Expand Personal. Right-click on Certificates. From the context menu select All Tasks then Renew Certificate with New Key…

Step 3: On the Before You Begin page of the wizard, click Next.

Step 4: On the Request Certificates page, click Enroll.

Step 5: On the final page of the wizard, click Finish.

Step 6: Open Certmgr.msc as a user that has Read and Enroll permissions to the Exchange Enrollment Certificate Template. Expand Personal, right click on Certificates. Select All Tasks, and then Request New Certificate…

Step 7: On the Before You Begin page, click Next.

Step 8: On the Select Certificate Enrollment Policy page, click Next.

Step 9: Select the Exchange Enrollment Agent certificate template, and click the More information is required to enroll for this certificate. Click here to configure settings. link.

You will want to user the same Subject Name that is in your current Exchange Enrollment certificate. The following steps illustrate the steps needed to do this. You can find the current subject name by opening the Certificates MMC targeted to the local machine and then open the existing Exchange Enrollment Agent certificate. In my example the name was CN=FCNDES01-MSCEP-RA,C=US.

Step 10: Under Subject Name ensure that Common Name is selected and under Value enter the common name that is in your existing certificate. Then click Add.

Step 11: Change the Type to Country and under Type the country code that is your existing Exchange Enrollment Agent certificate.

Step 12: Click Add

Step 13: On the Private Key tab, select Make private key exportable. Then click OK.

Step 14: Then click Enroll.

Step 15: Right-click on the Exchange Enrollment certificate in the users personal store. Select Export…

Step 16: When the Certificate Export Wizard opens, click Next.

Step 17: On the Export Private Key page, select Yes, export the private key.

Step 18: On the Export File Format page, select Personal Information Exchange – PKCS #12 (.PFX)

Step 19: On the Password page, enter a password and click Next.

Step 20: On the File to Export page, click the Browse… button. Select the file name and save location. When finished click Next.

Step 21: n the final page of the wizard, click Finish.

Step 22: Then click OK.

Step 23: In the Certificate MMC on the NDES Server that is targeted to the computer, expand Personal. Right-click on Certificates. From the context menu, select All Tasks and then Import…

Step 24: On the Welcome page, click Next.

Step 25: Browse to the PFX file you previously created, and click Next.

Step 26: On the Password page, enter the password associated with the PFX file.

Step 27: On the Certificate Store page, click Next.

Step 28: On the final page of the wizard, click Finish.

Step 29: Then click OK.

Step 30: In the Certificate MMC on the NDES Server that is targeted to the computer, expand Personal. Right-click on the old Exchange Enrollment certificate, and select Delete.

Step 31: Then click Yes, to accept the deletion.

Step 32: Right click on the new Exchange Enrollment certificate. From the context menu, select All Tasks then Manage Private Keys…

Step 33: Add the NDES service account and ensure that it just has Read permission. Click OK.

Step 34: Right click on the new CEP Encryption certificate. From the context menu, select All Tasks then Manage Private Keys…

Step 35: Add the NDES service account and ensure that it just has Read permission. Click OK.

Step 36: Reset IIS using iisreset command.

Have a Happy New Year!!!

-Chris

I had previously published this information to  my blog and accidently removed it from here.  Re-adding the posting.  I hope to find time to update this for Windows 10 in the future. Windows 10 has a feature named Credential Guard which greatly increases the security of credentials and help limits their exposure. This blog posting covers one possible way that Administrator Workstations could be configured to reduce the attack surface for Administrator Accounts.  If you would like assistance with this Microsoft Consulting Services has a service named Privileged Administrator Workstation, where they can assist you with implementing Administrator Workstations. Their service is much more detailed and comprehensive then what I have provided here.  The instructions here are just taking Microsoft’s PtH recommendations and showing how they could be implemented.

Definitions

Productivity Workstation: Workstation used by a user to check email, access the internet, view and edit documents. This workstation is less trusted since it has a larger attack surface and is extremely susceptible to compromise.

Administrator Workstation: A workstation used solely for systems administration. This workstation is very trusted since it is locked down, reducing the overall attack surface and making less susceptible to compromise.

Background

To help secure environments against Credential Theft attacks and to prevent escalation the following conceptual model should be used to help understand how the environment should be secured.

In order to protect credentials, especially those of privileged accounts the following rules should be followed:

· A user should never logon to a system that is in a lower tier. (For example a Domain Administrator should not login to a server or a non-administrator workstation with their credentials.)

· A tier 0 principal should not be accessed by an account or service that is in a lower tier. (For example the same WSUS server that patches all infrastructure servers should not be the same one that patches Domain Controllers.)

Administrator Workstations

Users who will be logging in with accounts that will be members of privileged groups should have a dedicated workstation for administration.

When these types of users perform both administration and productivity work from the same workstation it increases the likelihood of their credentials being compromised. This is due to the increased exposure due to opening documents, reading email, or browsing the web all of which are pathways for malware or an adversary to gain a foothold on a workstation.

Exposure of credentials

Even if an administrator is logged on to workstation with a non-admin account, their admin credentials can be exposed if the use the “Run As” functionality and use their admin credentials.

If an administrator uses RDP to manage servers or domain controllers with a privileged account, their password can be exposed if there is malware on the system running a keystroke logger.

Cost of exposure

If a highly privileged account such as domain administrator or enterprise administrator is compromised it is an extremely costly compromise. In some cases this may result in the organization having to build an entirely new forest, since the existing forest can no longer be trusted. In the best case scenario the organization will have to spend several months having all systems reviewed by a forensic team to try to rid systems of malware or an adversary that has established a foothold. Although the cost of a second laptop for an administrator can be costly, that cost pales in comparison to having to rebuild an entire forest. Having a dedicated workstation for administrators is a fundamental mitigation that should be in place and if it is not in place reduces the effectiveness of other mitigation that are put in place to protect administrator credentials.

Options for Administrator Workstation

Option 1: Dedicated Hardware

Advantages:

A dedicated laptop used exclusively for performing administration is the most secure option. This is due to the fact that the administrators credentials are completely isolated. As with all administrator workstations.

Since a user has a dedicated productivity machine they are allowed to have greater control and will be able to use USB storage, add drivers, and have greater control over the environment.

Disadvantages:

Requires the user having two machines.

Option 2: Physical Machine for Administrator Workstation with VM for Productivity Workstation.

Advantages: The advantage of this configuration is it isolates the productivity workstation from the administrator workstation using a hypervisor. This allows a single physical machine to be used for both an administrator workstation and productivity workstation.

Additional Information: One question that may be posed is “Can the Physical Machine be the Productivity Workstation and the VM be the Administrator Workstation?”. The answer to this question is: No. The Productivity Workstation is a Tier 2 Workstation and the Administrator Workstation is a Tier 0 Workstation. If the physical machine is a Productivity Workstation and the VM is a Administrator Workstation, you then have a Tier 2 workstation managing a Tier 0 workstation. And from the previous rules we know that a lower tier should not be able to manage a higher tier. This is because if the physical machine was compromised it would have control over the VM, be able to overlay fake images over the VM, modify the VM configuration, add files to the VM image, and capture keystrokes through the physical machine.

Disadvantages:

Since the laptop is the Administrator Workstation it is very locked down. That means that the user has little control over the machine, including using USB storage and adding device drivers. This means the user must compromise on the usefulness of the laptop in exchange for carrying one machine.

Hardening Requirements for Administrator Workstation

In order to ensure the integrity of the Administrator Workstation there is configuration that needs to be enforced. The following is a list of those configuration items.

· The administrator using the Administrator Workstation cannot have administrator level access to the OS on the Administrator Workstation. This must be enforced to prevent the administrator from bypassing security configuration on the workstation.

· Latest Operating System- Each iteration of the Windows Operating System adds additional features to mitigate known attacks, additional there are security features added to each OS that increase the ability to further secure the OS through proper configuration. To ensure the security of the Administrator workstation the latest Operating System should be installed. The latest Operating System is Windows 8.1.

· Secure Boot- Protects the Operating System by preventing the loading of unsigned code during the boot up process

· AppLocker- Application Whitelisting should be implemented so that only approved applications can be run on the Administrator Workstation.

· BitLocker- Whole volume encryption should be implemented to secure the device in case of loss or theft.

· USB Restrictions- The Administrator Workstation should be prevented from using USB storage to prevent infection or compromise via malware on a USB device.

· Internet Restrictions- The Administrator Workstation should be make incapable of accessing the internet. This restriction can be implement by configuring the browser to point to a “black hole” proxy. Alternatively, the organizations proxy server can be configured to block outbound connections on connections imitated by an administrator account.

· Network Isolation- Windows Firewall should be enabled and configured to block incoming connections.

· Antimalware- Antimalware also known as Antivirus should be installed on the Administrator Workstation and kept current with signatures.

· Exploitation Mitigation- EMET should be installed to mitigate common methods that malware and adversaries use to run code on the system.

· Attack Surface Analysis- During the build of the Administrator Workstation a tool such as Attack Surface Analyzer should be run to determine the attack surface are of the deployment.

· Imaging- A Golden Image should be produced of the Administrator Workstation and should be kept up to date. In the event of a potential exposure the machine can quickly be wiped and rebuilt.

Restricting Administrator Access

Below are instructions to demonstrate how restricted groups can be used to control members of the Local Administrators Group.

Step 1: Open GPMC.msc

Step 2: Right click on the OU that contains Administrator Workstations and select Create a GPO in this domain and Link it here…

Step 3: Give the GPO a name and click OK

Step 4: Right click on the new GPO and select Edit… from the context menu

Step 5: Navigate to \Computer Configuration\Policies\Windows Settings\Restricted Groups

Step 6: Right click on Restricted Groups and select Add Group… from the context menu

Step 7: In the Add Group dialog box enter .\Administrators and click OK

Step 8: A new Window will open. Under the Members of this group section and users or groups that should be Local Administrators. Be sure to exclude the users of the Administrator Workstation. Click OK when finished.

The resulting GPO should look something like the example below.

Current Operating System

Windows 8.1 should be installed as the operating system on the Administrator Workstation.

Windows 8.1 includes all of the security features of Windows 7 along with the additional security functionality available in Windows 8.1. Below are some of the key security features that help add additional security to privileged users.

Secure Boot

Secure Boot prevents unsigned code from being run during the boot process. This prevents attackers from loading attack tools or malware during boot.

Trusted Boot

Early-Launch Anti-Malware (ELAM) is run early in the boot process and is used to prevent malware from launching prior to the Operating System.

Virtual Smart Cards

The Trusted Platform Module is used to securely store a certificate that is used for Smart Card Logon. The user must enter a PIN to use the Virtual Smart Card. So a user must have possession of the device as well as knowledge of the PIN to perform a Smart Card Logon with a Virtual Smart Card.

Protected Groups

· Protected Groups add the following protections: The member of the Protected Users group cannot authenticate by using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8.1, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.

· The Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. This means that the domain must be configured to support at least the AES cipher suite.

· The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.

· The default Kerberos Ticket Granting Tickets (TGTs) lifetime setting of four hours is configurable by using Authentication Policies and Silos, which can be accessed through the Active Directory Administrative Center (ADAC). This means that when four hours has passed, the user must authenticate again.

Restricted Admin Mode for RDP

This allows an administrator to RDP to another system without exposing their credentials to that system

Secure Boot

Secure boot requires firmware that is at UEFI version 2.3.1 or greater. Secure Boot must be enabled in the BIOS. Contact your PC vendor to get instruction on how to enable Secure Boot on your particular model. Below is an example of a BIOS Setup screen where Secure Boot is enabled.

(Photo from http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx)

AppLocker

AppLocker is an Application Control feature in Windows 7 and Windows 8. AppLocker is used to control which applications a user can run. This control over what applications can run, reduces the chance of a user accidentally running malware or other software that can leave a system exposed. In terms of the Administrator Workstation it is used for “Application Whitelisting”. The first step in Application Whitelisting is to determine what applications the user should be allowed to run. So, first you will want to inventory what applications an Administrator users. Productivity software and alternate web browsers should not be allowed to run on the Administrator Workstation.

Once you have the applications that should be whitelisted you can use the following steps to create a GPO to enforce the AppLocker settings.

First we you will need a reference machine to create your settings on. On the reference machine you should have Windows 8.1 installed, along with any applications that you have chosen to whitelist. You will also need the RSAT installed unless you plan on importing the policy into group policy on another machine. The RSAT tools can be downloaded from here: http://www.microsoft.com/en-us/download/details.aspx?id=39296.

Step 1: Launch the Local Group Policy Editor (gpedit.msc) on the reference machine.

Step 2: Navigate to \Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker

Step 3: Click on Configure rule enforcement

Step 4: Under Executable rules, select Configured and choose Enforce Rules, then click OK. This step enables rule enforcement for executable files such .exe.

Step 5: Right click on Executable Rules and select Create Default Rules from the context menu.

Step 6: The Default rules creates 3 rules:

· Allow Everyone to run All files located in the Program Files folder

· Allow Everyone to run All files located in the Windows folder

· Allow Builtin Administrator to run All files

The rule that allows Everyone to run All files located in the Program Files folder should be deleted, so that you have greater control over what programs the user can run. Do not delete the other two rules. Deleting these rules can cause the user to be incapable of logging in.

Step 7: When prompted about deleting the rule, click Yes

Step 8: Right click on Executable Rules, and select Create New Rule… from the context menu

Step 9: Check Skip this page by default, and click Next

Step 10: Select Allow. Select a group or user that will be using the Administrator Workstation and click Next.

Step 11: Select Publisher and click Next.

Step 12: Check, Use Custom Values and next to the File Version select Exactly from the Drop Down menu.

Step 13: Click Next

Step 14: Click Create

Follow Steps 10-14 for each application that needs to be whitelisted.

Step 15: In the Group Policy Editor, right click on AppLocker, and select Export Policy… from the context menu.

Step 16: Give the Policy File a name and click Save

Step 17: When prompted that the rules were exported, click OK.

Step 18: Open Group Policy Management (GPMC.msc). On the OU that contains the Administrator Workstations, right click and select Create a GPO in this domain, and Link it here…

Step 19: When prompted, give a name for the GPO and click OK

Step 20: Right click on the newly create GPO and select Edit

The Application Identity Service must be running for Applocker to function so we will enable it through Group Policy.

Step 21: Navigate to \Computer Configuration\Policies\Windows Settings\Security Settings\System Services.

Step 22: Double click on Application Identity

Step 23: Select Define this policy setting and then select Automatic , and then click OK

The Services should now show up as Automatic

Now we are going to import the previously created policy.

Step 24: Navigate to \Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker

Step 25: Right click on AppLocker

Step 26: Select Import Policy… from the context menu

Step 27: Navigate to the Policy File you created in step sixteen, and click Open

Step 28: When prompted if you want to import the policy, click Yes

Step 29: When prompted that the rules were imported, click OK

Internet Restrictions

Internet Access on the Administrator Workstation should be blocked. The steps below demonstrate how internet access can be blocked with a GPO. These instructions assume there are no other web browsers other then Internet Explorer installed on the system.

Step 1: Right click on the OU that contains Administrator Workstations, and select Create a GPO in this domain, and Link it here…

Step 2: Type a name for the new GPO and click OK

Step 3: Right click on the newly created GPO and select Edit from the context menu

Step 4: Navigate to \Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\

Step 5: Open Prevent changing proxy settings and click OK

Step 6: Open the setting Disable changing Automatic Configuration settings, select Enabled, and then click OK

Step 7: Open the setting Make proxy settings per-machine (rather than per-user) select Enabled and click OK.

Step 8: Open Disable changing connection settings, select Enabled, and click OK

Step 9: Navigate to \Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel

Step 10: Open the setting Disable the Connections page, select Enabled, and click OK

Step 11: Create a new Group Policy that is linked to the OU that contains Administrator accounts.

Step 12: Navigate to \User Configuration\Preferences\Internet Settings

Step 13: Right click on Internet Settings, select New and then Internet Explorer 10 from the context menu

Step 14: Navigate to the Connections Tab, and click LAN Settings

Step 15: Select Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections), under Address enter 127.0.0.1, for Port enter 80, and ensure that Bypass proxy server for local addresses is selected. Make sure everything has a green underline, if not toggle the F5 and F8 keys until it turns green. Click OK.

Step 16: Close the Group Policy Editor.

USB Restrictions

Malware is often spread via Removable Storage. Therefore it is important that Removable Storage cannot be used with the Administrator Workstation. Below are steps to lock down Removable Storage on the Administrator Workstation.

Step 1: Open the Group Policy Management Console.

Step 2: Right click on the OU that contains the Administrator Workstation, and click on Create a GPO in this domain, and Link it here…

Step 3: Enter a name for the newly created GPO, and click OK

Step 4: Right click on the newly created GPO, and select Edit

Step 5: Navigate \Computer Configuration\Administrative Templates\System\Removable Storage Access and open the setting All Removable Storage classes: Deny all access

Step 6: Select Enabled, and click OK

BitLocker

BitLocker Drive Encryption should be enabled on the Administrator Workstation to secure the machine in case it is lost or stolen. The following steps illustrate how to configure BitLocker securely. The following instructions do not able the ability to recover BitLocker with a Recovery Key. If the administrator is unable to boot, the machine should be considered compromised, and rebuild from known good media.

Step 1: Right click on the OU that contains the Administrator Workstation, and click on Create a GPO in this domain, and Link it here…

Step 2: Enter a name for the newly created GPO, and click OK

Step 3: Right click on the newly created GPO, and select Edit

Step 4: Navigate to \Computer Configuration\Windows Components\Bit locker Drive Encryption\Operating System Drives

Step 5: Open the setting Require additional authentication at startup, select Enabled, and click OK

Step 6: Open the setting Allow enhanced PINs for startup, select Enabled, and click OK

Step 7: Open Configure minimum PIN length for startup, select Enabled, and click OK

Step 8: Open the setting Enforce drive encryption type on operating system drives, select Enabled, and click OK

Step 9: Select the setting Choose how BitLocker-protected operating system drives can be recovered, select Disabled, and click OK

Step 10: Navigate to \Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption

Step 11: Open the setting Choose drive encryption method and cipher strength, select Enabled, and click OK

Network Isolation

The Windows Firewall should be enabled to protect the Administrator Workstation from Network Attacks. The following instructions cover how to create a Group Policy to configure the Windows Firewall for Administrator Workstations.

Step 1: Right click on the OU that contains the Administrator Workstation, select Create a GPO in this domain, and Link it here…

Step 2: Enter a name for the New Group Policy, and click OK

Step 3: Right click on the newly created GPO and select Edit

Step 4: Navigate to \Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\

Step 5: Right click on Windows Firewall with Advanced Security, and select Properties

Step 6: Configure the settings as defined below:

Firewall state: On (recommended)

Inbound connections: Block (default)

Outbound connections: Allow (default)

Step 7: Then under Settings, click Customize…

Step 8: Change Apply local firewall rules to No

Step 9: Change Apply local connection security rules to No

Step 10: Click OK

Step 11: Repeat Steps 6 – 10 for each Profile. When finished, click OK.

The resulting setting should look similar to those in the screenshot below:

Hashing Algorithms

Hashing Algorithms take variable input and provide a unique fixed length output. Hashing algorithms have a number of desired properties. Those desired properties include that the hash should not be able to be reversed to determine the data that was inputted into the hash. Also, it should not be possible to produce collisions. A collision is when two separate inputs into a hash algorithm produce the same hash.

How a Digital Signature is created

To produce a digital signature data that is going to be signed is passed through a hash algorithm to create a hash.

The resulting hash is encrypted with key. That key is the private key that is part of a private/public key pair. The private key is held securely by the signer and the public key is widely distributed in the form of an X.509 certificate.

The result of the encrypted hash is a digital signature

Verifying a digital signature

To verify a digital signature, the verifier must first retrieve or possess a copy of the signer’s certificate. This certificate includes the public key of the signer.

The verifier must also have a copy of the data or document that was signed. The verifier also must have knowledge of what hash algorithm and what asymmetric cryptographic algorithm were used to create the signature. Information on what algorithms were used for the signature are usually contained in the metadata of the signature. And finally, the verifier must also have a copy of the signature.

The verifier runs the document or data through the same hashing algorithm as the signer. The verifier then decrypts the digital signature with the signer’s public key. The result of the decryption is the hash that was created by the signer. That hash is compared to the hash generated by the verifier. If the hashes match the verifier now knows two things. First, the verifier knows that the data has not been modified since signed by the signer. Second, since the public key decrypted a matching hash, the verifier knows that the document or data was signed with the corresponding private key and thus knows that the identity associated with the signer via the certificate is actually the signer of the data or document.

Impact of Collisions on Certificates

Certificates are digitally signed data, signed by a Certification Authority. If the signature is determined valid using the Certification Authorities public key, then that certificate is understood to have been issued by that Certification Authority assuming information used for chain building also regard that CA as the issuer.

There is a significant problem that is caused if collisions can be created for the hash algorithm that is used to sign a certificate. The issue arises because it provides an opportunity for an adversary to create fraudulent certificates. If an adversary can create a fraudulent certificate whose hash is the same as another certificate, then the adversary can use the signature from another non-fraudulent certificate on the fraudulent certificate. This allows an adversary to create certificates that have the same chain of trust as those signed by that CA. This is the reason that as hashing algorithms become considered broken in the sense that collisions can be created, that they must stop being used in the certificate signing process.

Attacks against SHA1

Example of a current attack against SHA1: https://eprint.iacr.org/2015/967

SHA1 Deprecation

Microsoft SHA1 Deprecation Policy as of 11/26/2015

Public Key Infrastructure’s whose Root CA certificates are installed in the Windows OS through the Microsoft Root Certificate Program will no longer be allowed to issue SSL and Code Signing certificates that are signed using the SHA1 hashing algorithm. This policy will effect certificates that are issued as of January 1, 2016. The official policy can be viewed here: https://technet.microsoft.com/en-us/library/security/2880823.aspx

3^rd Party SHA1 Policies

Google: Gradually sunsetting SHA-1 (https://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html)

Mozilla: Phasing Out Certificates with SHA-1 based Signature Algorithms (https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/)

SHA2

Beginning with Windows Server 2008, Windows began supporting Suite-B cryptographic protocols. This support of Suite-B cryptographic protocols includes the support of the SHA2 hashing algorithm. Specifically, SHA256, SHA384, and SHA512 are supported by Windows. Typically, when choosing a SHA2 hashing algorithm SHA256 is selected. I have not run into compatibility issues with SHA384 or SHA512. However, it is more likely that SHA256 would be supported in 3^rd party software then SHA384 or SHA512. Also, it is a common practice by 3^rdparty Certification Authorities to issue certificates signed using the SHA256 hashing algorithm.

Reconfiguring a PKI to use SHA2 instead of SHA1

The steps below will illustrate how one can reconfigure their PKI so that the CA certificates are signed with the SHA2 hashing algorithm and certificates issued by the PKI are signed using the SHA2 hashing algorithm. This walkthrough is an example of how this can be accomplished on a Two Tier PKI. If you are going to perform these steps in a production environment you should first backup your existing PKI. It is also recommended that you engage Premier Field Engineering, Microsoft Support, or Microsoft Consulting Services if you are performing these steps in a Production Environment. One last note of caution, you should first run through these steps in a pre-production environment to ensure you get the proper results.

Reconfiguring the Root CA

In the following steps I will show the steps used to reconfigure the Root CA to issue certificates signed using the SHA256 hashing algorithm.

The screenshot below shows the current Root CA certificate in my test lab and the fact that the hashing algorithm is SHA1.

Step 1: Open the registry editor

Step 2: Navigate to HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\CSP

Step 3: Open the registry setting CNGHashAlgorithm

Step 4: Replace Value data with SHA256

Step 5: Click OK

Step 6: Restart the Active Directory Services service. One way to do this is to open an elevated command prompt and run the following command to stop the service: net stop certsvc, and then run the following command to start the service: net start certsvc.

Renewing the Root CA Certificate

In the following steps I will show how the Root CA certificate can be renewed. Since, I reconfigured might Root CA to issue certificates signed using the SHA256 hashing algorithm, the resulting certificate will be signed with this hashing algorithm.

Step 1: Open the Certification Authority MMC (certsrv.msc)

Step 2: Right-click on the CA Name

Step 3: Select All Tasks and then Renew CA Certificate…from the context menu

Step 4: When prompted to stop the Active Directory Certificate Services service, click Yes

Step 5: When prompted to Renew CA Certificate, click OK. Note: If you do not want to renew the CA certificate with a new key pair, select No and then click OK.

Verifying the certificate

To verify that the certificate has been renewed and signed using the SHA256 hashing algorithm, perform the following steps:

Step 1: Open the Certification Authority MMC (certsrv.msc)

Step 2: Right-click on the CA Name and select Propertiesfrom the context menu.

Step 3: Select the newest certificate in the list, which will be the last one in the list.

Step 4: Click View Certificates

Step 5: When the Certificate opens, click on the Detailstab

Verify Signature hash algorithm is set to SHA256.

Publishing the Root CA Certificate and CRL

Next you will need to publish the new CA Certificate to any AIA repositories. You will also need to publish the new CRL to any CDP locations. <Add section on finding these sections>

Step 1: On the Root CA navigate to C:\Windows\Systen32\CertSrv\CertEnroll

Step 2: Copy the newest CA Certificate and CRL

Step 3: Make the CA Certificate and CRL available to a machine where you are logged in as Enterprise Admin.

Step 4: Run the folllowing command in an elevated command prompt and where the path in the command prompt is the same path where there is a copy of the CA Certificate:

certutil –f –dspublish <CA Certificate File Name> RootCA

Step 5: Run the folllowing command in an elevated command prompt and where the path in the command prompt is the same path where there is a copy of the CRL:

certutil –f –dspublish <CRL File Name>

Step 6: Copy the Root CA Certificate to the HTTP AIA Repository

Step 7: Copy the Root CRL to the HTTP CDP Repository

Renewing the Issuing CA Certificate

Step 1: Open the Certification Authority MMC (certsrv.msc) on the Issuing CA

Step 2: Right-click on the CA Name

Step 3: Select All Tasks and then Renew CA Certificate…from the context menu

Step 4: When prompted to stop the Active Directory Certificate Services service, click Yes

Step 5: When prompted to Renew CA Certificate, click OK. Note: If you do not want to renew the CA certificate with a new key pair, select No and then click OK.

Step 6: When prompted to submit the CA Certificate Request click Cancel

Step 7: Locate the newest request file in the C:\ directory

Step 8: Copy that request file to the Root CA

Step 9: On the Root CA open up the Certification Authority MMC (certsrv.msc)

Step 10: Right-click on the CA Name and from the context menu, select All Tasks and then Submit new request…

Step 11: Navigate to the request file and click Open.

Step 12: Return to the Certification Authority MMC and click on Pending Requests

Step 13: Right-click on the appropriate request and from the context menu click All Tasks and then Issue

Step 14: Navigate to Issued Certificates

Step 15: Right-click on the certificate you just generated and click Open

Step 16: Click on the Details Tab (Note that the Signature hash algorithm is set to SHA256)

Step 17: Click the Copy to File…button

Step 18: When the Certificate Export Wizard opens click Next

Step 19: On the Export File Format page of the wizard, select Cryptographic Message Syntax Standard – PKCS #7 Certificates (.P7B)

Step 20: Click Next

Step 21: On the File to Export page, click Browse…

Step 22: Navigate to the location where you want to save the resulting CA Certificate File, and then click Save

Step 23: Click Next

Step 24: Click Finish

Step 25: When prompted that The export was successful., click OK

Step 26: Copy the certificate from the Root CA to the Issuing CA

Step 27: From the context menu right-click on the CA Name and select All Tasks and then Install CA Certificate…

Step 28: When prompted to stop the Active Directory Certificate Services service, click Yes

Step 29: Browse to the CA Certificate Envelope file and click Open

Verify the Issuing CA Certificate

To verify that the Issuing CA certificate was renewed with SHA256 used in signing of the certificate, follow the following steps.

Step 1: Open the Certification Authority MMC

Step 2: Right-click on the CA Name and from the context menu click Properties

Step 3: Select the last certificate in the list

Step 4: Click View Certificate

Step 5: Verify that the Signature hash algorithm is set to SHA256

Publish CA Certificate

An Enterprise Issuing CA is normally configured to automatically publish it’s CRL to both the HTTP and LDAP CDP repositories. Enterprise Issuing CAs typically also are configured to publish their CA cert to Active Directory. But in my experience the Enterprise Issuing CA will not publish it’s CA certificate to an HTTP AIA repository. The following steps illustrate how to copy the CA Ceritficate to the HTTP AIA repository.

Step 1: Navigate to C:\Windows\System32\CertSrv\CertEnroll on the Issuing CA.

Step 2: Copy the newest CRT file.

Step 3: Locate the server(s) that host the HTTP AIA repository, paste the CRT file to the appropriate directory.

Validating PKI Status

The following steps will allow you to validate that all of the AIA and CDP repositories are now accessible and up to date with the appropriate files.

Step 1: Open pkiview.msc

Step 2: In the left hand pane click on the Root CA

Step 3: Verify that there are no errors in the right-hand pane

Step 4: Click on the Issuing CA

Step 5: Verify that there are no errors in the right-hand pane

Configure the Issuing CA

Next you will need to configure the Issuing CA to issue end-entity certificates that are signed using the SHA256 hash algorithm.

Step 1: Open the registry editor

Step 2: Navigate to HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\CSP

Step 3: Open the registry setting CNGHashAlgorithm

Step 4: Replace Value data with SHA256

Step 5: Click OK

Step 6: Restart the Active Directory Services service. One way to do this is to open an elevated command prompt and run the following command to stop the service: net stop certsvc, and then run the following command to start the service: net start certsvc.

-Chris

Background

Administrator Workstations

Cost of exposure

Options for Administrator Workstation

Hardening Requirements for Administrator Workstation

Restricting Administrator Access

Current Operating System

Secure Boot

Trusted Boot

Virtual Smart Cards

Protected Groups

Restricted Admin Mode for RDP

Secure Boot

AppLocker

Internet Restrictions

USB Restrictions

BitLocker

Network Isolation

This article walked thought the steps that can be used to secure an Administrator Workstation.  Of course you should customize this configuration for the needs of your specific environment.

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

Smart Card Group Policies

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

• Allow Integrated Unblock screen to be displayed at the time of logon
• Allow signature keys valid for Logon
• Allow time valid certificates
• Turn on certificate propagation from smart card
• Configure root certificate clean up
• Turn on root certificate propagation from smart card
• Prevent plaintext PINs from being returned by Credential Manager
• Allow ECC certificates to be used for logon and authentication
• Filter duplicate logon certificates
• Force the reading of all certificates from the smart card
• Display string when smart card is blocked
• Reverse the subject name store in a certificate when displaying
• Turn on Smart Card Plug and Play service
• Notify user of successful smart card driver installation
• Allow user name hint

These Group Policy settings are described in detail, here: http://technet.microsoft.com/en-us/library/ff404287(v=ws.10).aspx

Virtual Smart Card Prerequisites

· 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.

Installing Certificates on Domain Controllers

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.

Deploying Certificates to Domain Controllers via Autoenrollment

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 3^rd party certificates are installed on domain controllers and whether autoenrollment would interfere with the use of those certificates.

Creating Autoenrollment GPO

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

Adding Certificate Template to Certification Authority

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.

Verifying Certification Authority is in the NTAuth store

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.

Creating the Certificate Template

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

You will then be notified of features that will now be enabled in the Certificate Template. Select OK.

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.

Creating the Virtual Smart Card

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.

Logging on with Virtual Smart Card

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.

Changing Smart Card PIN

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.

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.

So, how does it work?

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.

Trusted Platform Module

First, we need to discuss the Trusted Platform Module, since the TPM is the device that makes Virtual Smart Card technology possible.

What is a Trusted Platform Module

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.

TPM Keys

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.

TPM and Identity

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.

Taking Ownership of 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.

TPM Management via Group Policy

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

Turn on TPM backup to Active Directory Domain Services

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.

Configure the list of blocked TPM commands

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.

Ignore the default list of blocked TPM commands

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.

Ignore the local list of blocked TPM commands

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.

Configure the level of TPM owner authorization information available to the operating system

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.

TPM Administration

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.

Turning on the TPM

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

Clearing the TPM and getting the Owner Authorization Password (No AD Backup)

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

Saving the TPM Owner Authorization Password

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

Clearing the TPM (AD Backup)

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

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 9

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 10

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.

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

Troubleshooting Issues that occur while clearing the TPM

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

Acquiring and Using Owner Authorization Password from Active Directory Backup

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>

Change TPM Owner Authorization Password

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

Reset TPM Lockout

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

TPM PowerShell Commands

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.

Summary

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

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.

GDR3

This morning when I woke up and checked my Windows Phone (HTC8X on Verizon) the so called GDR3 update was ready for installation. 

Office Remote

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.

Instagram

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

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

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

Nokia Lumia 1520

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!

-Chris

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. 

Virtual Machines

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.

Virtual Machines Menu

There is also a menu at the top of the screen. 

Virtual Machine Instances

By default Virtual Machine Instances are selected.  When Virtual Machine Instances is selected you see a list of your VMs.

Images

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.

CREATE AN IMAGE

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.

BROWSE VM DEPOT

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.

Disks

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

Create allows you to create new Virtual Disk from an existing VHD.

EDIT CACHE

Edit Cache allows you to modify whether caching applies to reads or reads and writes.

DELETE

Delete allows you to delete the selected Virtual Disk.

Virtual Machine Advanced Configuration

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.

Dashboard

If you click on DASHBOARD you will be able to view basic monitoring and information about the Virtual Machine.

Monitor

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.  

Endpoints

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. 

Configure

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.

Summary

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.

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.