Chapter 25: Document and Code Signing 665 Best Practices ■ Configure the Unsigned Driver Installation Group Policy setting to either warn or prevent installation of unsigned device drivers. This setting ensures either that the local administrator is aware that an unsigned driver is implemented, or it prevents the installation of unsigned drivers in the local operating system. ■ Use a commercially issued Code Signing or Document Signing certificate for publicly distributed applications. If the application you sign is intended for public use, acquire the Code Signing or Document Signing certificate from a commercial CA, such as VeriSign. This certificate increases the assurance in the signed application because the signing certificate chains to a root CA trusted by most organizations. ■ Use a corporate-issued Code Signing or Document Signing certificate for internal applications. There is no need to acquire a Code Signing or Document Signing certificate from a commercial organization for internal applications. All computers within the organization trust the local CA hierarchy’s root CA. ■ Increase the protection of the Code Signing or Document Signing certificate’s private key by using a smart card CSP. A smart card CSP provides higher protection of the Code Signing certificate’s private key by storing the private key on a two-factor hardware device. ■ Create a custom version 2 certificate template based on the Code Signing or Document Signing certificate that requires certificate manager approval. This measure increases the assurance of the Code Signing or Document Signing certificate and allows stronger identity validation of the Code Signing certificate requestor. Note Alternatively, use a registration authority to enforce the validation of the requestor’s identity before the certificate is issued. ■ Implement code signing for all macros implemented in Microsoft Office applications. This practice allows an organization to increase the macro security level to prevent the execution of nonsigned macros, thereby protecting an organization from attacks based on Visual Basic macros. ■ Implement code signing for all ActiveX controls developed by your organization. This practice allows you to increase the ActiveX security settings within Internet Explorer, blocking the execution of unsigned ActiveX controls. ■ Outsource a Time Stamping Service. The outsourcer provides a date and time stamp to the code signing process, allowing signature-event recognition if the signing certificate is later revoked. As long as the time stamp is a date or time before the revocation date, the signature is still considered valid. 666 Part III: Deploying Application-Specific Solutions ■ Use the organization name as the subject of the Code Signing certificate. This associates the Code Signing certificate with the organization rather than an individual. You can accomplish this by creating a custom user in AD DS or by allowing the subject to be manually input by the certificate requestor. Additional Information ■ Microsoft Official Curriculum, Course 2821: “Designing and Managing a Windows Public Key Infrastructure” (http://www.microsoft.com/traincert/syllabi/2821afinal.asp) ■ Writing Secure Code, Second Edition, by Michael Howard and David LeBlanc (Microsoft Press, 2002) ■ “Microsoft Windows Software Development Kit Update for Windows Vista” (http://www.microsoft.com/downloads/details.aspx?familyid=4377f86d-c913-4b5c-b87e- ef72e5b4e065&displaylang=en) ■ “Introduction to Code Signing” (http://msdn.microsoft.com/workshop/security/ authcode/intro_authenticode.asp) ■ “Frequently Asked Questions About Authenticode” (http://msdn.microsoft.com/library/ en-us/dnauth/html/signfaq.asp) ■ “Microsoft Technet: 5-Minute Security Advisor—Signing Office Objects” (http://www.microsoft.com/technet/community/columns/5min/5min-402.mspx) ■ “ActiveX Controls and Office Security” (http://www.microsoft.com/office/ork/2003/ seven/ch23/SecA05.htm) ■ “Digital Signature Resources for Adobe Acrobat” (http://www.adobe.com/security/ digsig.html) ■ “Details on Digital Signatures” (http://office.microsoft.com/en-us/infopath/ HP010967151033.aspx?pid=CH011097171033) ■ “nCipher Time Stamp Server” (http://www.ncipher.com/timestamping.html) 667 Chapter 26 Deploying Certificates to Domain Controllers One of the most common types of certificates deployed in a Microsoft Windows networking environment is domain controller (also referred to a Kerberos Distribution Center or KDC) certificates. The KDC certificates are used by domain controllers for: ■ Authenticating the domain controllers when a user logs on to the network with a smart card. ■ Securing queries by Lightweight Directory Access Protocol (LDAP) clients when a user queries Active Directory Domain Services (AD DS) using an LDAP Secure Sockets Layer (LDAPS)–protected connection. ■ Securing Simple Mail Transfer Protocol (SMTP) replication traffic between AD DS sites. Changes in Domain Controller Certificates Windows Server 2008 includes four different domain controller certificate templates. The fol- lowing sections describe: ■ The history of the domain controller certificate choices. ■ Implementing strong KDC validation. ■ How a Windows Server 2008 domain controller selects its certificate. History of Domain Controller Certificates The Domain Controller certificate template was introduced in Microsoft Windows 2000 enterprise certification authorities (CAs) for two purposes: ■ Providing a server authentication certificate to domain controllers for smart card authentication ■ Secure e-mail replication between domain controllers in different domains Table 26-1 outlines the specific attributes of a certificate based on the Domain Controller certificate template. 668 Part III: Deploying Application-Specific Solutions Note Some organizations use the Domain Controller certificate template to enable other platforms to securely query AD DS using Secure Lightweight Directory Access Protocol (LDAP/S). The LDAP tools connect to TCP port 636 on the domain controller, securing the connection by using the domain controller’s certificate. In Windows Server 2003, two new version 2 certificate templates were created to separate domain controller authentication from securing e-mail replication. ■ Domain Controller Authentication Enables authentication of the domain controller during smart card logon. Also used to secure LDAP/S connections to domain controllers. ■ Directory Email Replication Enables encryption of replication traffic between domain controllers when Simple Mail Transfer Protocol (SMTP) is used as the replication protocol. In both cases, the version 2 certificate templates are configured to supersede the Domain Controller certificate template. This configuration setting ensures that certificates based on the Domain Controller certificate template are replaced with certificates based on both the Domain Controller and the Directory Email Replication certificate templates. Table 26-2 outlines the specific attributes of the Domain Controller Authentication and Direc- tory Email Replication certificate templates. Table 26-1 Domain Controller Certificate Template Attributes Attribute Domain controller Subject CN=Fully Qualified Domain Name (FQDN) Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2) Server Authentication (1.3.6.1.5.5.7.3.1) Subject Alternative Name Other Name: 1.3.6.1.4.1.311.25.1=GUID DNS Name=FQDN Table 26-2 Windows Server 2003 Domain Controller Certificate Templates Attribute Domain Controller Authentication Directory Email Replication Subject Empty Empty Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2) Server Authentication (1.3.6.1.5.5.7.3.1) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Directory Service Email Replication (1.3.6.1.4.1.311.21.19) Chapter 26: Deploying Certificates to Domain Controllers 669 Note The biggest change in the certificate template design is implementing a blank subject name for both certificate templates. Instead, the FQDN is stored in the Subject Alternative Name (SAN) extension. The SAN allows longer FQDNs than the Subject (which is limited to 64 characters). Windows Server 2008 introduces a new certificate template called Kerberos Authentication. The new certificate template is intended to replace the Domain Controller Authentication cer- tificate template. The main change is changing the name recorded in the SAN from the FQDN to the domain name of the domain controller. The change helps in several ways: ■ The domain-joined client can verify that it is connecting to a domain controller for the specified domain by validating that the domain name recorded in the SAN is the desired domain. ■ LDAP/S clients can connect to any domain controller in the domain. Previously, the LDAP/S clients had to connect to a specific domain controller and provide its FQDN in the connection string. Table 26-3 provides details on the attributes in a Kerberos Authentication certificate. Enforcing Strong KDC Validation If you have deployed a Kerberos Authentication certificate to your domain controllers, you can enforce strong Kerberos Distribution Center (KDC) validation for computers running Windows Vista and Windows Server 2008. To enable strong KDC validation, you must Subject Alternative Name DNS Name=FQDN Other Name: 1.3.6.1.4.1.311.25.1=GUID DNS Name=FQDN Table 26-3 Kerberos Authentication Certificate Details Attribute Kerberos Authentication Subject Empty Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2) Server Authentication (1.3.6.1.5.5.7.3.1) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) KDC Authentication (1.3.6.1.5.2.3.5) Subject Alternate Name DNS Name=FQDN-domainname DNS Name=NetBIOS-Domain-Name Table 26-2 Windows Server 2003 Domain Controller Certificate Templates Attribute Domain Controller Authentication Directory Email Replication 670 Part III: Deploying Application-Specific Solutions configure the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ Kerberos\Parameters\kdcvalidation registry value at all clients and servers. ■ 0: Disable strong KDC validation ■ 2: Enable strong KDC validation If strong KDC validation is enabled, the client will require the presence of the KDC Authenti- cation (1.3.6.1.5.2.3.5) object identifier (OID) in the Enhanced Key Usage (EKU) extension and the matching domain name in the subject alternate name of the domain controller’s certificate. Note For more details on implementing strong KDC validation, see section 3.2.4 of RFC 4556, “Public Key Cryptography for Initial Authentication in Kerberos (PKINIT),” available at http://www.ietf.org/rfc/rfc4556.txt. Windows Server 2008 Domain Controller Certificate Selection If a Windows Server 2008 domain controller has multiple domain controller certificates installed, the following rules are implemented to select which certificate is used by the server during a client authentication attempt: 1. The domain controller will use a Kerberos Authentication certificate from the local machine store. The certificate is identified by the verifying the OID of the certificate tem- plate and confirming that the KDC Authentication OID (1.3.6.1.5.2.3.5) exists in the EKU extension. The selected certificate is used for Public Key Initialization (PKINIT) authentication attempts. 2. If no Kerberos Authentication certificate exists, the domain controller searches its local machine store for a Domain Controller Authentication certificate. The certificate is iden- tified by the existence of the Smart Card Logon OID (1.3.6.1.4.1.311.20.2.2) in the EKU extension. The selected certificate is used for PKINIT authentication attempts. 3. If no Domain Controller Authentication certificate template is found, the domain con- troller will search its local machine store for a Domain Controller certificate. If found, this certificate is used for authentication connections. The selected certificate is used for PKINIT authentication attempts. 4. If no matching certificates are found, PKINIT authentication is disabled on this domain controller. Note The same selection process is used when a client attempts an LDAP/S connection to a domain controller. Chapter 26: Deploying Certificates to Domain Controllers 671 Deploying Domain Controller Certificates The method of deploying domain controller certificates is a dependency on the operating sys- tem version of the domain controllers and the operating system version of the CA. Table 26-4 shows which certificate templates are deployed to domain controllers based on the operating system of the domain controller and the operating system of the issuing CA. The method used to deploy the certificate templates depends entirely on the version of the certificate template. Automatic Certificate Request Settings Automatic Certificate Request Settings is used to deploy the version 1 Domain Controller cer- tificates to domain controllers in the forest. Although not explicitly designated as a certificate template in the Automatic Certificate Request Settings (ACRS) Group Policy Object (GPO), domain controllers are hard-coded to automatically request a certificate based on the Domain Controller certificate if it is available at an issuing CA. Note Windows 2000 domain controllers can use only version 1 certificate templates and enroll only the Domain Controller certificate template by using ACRS. Autoenrollment Autoenrollment Settings is used to automatically deploy the Domain Controller Authentication, Directory Email Replication, and Kerberos Authentication certificates to domain controllers running Windows Server 2003 and Windows Server 2008. Table 26-4 Domain Controller Certificate Template Matrix Certification Authority Version Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows 2000 Server Domain Controller Domain Controller Domain Controller Domain Controller Version Windows Server 2003 Domain Controller Domain Controller or Domain Controller Authentication and Directory Email Encryption Kerberos Authentication Windows Server 2008 Domain Controller Domain Controller or Domain Controller Authentication and Directory Email Encryption Kerberos Authentication 672 Part III: Deploying Application-Specific Solutions To ensure that autoenrollment takes place, ensure that the Default Domain Controller Policy for each domain enables autoenrollment. As shown in Figure 26-1, you must enable the Certificate Services Client – Autoenrollment Properties settings for computer objects. Figure 26-1 Enabling autoenrollment of computer certificates By enabling autoenrollment settings, you ensure that Domain Controller Authentication, Directory Email Replication, or Kerberos Authentication certificates are automatically deployed to all domain controllers. Note If multiple domains exist in the forest, ensure that each domain’s Default Domain Controllers GPO enforces autoenrollment settings. Third-Party CAs or CAs in Other Forests You do not have to deploy Microsoft CAs in a forest to deploy certificates for domain controllers. For example, if your organization has two forests (as shown in Figure 26-2), you can manually request and issue domain controller certificates to the three domain control- lers in the extranet.fabrikam.com forest from the CA hierarchy in the internal.fabrikam.com forest. Chapter 26: Deploying Certificates to Domain Controllers 673 Figure 26-2 A network deployment with two forests: internal.fabrikam.com and extranet.fabrikam.com For this example, assume that the CA hierarchy shown in Figure 26-3 is the CA hierarchy deployed in the internal.fabrikam.com forest. Figure 26-3 The internal CA hierarchy for the internal.fabrikam.com forest The deployment of domain controller certificates in the extranet.fabrikam.com forest is accomplished by completing the following steps: 1. Define the root CA from the internal.fabrikam.com forest (CN=Fabrikam Internal Root CA) as a trusted root CA in the extranet.fabrikam.com forest. internal.fabrikam.com extranet.fabrikam.com emea.internal.fabrikam.comamers.internal.fabrikam.com CN = Fabrikam AMERS Issuing CA NetBIOS Name = FABINCCA03 CN = Fabrikam EMEA Issuing CA NetBIOS Name = FABINCCA04 CN = Fabrikam Internal Policy CA NetBIOS Name = FABINCCA02 CN = Fabrikam Internal Root CA NetBIOS Name = FABINCCA01 674 Part III: Deploying Application-Specific Solutions 2. Add the subordinate CAs for the internal.fabrikam.com forest as intermediate CAs in the extranet.fabrikam.com forest. This includes the policy CA and both issuing CAs. 3. Add the issuing CAs from the internal.fabrikam.com forest to the NTAuth store in the extranet.fabrikam.com forest. This includes both the Fabrikam AMERS Issuing CA and the Fabrikam EMEA Issuing CA. 4. Configure the issuing CAs in the internal.fabrikam.com forest to accept a SAN extension in a certificate request. 5. Create the domain controller certificate requests at each domain controller in the extra- net.fabrikam.com forest. A separate request must be generated for each domain control- ler in the forest. 6. Submit the request to the issuing CA in the internal.fabrikam.com forest. Note The following procedures can also be used to request domain controller certificates from a commercial provider or from a third-party certification authority. Add the Internal Root CA as a Trusted Root CA You must designate the internal root CA as a trusted root CA in the extranet.fabrikam.com for- est. The easiest way to do this is to use the certutil–dspublish command. Assuming that the default naming was used for the root CA certificate, the command would be: certutil –dspublish –f "fabincca01_Fabrikam Internal Root CA.crt" RootCA The command will add the Fabrikam Internal Root CA as a trusted root CA for all extranet forest members. Add the Subordinate CA Certificates To allow complete trust of the certificate chain, you must add the subordinate CA certificates as intermediate CAs in the extranet forest. This requires that you run the following three certutil –dspublish commands: certutil –dspublish –f "fabincca02_Fabrikam Internal Policy CA.crt" SubCA certutil –dspublish –f "fabincca03_Fabrikam AMERS Issuing CA.crt" SubCA certutil –dspublish –f "fabincca04_Fabrikam EMEA Issuing CA.crt" SubCA The commands will ensure that all extranet forest members will recognize all CA certificates in the internal CA hierarchy. Define NTAuth Certificates To allow certificates issued by the two internal issuing CAs to be used for smart card authen- tication, the CA certificates must be added to the NTAuth store in the extranet.fabrikam.com [...]... available only on Windows Server 2008 Enterprise and Windows Server 2008 Datacenter History of NDES and Microsoft PKI NDES is not the first implementation of SCEP for Microsoft certification authorities (CAs) SCEP has previously been implemented as an add-on service for both Microsoft Windows Server 2000 and Windows Server 2003 NDES is the first native implementation of SCEP for a Microsoft CA SCEP... the certificate with the domain ■ Enable strong KDC validation only when all clients and servers are upgraded to Windows Vista and Windows Server 2008 Strong KDC validation is not supported by Windows XP, Windows Server 2003, and other earlier Microsoft operating systems ■ Generate custom domain controller certificate requests only if you do not have an existing Microsoft public key infrastructure (PKI) ... Enhancements in Windows Server Code Name ‘Longhorn’” (http://www .microsoft. com/downloads/details.aspx?FamilyID=9bf17231d832-4ff9-8fb8-0539ba21ab95&DisplayLang=en) ■ Certificate Autoenrollment in Windows Server 2003” (http://www .microsoft. com/technet/prodtechnol/windowsserver2003/technologies /security/ autoenro.mspx) ■ “Processing Domain Controller Certificates” (http://technet2 .microsoft. com/WindowsServer/en/library/d08181ca-4fac-4ca7-8171-b66e9e65606e1033.mspx?mfr=true)... controller certificates If you generate custom requests, you must manually renew and replace the domain controller certificates through their certificate life cycle Additional Information ■ Windows Server 2003 Advanced Certificate Enrollment and Management” (http://www .microsoft. com/technet/prodtechnol/windowsserver2003/technologies/ security/ advcert.mspx) ■ “Active Directory Certificate Server Enhancements... ssl-client; and to generate a server authentication key pair, run the command usage ssl -server You can create a multi-use key pair by combining usages on the same command line For example, to generate a certificate for both client and server authentication, you would run the command usage ssl-client, ssl -server ■ The device administrator must obtain an enrollment challenge password from the NDES server. .. Network Device Enrollment Service” (http://technet2 .microsoft. com/ windowsserver2008/en/library/569cd0df-3aa4-4dd7-88b8-227e9e3c012b1033.mspx?mfr= true) ■ 249125: “Using Certificates for Windows 2000 and Cisco IOS VPN Interoperation” Note The last article in the above list can be accessed through the Microsoft Knowledge Base Go to http://support .microsoft. com, and enter the article number in the Search The... CA1” part of the command 10 Copy the resulting DCRequest.cer file to the external media 11 Copy the DCRequest.cer file to the local file system of the domain controller (dc1.extranet.fabrikam.com) 12 Open a command prompt 13 At the command prompt, type certreq -accept DCRequest.cer, and then press Enter This command installs the certificate into the local machine store and ties the certificate to the... has two certificates that can be used as KDC certificates: one Domain Controller certificate and one Kerberos Authentication certificate ** KDC Certificates for DC DC1 Certificate 0: Serial Number: 6182a6ba000000000004 Issuer: CN=Fabrikam Clustered Issuing CA, O=Fabrikam Inc., C=US NotBefore: 12/16/2007 1:41 PM NotAfter: 12/15 /2008 1:41 PM Subject: CN=DC$@fabrikam.com Certificate Template Name (Certificate. .. determine whether the request is for a signing certificate, encryption certificate (0x80), or a combination signing and encryption certificate (0xa0) Note If no key usage information is provided, the NDES server will treat the request as a request for a combination signing and encryption certificate and set the key usage value to 0xa0 ■ The NDES server sends the certificate enrollment request to the CA The... being a standalone CA or the requested certificate template requiring certificate manager approval, the device administrator must send another request to the NDES server to receive the status of the requested certificate If the certificate has been issued by the CA, the certificate is returned to the device and installed on the device Implementing an NDES Server The implementation of an NDES server requires . when all clients and servers are upgraded to Windows Vista and Windows Server 2008. Strong KDC validation is not supported by Windows XP, Windows Server 2003, and other earlier Microsoft operating. Version Windows 2000 Server Windows Server 2003 Windows Server 2008 Windows 2000 Server Domain Controller Domain Controller Domain Controller Domain Controller Version Windows Server 2003 Domain. is available only on Windows Server 2008 Enterprise and Windows Server 2008 Datacenter. History of NDES and Microsoft PKI NDES is not the first implementation of SCEP for Microsoft certification