Important notice: Microsoft does not support any apple products, if you need to troubleshoot any problem related to apple products, please refer to http://www.apple.com/support

Warning
SCEP was designed to be used in a closed network where all end-points are trusted. The warnings from CERT in the article"Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests " should be considered when implementing the NDES service. If an applicationutilizes SCEP, itshould provide its own strong authentication.

 

I am often asked by customers how to deploy certificates to iPads using NDES, where I refer them to Rob Greene’s blog for the steps required configuring NDES and enrolling these devices for certificates. Lately, I was presented with a challenge where a customer wanted to enroll these devices for certificates and authenticate them to an 802.1x infrastructure using Network Policy Server (NPS)

Let’s review how a non-domain joined machine authenticates to an 802.1x network before delving into the required steps for iPads to connect to the same network. Historically, the following steps were followed:

1. Create a placeholder computer account in Active Directory Domain Services (ADDS)

2. Configure a Service Principal Name (SPN) for the new computer object.

3. Enroll a computer certificate passing the FQDN of the placeholder computer object as a Subject Name, using Web Enrollment Pages or Certificates MMC snap-in directly from the computer (Skip step 4 if you are using the Certificates MMC snap-in)

4. Export the certificate created for the non-domain joined machine and install it.

5. Associate the newly created certificate to the placeholder ADDS domain computer account manually created through Name Mappings

a. Select Advanced View in Active Directory Users and Computers

b.Right-click the placeholder computer object and then select Name Mappings.

Note: Windows 7 and Windows Server 2008 R2 allows to you skip steps 3 and 4 by using Certificate Enrollment Web Services (CES) and Certificate Enrollment Web Policy (CEP) to enroll non-domain joined computers for certificates

The method described earlier applies to computers where the computer certificate enrolled is based on a computer template. The computer will present the certificate (Subject Name) to the Network Policy Server (NPS), which in turn will check if the computer account is enabled in ADDS.

Devices such as iPads behave differently, where they treat all certificates installed as a user certificate, hence when passing the subject name to the NPS server, NPS will look for a user object in ADDS rather than a computer object, causing the authentication request to fail

 

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 2/15/2012 8:55:49 PM

Event ID: 6273

Task Category: Network Policy Server

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC1.contoso.com

Description:

Network Policy Server denied access to a user.

 

Contact the Network Policy Server administrator for more information.

 

User:

 Security ID: NULL SID

 Account Name: ipad.contoso.com

 Account Domain: CONTOSO

 Fully Qualified Account Name: CONTOSO\ipad.contoso.com

 

Client Machine:

 Security ID: NULL SID

 Account Name: -

 Fully Qualified Account Name: -

 OS-Version: -

 Called Station Identifier: 021c1049ef6a

 Calling Station Identifier: b8ff6154d066

 

NAS:

 NAS IPv4 Address: 192.168.25.254

 NAS IPv6 Address: -

 NAS Identifier: 021c1049ef6a

 NAS Port-Type: Wireless - IEEE 802.11

 NAS Port: 34

 

RADIUS Client:

 Client Friendly Name: wrt350n

 Client IP Address: 192.168.25.254

 

Authentication Details:

 Connection Request Policy Name: Secure Wireless Connections

 Network Policy Name: -

 Authentication Provider: Windows

 Authentication Server: DC1.contoso.com

 Authentication Type: EAP

 EAP Type: -

 Account Session Identifier: -

 Logging Results: Accounting information was written to the local log file.

 Reason Code: 8

 Reason: The specified user account does not exist.

 

 

The certificates installed on IPads use the Network Device Enrollment Services (NDES) which utilizes the Simple Certificate Enrollment Protocol (SCEP) to enroll for device certificates – This is the default and can’t be changed - These device certificates are computer certificates and not user certificates.

certutil -v -adtemplate ipsecintermediateoffline

 

IPSECIntermediateOffline: IPSec (Offline request) -- Auto-Enroll: Access is denied.

 msPKI-Enrollment-Flag = 0

 msPKI-Certificate-Name-Flag = 1

 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT -- 1

 msPKI-Private-Key-Flag = 0

 flags = 10241 (66113)

 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT -- 1

 CT_FLAG_MACHINE_TYPE -- 40 (64)

 CT_FLAG_ADD_TEMPLATE_NAME -- 200 (512)

 CT_FLAG_IS_DEFAULT -- 10000 (65536)

 cn = IPSECIntermediateOffline

 distinguishedName = IPSECIntermediateOffline

 displayName = IPSec (Offline request)

templateDescription = Computer

 pKIExtendedKeyUsage = 1.3.6.1.5.5.8.2.2 IP security IKE intermediate

 pKIDefaultCSPs = Microsoft RSA SChannel Cryptographic Provider

 pKICriticalExtensions = 2.5.29.15 Key Usage

 revision = 7

 msPKI-Template-Schema-Version = 1

 msPKI-Template-Minor-Revision = 1

 msPKI-RA-Signature = 0

 msPKI-Minimal-Key-Size = 400 (1024)

 msPKI-Cert-Template-OID = 1.3.6.1.4.1.311.21.8.800281.5632585.475790.4272720.15075391.217.1.20

 msPKI-Supersede-Templates =

 msPKI-RA-Policies =

 msPKI-RA-Application-Policies =

 msPKI-Certificate-Policy =

 msPKI-Certificate-Application-Policy =

 dwKeySpec = AT_KEYEXCHANGE

 pKIExpirationPeriod = 2 Years

 pKIOverlapPeriod = 6 Weeks

 

Template Extensions: 3

 1.3.6.1.4.1.311.20.2: Flags = 0, Length = 32

 Certificate Template Name (Certificate Type)

 IPSECIntermediateOffline

 

 2.5.29.37: Flags = 0, Length = c

 Enhanced Key Usage

 IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

 

 2.5.29.15: Flags = 1(Critical), Length = 4

 Key Usage

 Digital Signature, Key Encipherment (a0)

 

As a result, the Network Policy Server (NPS) will deny access to the iPad device, because it is mapping the wrong certificate type, and will log the following security event.

 

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 2/19/2012 12:38:38 PM

Event ID: 6273

Task Category: Network Policy Server

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC1.contoso.com

Description:

Network Policy Server denied access to a user.

 

Contact the Network Policy Server administrator for more information.

 

User:

 Security ID: CONTOSO\ipad

 Account Name: ipad

 Account Domain: CONTOSO

 Fully Qualified Account Name: CONTOSO\ipad

 

Client Machine:

 Security ID: NULL SID

 Account Name: -

 Fully Qualified Account Name: -

 OS-Version: -

 Called Station Identifier: 021c1049ef6a

 Calling Station Identifier: b8ff6154d066

 

NAS:

 NAS IPv4 Address: 192.168.25.254

 NAS IPv6 Address: -

 NAS Identifier: 021c1049ef6a

 NAS Port-Type: Wireless - IEEE 802.11

 NAS Port: 34

 

RADIUS Client:

 Client Friendly Name: wrt350n

 Client IP Address: 192.168.25.254

 

Authentication Details:

 Connection Request Policy Name: Secure Wireless Connections

 Network Policy Name: Secure Wireless Connections

 Authentication Provider: Windows

 Authentication Server: DC1.contoso.com

 Authentication Type: EAP

 EAP Type: Microsoft: Smart Card or other certificate

 Account Session Identifier: -

 Logging Results: Accounting information was written to the local log file.

 Reason Code: 293

  Reason: The certificate is not valid for the requested usage.

 

The only way to make this work is to map the computer enrolled certificate to a user account, which is described in the remainder of this blog.

Extreme Caution: The steps mentioned in this blog were tested in an isolated network, and not verified to work fully in an Enterprise Network. This solution is provided as is without any Microsoft support.

But, wait! What if we issue a certificate with subject type computer (e.g. IPSec Offline Request) and associate to the user account?

Important:

The steps to enroll certificates for IPads and iPhone were described in iPad/iPhone Certificate Issuance . The solution provided in this blog assumes you read it first.

The X.500 notation in the Iphone Configuration Utility for CN (common name) or O (Organization ) has to be upper case letters – example CN=IPAD1 – failure to type the correct syntax will generate the following error on the Network Device Enrollment Service (NDES) during certificate enrollment:

 

Log Name: Application

Source: Microsoft-Windows-NetworkDeviceEnrollmentService

Date: 2/16/2012 4:40:58 AM

Event ID: 31

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: NDES.contoso.com

Description:

The Network Device Enrollment Service cannot submit the certificate request (The request subject name is invalid or too long.). 0x80004005

 

Basic lab topology

High Level Operational Steps

 

1. The device connects to a deployment wireless network (isolated) while connected via USB to the Mobile Device Management Software (MDM). In this example, the IPad is connected to the Iphone Configuration Utility.
2. The device Administrator connects to the Network Device Enrollment Service (NDES) to obtain a temporary password which is entered in the Mobile Device Management (MDM) as the device’s profile.
3. The Mobile Device Management (MDM) software pushes the profile configuration to the device.
4. The device creates the private/public pair key and sends a request to the Network Device Enrollment Service (NDES)to request a certificate
5. The Network Device Enrollment Service (NDES) sends an RA request to the Certification Authority (CA)
6. The Certification Authority (CA) sends the certificate to the Network Device Enrollment Service (NDES)
7. The Network Device Enrollment Service (NDES) sends the certificate to Device which in turn installs it
8. The Device connects to the corporate network using 802.1X

 

Configuration steps

 

1. Create a user account for each device you want to enroll in ADDS with the following specifications:

a.Set a long complex password (at least 15 characters).

b.Set the password to not expire by selecting Password never expires.

c.In the user properties Account tab, select Smart Card is required for interactive logon. Select Smart card is required for interactive logon.

d.Select Account is sensitive and cannot be delegated in the user properties “Account “ tab.

e.Click on “Logon On To” button and in “The Following Computers” and then enter a placeholder computer name (IPad’s IMEI for example). The placeholder computer account doesn’t need to exist in ADDS.

 

Note: Disabling the user account will not work, because the Network Policy Service (NPS) will detect that the account is disabled it will deny access to the iPad. The Network Policy Server (NPS) will log the following event if the user account is disabled

 

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 2/16/2012 4:52:50 PM

Event ID: 6273

Task Category: Network Policy Server

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC1.contoso.com

Description:

Network Policy Server denied access to a user.

 

Contact the Network Policy Server administrator for more information.

User:

 Security ID: CONTOSO\ipad

 Account Name: ipad

 Account Domain: CONTOSO

 Fully Qualified Account Name: CONTOSO\ipad

 

Client Machine:

 Security ID: NULL SID

 Account Name: -

 Fully Qualified Account Name: -

 OS-Version: -

 Called Station Identifier: 021c1049ef6a

 Calling Station Identifier: b8ff6154d066

 

NAS:

 NAS IPv4 Address: 192.168.25.254

 NAS IPv6 Address: -

 NAS Identifier: 021c1049ef6a

 NAS Port-Type: Wireless - IEEE 802.11

 NAS Port: 34

 

RADIUS Client:

 Client Friendly Name: wrt350n

 Client IP Address: 192.168.25.254

 

Authentication Details:

 Connection Request Policy Name: Secure Wireless Connections

 Network Policy Name: -

 Authentication Provider: Windows

 Authentication Server: DC1.contoso.com

 Authentication Type: EAP

 EAP Type: -

 Account Session Identifier: -

 Logging Results: Accounting information was written to the local log file.

 Reason Code: 34

Reason: The user or computer account that is specified in the RADIUS Access-Request message is disabled.

 

2. Duplicate the User template with the following configuration (name it as “UserV2” for example):

a. Request Handling tab:

i. Purpose – Signature and encryption

ii. No other checkbox selected

iii. CSP – Microsoft RSA Schannel Cryptographic Provider

b. Subject Name Tab:

i. Select “Supply in the request”

c.Issuance Requirements Tab

i.Nothing selected or configured

d. Extensions tab:

i. Application Policies:

• • • • IP Security IKE Intermediate
      • Server Authentication
      • Client Authentication

ii. Basic Constraints:

• • • • Leave as default

iii. Certificate Template Information:

• • • • This configuration comes from the AD Template object; you need to modify the subject type from user to computer, which allows NDES to enroll for user certificates (described in Step 4).

iv. Issuance Policy:

• • • • Leave as default

v. Key Usage:

• • • • Signature requirements:
        • Digital Signature
        • Allow key exchange only with key encryption
        • Critical extension

e.Security Tab

i. Configure in the same way as described in the iPad/iPhone Certificate Issuance.

 

3. Check the certificate template attributes you created in step 2 using certutil –v –adtemplate userv2 and note the template description attribute. This attribute will be changed later on

 

Userv2: User v2 -- Auto-Enroll: .

 msPKI-Enrollment-Flag = 0

 msPKI-Certificate-Name-Flag = 1

 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT -- 1

 msPKI-Private-Key-Flag = 0

 flags = 2023a (131642)

 CT_FLAG_ADD_EMAIL -- 2

 CT_FLAG_PUBLISH_TO_DS -- 8

 CT_FLAG_EXPORTABLE_KEY -- 10 (16)

 CT_FLAG_AUTO_ENROLLMENT -- 20 (32)

 CT_FLAG_ADD_TEMPLATE_NAME -- 200 (512)

 CT_FLAG_IS_MODIFIED -- 20000 (131072)

 cn = Userv2

 distinguishedName = Userv2

 displayName = User v2

templateDescription = User

 pKIExtendedKeyUsage =

 0: 1.3.6.1.5.5.8.2.2 IP security IKE intermediate

 1: 1.3.6.1.5.5.7.3.1 Server Authentication

 2: 1.3.6.1.5.5.7.3.2 Client Authentication

 pKIDefaultCSPs = Microsoft RSA SChannel Cryptographic Provider

 pKICriticalExtensions =

 0: 2.5.29.7 Subject Alternative Name

 1: 2.5.29.15 Key Usage

 revision = 64 (100)

 msPKI-Template-Schema-Version = 2

 msPKI-Template-Minor-Revision = 8

 msPKI-RA-Signature = 0

 msPKI-Minimal-Key-Size = 800 (2048)

 msPKI-Cert-Template-OID = 1.3.6.1.4.1.311.21.8.800281.5632585.475790.4272720.15075391.217.15856343.7753402 User v2

 msPKI-Supersede-Templates =

 msPKI-RA-Policies =

 msPKI-RA-Application-Policies =

 msPKI-Certificate-Policy =

 msPKI-Certificate-Application-Policy =

 0: 1.3.6.1.5.5.8.2.2 IP security IKE intermediate

 1: 1.3.6.1.5.5.7.3.1 Server Authentication

 2: 1.3.6.1.5.5.7.3.2 Client Authentication

 dwKeySpec = AT_KEYEXCHANGE

 pKIExpirationPeriod = 1 Years

 pKIOverlapPeriod = 6 Weeks

 

Template Extensions: 4

 1.3.6.1.4.1.311.21.7: Flags = 0, Length = 2f

 Certificate Template Information

 Template=User v2(1.3.6.1.4.1.311.21.8.800281.5632585.475790.4272720.15075391.217.15856343.7753402)

 Major Version Number=100

 Minor Version Number=8

 

 2.5.29.37: Flags = 0, Length = 20

 Enhanced Key Usage

 IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

 Server Authentication (1.3.6.1.5.5.7.3.1)

 Client Authentication (1.3.6.1.5.5.7.3.2)

 

 2.5.29.15: Flags = 1(Critical), Length = 4

 Key Usage

 Digital Signature, Key Encipherment (a0)

 

 1.3.6.1.4.1.311.21.10: Flags = 0, Length = 26

 Application Policies

 [1]Application Certificate Policy:

 Policy Identifier=IP security IKE intermediate

 [2]Application Certificate Policy:

 Policy Identifier=Server Authentication

 [3]Application Certificate Policy:

 Policy Identifier=Client Authentication

 

4. Network Device Enrollment Service (NDES) does not support user templates; as a result, the user template created in Step 2 has to be changed to a computer template. To do so:

a. Open Active Directory Sites and Services

b. Select Menu , View and then select Show Services Node.

c. Expand Services, Public Key Services and then click Certificate Templates.

d. Open the duplicated certificate template created in step 2 (UserV2 in this example)

e. Edit the flags attribute and change its value from 131642 to 131706.

Extreme Warning: This method is supplied as is, and should be thoroughly tested in your environment. Deploy this solution at your own risk

If you run certutil –v –adtemplate userv2command again, you can see that the templatedescription attribute was changed from user to computer.

 

5.Publish the certificate created in step 2 to the Certification Authority (CA).

 

Note: If you don’t perform these changes to the certificate template and configure NDES to deploy this template, then you will receive the following error when requesting the challenge password from the Network Device Enrollment Service (NDES):

 

Network Device Enrollment Service

Network Device Enrollment Service allows you to obtain certificates for routers or other network devices using the Simple Certificate Enrollment Protocol (SCEP).

You do not have sufficient permission to enroll with SCEP. Please contact your system administrator.

For more information see Using Network Device Enrollment Service.

6. Configure the Network Device Enrollment Service (NDES) to issue certificates based on the certificate template created in step do by editing the following registry key:

 

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP]

"SignatureTemplate"="Userv2"

"EncryptionTemplate"="Userv2"

"GeneralPurposeTemplate"="Userv2"

 

 

7. Restart Internet Information Services (IIS) on the Network Device Enrollment Service (NDES).

8. Install the Root CA’s certificate on the computer where you will run the iPhone Configuration Utility.

9. Open the iPhone Configuration Utility and create a configuration profile.

10. Make sure NDES and SCEP settings are configured in the iPhone Configuration Utility using the steps in iPad/Iphone Certificate Issuance blog.

11. Select Wi-fi and enter the SSID of the 802.1x wireless network.

12. Select Auto-Join.

13. On Security type, select WPA/WPA2 Enterprise.

14. Select Protocols and then choose TLS

 

 

15. Next, select Authentication and choose the SCEP identity certificate that was previously configured as outlined in iPad/Iphone Certificate Issuance blog.

 

 

16. Select “Trust” and choose your RootCA certificate as a trusted certificate.

 

17. After the CA issues the new certificate, you must export it from the CA and associate this certificate with the user account that was created in step 1:

a.Open Active Directory Users and Computers

b.Select menu, View-and then select Advanced Features

c.Find the user account that represents the IPad

d.Right-click the user account and choose Name Mappings

e.Click Add, then select the certificate to import

 

18. Deploy the profile to your IPad

 

NPS Basic Settings

 

The Network Policy Server (NPS) settings that were configured during this solution were:

1. Make your Network policy Server (NPS) member of “RAS and IAS Servers” group

2. Publish the “RAS and IAS Server” certificate template to your CA

3. Enroll your Network policy Server (NPS) server for the “RAS and IAS Server” certificate

4. In Policies, select Connection request policies:

a. Create a Policy named “Secure Wireless Connections” with a condition:

• • NAS Port Type = “Wireless – Other or Wireless – IEE 802.11”

b. Disable the default policy called “Use Windows authentication for all users”

5. In Policies, select Network Policies:

a. Create a policy named “Secure Wireless Connections” with following settings:

• • Overview Tab
    • Select “Grant Access. Grant access if the connection request matches this policy.”
    • Select “Ignore user account dial-in properties”
  • Conditions Tab
    • NAS Port Type = “Wireless – Other or Wireless – IEE 802.11”
    • Windows Groups = “Contoso\Domain users” (this could be any group, just make sure to make the user account member of it)
  • Constraints Tab
    • Authentication Methods
      • Microsoft: Smart Card or other certificate (choose the enrolled RAS and IAS Server certificate)

Thanks to Paulo Marques da Costa for writing this informative Blog

 

Jonathan Stephensposted an excellent Blog about this topic; however, it didn’t include the steps. As a result, I decided to type this Blog detailing the steps required. The following assumptions have to be met before proceeding with these steps:

1- There is a new valid Certification Authority configured

2-There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData

Steps:

1-Logon to the old Enterprise Certification Authority as an Enterprise Administrator.

2-Identify the AIA and CDP distribution points

1. a. Open the Certification Authority Console
2. b. Right click the Certification Authority name and click Properties
3. c. Click the “Extensions” tab
4. d.Document the distribution points configured for CRL Distribution Point (CDP) – as an example http://<serverDNSnname>/CertEnroll/<CANAME>CRLNameSuffix><DeltaCRLAllowed>.crl which refers to local IIS installed on the server, or http://pki.contoso.com/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: Ignore the LDAP and C:\%windir% locations

1. e.In the “Extensions” tab, select Authority Information Access (AIA) from the drop down menu
2. f.Document the distribution points configured for the AIA extensions – as an example http://<ServerDNSName>/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt which refers to the local IIS installed on the server or http://pki.contoso.com/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt

Note: Ignore the LDAP and C:\%windir% locations

3-Disable Delta CRL and Issue a long Certificate Revocation List (CRL)

1. a. Open the Certification Authority Console
2. b.Right click “Revoked Certificates”, and then click “Properties”
3. c.Uncheck “Publish Delta CRL”
4. d.Change the “CRL publication Interval” to 99 years and then click OK
5. e.Open the command line with elevated privileges
6. f.Run Certutil –crl to issue a new Certificate Revocation List (CRL)

4-Copy the old Certification Authority’s certificate (CRT) and certificate revocation list (CRL) files to the server hosting website http://crl.contoso.com/CertData

1. a. On the old Certification Authority, navigate to %windir%\System32\CertSrv\CertEnroll
2. b.Copy the Certification Authority’s certificate (CRT) and certificate revocation list (CRL) to the directory hosting http://crl.contoso.com/CertData

5-Redirect the Authority Information Access (AIA) and Certificate Revocation List (CRL) distribution points of the old Certification Authority to http://crl.contoso.com/certdata

1. a. This can be done using an IIS redirect, or a DNS CNAME redirect to redirect Authority information Access (AIA) and Certificate Revocation List (CRL) of the old Certification Authority documented in steps 2.d and 2.f to the new web server http://crl.contoso.com/certdata

6- Document and remove all certificate templates available on the old Certification Authority to prevent it from issuing new certificates

1. a. Open the command line with elevated privileges
2. b. Run Certutil –catemplates > c:\catemplates.txt to document all available certificate templates at the old Certification Authority
3. c. Launch the Certification Authority console
4. d. Navigate to “Certificate Templates”
5. e. Highlight all templates in the right pane, right click and then click “Delete”

At this point, the old Certification Authority can’t issue any certificates, and has all of its Authority Information Access (AIA) and Certificate Revocation List (CRL) redirected to a new web site http://crl.contoso.com/CertData The next steps will detail how to document the certificates issued by templates from the old Certification Authority and how to make them available at the new Certification Authority.

7- Identify and document the certificates issued based on certificate templates by sorting the Certification Authority database

1. a. Highlight “Issued Certificates”
2. b.Navigate to the right, and sort by “Certificate Templates”
3. c. Identify the certificates issued by default certificate template types
4. d. Identify the certificates issued by custom certificate templates – any template other than the default certificate templates mentioned earlier

8- Dump the certificates based on the default certificate template types:

1. a. Open the command line with elevated privileges
2. b. Run Certutil -view -restrict "Certificate Template=Template" -out "SerialNumber,NotAfter,DistinguishedName,CommonName" > c:\TemplateType.txt
3. c.Examine the output of c:\TemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as Web SSL.
4. d. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: Replace Template with the correct template name.

9- Dump the certificates based on the custom certificate template types:

1. a. Open the Certification Authority Console
2. b. Right click “Certificate Templates” and click “Manage”
3. c.Double click the certificate template and click on “Extensions” tab
4. d. Click on “Certificate Template Information”
5. e. Copy the Object Identifier (OID) number – the number will look similar to 1.3.6.1.4.1.311.21.8.12531710.13924440.6111642.16676639.10714343.69.16212521.10022553
6. f. Open the command line with elevated privileges
7. g. Run Certutil -view -restrict "Certificate Template=OIDNumber" -out "SerialNumber,NotAfter,DistinguishedName,CommonName" > c:\CustomTemplateType.txt

Note: Replace OIDNumber with the number identified in step 9.e

1. h. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as custom SSL certificates.
2. i. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: You don’t need to take any action if the certificate was auto-enrolled because the certificate holder will renew the certificate when it expires from the new CA infrastructure.

10- Enable the Certificate Templates needed based on the results of steps 7-9 on the new Certification Authority

1. a. Logon to the new Certification Authority as an Enterprise Administrator
2. b. Right Click “Certificate Templates”, click “New” and then click “Certificate Template to Issue”
3. c. Choose all the certificate templates needed in the “Enable Certificate Templates” window and click “OK”

11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority

1. a. Backup the old Certification Authority using the steps outlined in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS)
2. b. Uninstall Certificate Services from the old Certification Authority
3. c. Decommission the server unless it is running other applications

12- Once all certificates are issued by the new infrastructure, you can safely remove all the Authority Information Access (AIA) and Certificate Revocation List (CRL) files from you infrastructure by following the steps in How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects and from the web server hosting http://crl.contoso.com

 

Amer F. Kamal

Senior Premier Field Engineer

If a Key Recovery Agent (KRA) certificate is stored in a Cryptography Next Generation (CNG) Key Service Provider (KSP), the certutil -RecoverKey command will by default recover a key as a CNG certificate. This default behavior could cause an issue if you are recovering a Rivest, Shamir and Adleman (RSA) key for the Encrypting File System (EFS). EFS supports KSPs only for Elliptic Curve Diffie-Hellman (ECDH) keys.

A workaround for this problem is to specify the switch -csp “Microsoft Strong Cryptographic Provider” with certutil -importpfx to ensure that the key is recovered in the appropriate format.

Microsoft MVP, Vadims Podans, has written and posted a Windows PowerShell script that can be used to setup a certification authority (CA). He posted his Windows PowerShell Script on the TechNet Script Repository as Setup Certification Authority with PowerShell posted at http://gallery.technet.microsoft.com/scriptcenter/Setup-Certification-bd2aff3e.

I am often asked when talking to my customers about the differences between Key Recovery and Data Recovery for encrypted files, in addition to which method to use. As a result, This Blog will focus on both areas, explaining the differences and best practices.

Both methods can easily be understood, after understanding the Encrypting File System (EFS) process in a domain environment including certificate enrollment and file encryption

EFS Certificate Enrollment:

When a user attempts to encrypt a file without having an EFS certificate the following process takes place:

1. The user’s registry (HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash) is queried for an Encryption Certificate
2. If there isn’t a default certificate, then the user store is queried for any viable certificate with the Encrypting File System Object Identifier OID (1.3.6.1.4.1.311.10.3.4.)
3. If there isn’t a viable encryption certificate, then the user will request an Encrypting File System certificate based on the BasicEFS template from an Enterprise CA, or any other template superseding it.
4. If the BasicEFS template is not available at any Enterprise CA, and any other template for EFS is not available then the computer will generate a self-signed EFS certificate.

Note: I am not a big fan of self-signed certificates especially when there are Enterprise Issuing CAs in a given Active Directory Forest. As a result, I recommend disabling the machine’s ability to generate an EFS Self-Signed certificate using the hotfix for Windows XP or Windows Server 2003

Windows Server 2008 and Windows 7 have a group policy setting which can disable the generation of an EFS Self-Signed certificate simply by unchecking the option to “Allow EFS to generate self-signed certificates when a certification authority is not available.

File Encryption Process:

Once the user has a valid Encrypting File System (EFS) certificate, then they can encrypt their files and folders following this process:

1. The user’s computer generates a random symmetric encryption key called File Encryption Key (FEK)
2. The computer retrieves the user’s Encrypting File System (EFS) certificate in the user store and obtains the user’s Public Key
3. The FEK created in step one is encrypted by the user’s Public Key in step 2

For more information about EFS Encryption, refer to How EFS Works on TechNet

Why Should I Implement Any Recovery Method?

An organization’s security policy typically lists the following reasons for allowing data or key recovery:

1. A user profile is deleted. When an encryption private key is stored in a user’s profile folder, the private key is lost if a anyone deletes that specific profile. Many organizations use profile deletion to fix problems with user logon. For example, if the desktop fails or takes a long time to appear, many organizations prescribe deleting the user’s profile and generating a new profile. This results in deletion of the user’s private key material.
2. A hard disk is corrupted. The corruption of a hard disk can cause users to lose access to their profiles. This can mean a total loss of access or loss of access to the private key material within the user profile.
3. The operating system is reinstalled. When the operating system is reinstalled, access to the previous user profiles is lost, including any private keys stored in the user’s profile.
4. A computer is stolen or lost. When a computer is stolen or lost, access to the private key material in the user profile is lost or compromised.

Note: A difference among the reasons listed, however, is that a computer theft or loss can mean the user’s private key is compromised and, therefore, the certificate associated with the private key should be revoked. There is no reason to revoke the certificate for the other reasons in this list because the user’s private key is not compromised.

Where is the File Recovery Agent role in the File Encryption Process?

If your domain has a designated File Recovery Agent certificate enrolled, also known as the Data Recovery Agent, then the computer will retrieve its information from the local computer configuration – deployed through Group Policy – extract the Public Key from the recovery agent’s certificate, and encrypts the File Encryption Key (FEK) with it. This process will apply to all the Data Recovery Agents in the domain.

Where is the Key Recovery Agent Role in the File Encryption Process?

This is not a trick question; the Key Recovery Agent (KRA) certificate doesn’t come to play at all when encrypting a file a folder. Key Recovery Agent (KRA) is enrolled using the Key Recovery Agent Certificate Template, and then added to the CA configuration. The Key Recovery Agent (KRA) can extract the end user’s Encrypting File System (EFS) Private Key and Certificate from the CA’s database, which in turn can be used by the end user to decrypt their files.

When a certificate template specifies Key Archival, the private key with a certificate request must be securely transmitted from the requesting client computer to the Certification Authority for archival in the CA database. When a client requests a certificate that has Key Archival enabled, the following process takes place:

1. The client queries the Enrollment Services container in the configuration partition of Active Directory to find an Enterprise CA
2. The client requests the CA’s CA Exchange Certificate
3. The client examines the received CA Exchange certificate to ensure it was signed by the CA’s signing certificate, and performs a certificate validation and revocation status check on the CA Exchange certificate
4. The client encrypts the private key corresponding to the request using the CA Exchange certificate’s public key and send the request to the Certification Authority
5. The Certification Authority verifies that the encrypted private key is the matched key to the public key, validates the signature on the request with the Public key in request to ensure the contents were not tampered with.
6. The Certification Authority encrypts the user’s request with a random symmetric key and then encrypts the symmetric key with one or more Key Recovery Agent (KRA) public keys defined in the Certification Authority’s properties
7. The Certification Authority saves the encrypted key BLOB which contains the encrypted private key and the symmetric key encrypted with one or more Key Recovery Agent (KRA) public keys
8. Lastly, the Certification Authority processes the request and issues a certificate to the requestor.

Which Method Should I Use?

There isn’t a correct answer for this question. It all depends on your company’s policies and procedures. It is also important to note that the person or group performing Key Recovery or File Recovery should be trustworthy and held to the highest levels of scrutiny.Understanding the difference between Key Recovery and File Recovery Procedures can help you determine the correct answer to your infrastructure’s requirements.

With Key recovery. The user’s original certificate and private key are recovered from the CA database and restored to the user’s profile. Recovery of the user’s certificate and private key allows the user to access the FEK stored in the EFS-encrypted file, returning access to the file to the user.

The major advantages for Key Recovery are:

1. Quick EFS decryption resolution by restoring the user’s Private Key and Certificate
2. The data doesn’t leave the end user’s computer

The major disadvantages of Key Recovery are:

1. The CA has to be prepared for Key Archival and requires the enrollment of Key Recovery Agents before rolling out EFS
2. The restore of the Private Keys might be a little complicated if the user has multiple Encrypting File System (EFS) certificates.
3. The Certification Authority must be installed on the Enterprise or Data Center SKU of the Operating System

Data recovery on the other hand, allows a designated EFS Recovery Agent to decrypt all EFS-encrypted files on a computer. By default, where the private key associated with the EFS Recovery Agent certificate exists – which can be a designated recovery computer, or the end user’s computer.

The major advantages of Data Recovery are:

1. Data Recovery Agents can be added to the File Encryption Key (FEK) after a user had already encrypted their files. This means a new Data Recovery Agent can be enrolled and added to the domain group policy, which allows the new Data Recovery Agent to recovery encrypted files
2. The Data Recovery Agent can decrypt the files for the end user
3. Data Recovery Agents can decrypt files and folders encrypted using self-signed encryption certificates or an encryption certificate issued by an enterprise issuing CA.
4. It doesn’t have any Certification Authority operating system pre-requisites

The major disadvantage of Data Recovery is the recovery method itself, because the Data Recovery Agent has to decrypt the end user’s files either on premise or remotely. This can have a significant impact on data transfers from remote sites to hub sites, or vice versa because the encrypted/decrypted data has to be copied twice.

Common Misconception:

A common misconception is that the Administrator account is the Data Recovery Agent (DRA) or the Key Recovery Agent (KRA). Both recovery methods rely on the certificates (Private and Public Key Pairs) of the KRA and DRA, which means anyone who has possession of them can recover keys. If an end user manages to possess the Data Recovery keys as an example, then they can decrypt any encrypted file in the organization. As a result, you should protect these keys, and establish a chain of custody anytime the key is used.

Conclusion:

Encrypting File System (EFS) shouldn’t be implemented without proper planning because of complexities in Data and Key Recovery. Make sure to understand both recovery methods before enrolling the first EFS certificate, and test recovery multiple times in a lab environment. Lastly, consider implementing both methods for extra recovery protection

Amer F Kamal

Senior Premier Field Engineer