Windows Server 2016 Active Directory Certificate Services Lab Build

Transcription

1 Windows Server 2016 Active Directory Certificate Services Lab Build Prepared By: Jacob Lavender, Microsoft Premier Field Engineer Updated: 27 November 2017 This guide does not utilize a Capolicy.inf file for configuration. However, the following articles discuss these in greater detail. If you are planning a PKI deployment which is on a larger scale, utilizing this config file might be very useful. Root CA Build Guide Lab Servers ROOTCA01: Offline Root CA; Workgroup Member INTCA01: Online Issuing CA; Domain Member Note: The information provided in this guide is intended to help you get started with a basic PKI infrastructure for issuing certificates to domain joined machines. It is not a fully comprehensive guide. Each organization will have unique requirements which must be accounted for and incorporated into their own PKI. This guide is intended as a basic introduction establishing a foundation for future PKI expansion and use. Step 1 - Standalone Root CA Initial Installation Begin by building the standalone Root CA. This machine will not be domain joined. Install the Active Directory Certificates Services - Certification Authority Role.

2 After the Certificate Authority role has successfully installed, the server must then be configured. Within the Server Manager console, we will now see a post configuration task action item to complete. Select the action icon next to the notification flag at the upper right and select Configure Active Directory Certificate Services on the destination server. We will then be greeted with the AD CS Configuration screen for the Offline Root CA. Let's proceed through the wizard to finalize the post installation items for the server. 1. Credentials: We will be using the built in local administrator account. This is due to the fact that the server is an offline root CA. This means that it is not domain joined and therefore only has local accounts. Select Next at this screen to proceed.

3 2. Role Services: At the Role Services screen we must now identify which of the various role services to use. For the offline root CA, we will use Certification Authority. 3. Setup Type: At the Setup Type screen we will select Standalone CA. Again, we are selecting this option as it is an offline root CA. By definition, the Enterprise CA must be a member of an Active Directory domain. Since our offline root CA is only a member of a workgroup it is impossible for it to be an Enterprise CA.

4 4. CA Type: For CA Type we will select Root CA. This is self-explanatory due to the type of CA which we are setting up. 5. Private Key: Since this is a new deployment, we will utilize the Create a new private key option. Utilization of an existing private key is outside the scope of this guide.

5 6. Cryptography for CA: We need to use a minimum of SHA256. A critical takeaway here is to avoid using SHA1, MD5, MD4, or MD2. These cryptographic algorithms are older, weaker, and have shown signs of compromise in the past. You must select the appropriate cryptographic provider, key length, and hash algorithm for your deployment. See the following post to learn more about cryptographic providers: For this deployment we, will utilize: 1. Cryptographic Provider: RSA#Microsoft Software Key Storage Provider 2. Key Length: Hash Algorithm: SHA256 At the time of writing this guide, these meet all public requirements. However, as a CA administrator/engineer, ensure that you keep track of current developments regarding acceptable PKI implementations.

6 7. CA Name: For the offline root CA, we will utilize the default naming context. However, if you require your offline root CA to have another common name, provide it at this screen. 8. Validity Period: The validity period for the certificate which will be generated for the offline root CA is dependent upon your organizational requirements. For the purpose of this guide, and due to the fact that this build exists within a lab, I have opted to use 20 years. However, in a real-world

7 scenario there are additional considerations and constraints that factor into making this determination: o It is recommended that you consult with a local Cyber Security technician to determine if there is an established recommendation/guideline/requirement for this setting. o The shorter the validity, the sooner you'll have to issue a new CA chain. o The longer the validity, the higher the probability that the chain can be compromised. o If you anticipate that the root CA will be replaced/upgraded in the future, plan to keep the validity period for at least 1 year after that projected date. This allows you some flexibility within your upgrade project to ensure that your root CA's certificate does not expire prior to implementing a new CA chain with a new root CA. 9. CA Database: We must now specify the path for the CA database. Considering that this is an offline root CA, utilizing the default location is likely acceptable. Since this CA should only issue certificates to intermediate CA's on a very irregular basis, the drive on which the DB and Logs reside do not need to be high performance drives. o PFE Pro Tip: I always recommend that any system that homes a DB, and thus transaction logs (TLOGS), have a dedicated drive for the DB and a separate dedicated drive for the TLOGS. However, each scenario must be evaluated to determine if this is necessary. Systems with low IO do not mandate this. However, systems with high IO should be configured with this at a minimum. Additionally, if the system is a virtual machine, each of these drives should utilize a dedicated storage controller for each drive; sharing a single storage controller can result in poor performance even with dedicated drives. o Example: i. C: = System Drive with OS and Programs ii. D: = Database Drive iii. T: = Transaction Log Drive

8 10. Confirmation: We have now arrived at the Confirmation page. This is the final screen prior to implementing the configuration for the offline root CA. Validate that the settings on this page are accurate, correct, and sustainable. Once we configure the offline root CA, it will be difficult, if not impossible, to make changes. If all the settings are correct select Configure.

9 11. Progress: The Progress screen should briefly appear as the CA is configured. It should then proceed to the Results screen. 12. Results: At the Results screen, we should receive Configuration Succeeded. If any other result was received, review the output for the configuration transaction and make the necessary corrections. Specifics are outside the scope of this guide. Step 2 - Standalone Root CA Certificate Export Having performed the initial Root CA setup, we now have some specific action items that we must take for the offline root CA post setup. Let's start by exporting the offline root CA's certificate. This will be required for a couple of items later as we setup the Intermediate CA and the Certificate Trust Chain within Active Directory Domain Services. 1. Within Server Manager, select Tools, then select Certification Authority. 2. We should now have the Certificate Authority snap-in open. 3. Right-click the certification authority name, and select Properties.

10 4. We are now presented with the ROOTCA01-CA Properties window. 5. On the General tab, we will see the offline root CA's certificate. Select View Certificate. 6. Then select the Details tab. 7. Then select the Copy to file radio button. This will allow us to export the offline root CA's certificate. This certificate is required to establish and deploy the trusted root chain within the Active Directory domain. This is addressed later in this guide. 8. Welcome to the Certificate Export Wizard: We are now presented with the certificate export wizard which will guide us through exporting the offline root CA's certificate. This wizard will allow us to save the certificate in a.cer format which we will later use to distribute within the Active Directory domain. At this screen select Next.

11 9. Export File Format: We need to export the file in a DER encoded binary X.509 (.CER) format. For trust chain establishment and distribution, we do not require any additional values of the offline root CA's certificate.

12 10. File to Export: Specify the file name. In other words, identify the path to which we need to save the.cer file along with the name that we are going to assign to the.cer file. o PFE Pro Tip: i. Create a folder on the server, such as C:\Software, which you can utilize for saving files which you need to retain. Some admins create a folder called C:\Temp. I leave this to your discretion within your organization. However, having a common path on all servers for this purpose is valuable. This ensures that all administrators are saving data into non-profile specific locations. This becomes extremely valuable in specific scenarios which at present are beyond the scope of this guide. ii. Utilize Value Added File Names. As an example, for the offline root CA, I would name the exported certificate file as ServerName_Date_VersionNumber.cer. See the screenshot for a graphic example. By doing so, we ensure that we clearly understand what this file is. Certificate naming format is critical. As you begin to deal with many certificates over an expanding period-of-time, having a sustainable and easily understood naming context will greatly simplify your work. Extend this same naming framework to the Friendly Name for certificates.

13 11. Completing the Certificate Export Wizard: This screen will validate all the prior options for exporting the certificate. Select Finish.

14 Step 3 - Standalone Root CA Security Configuration By default, the Root CA provides more permissions than we would like to see. While this is a stand-alone CA, and not joined to a domain, let's take an easy step to slightly bump security up. 1. On the Security tab of the root CA's properties window, let's remove the Everyone group. Complete this by Selecting the Everyone group and then selecting Remove.

15 2. We should be left with simply Administrators within the Security tab. Let's select Allow Read and Allow Request Certificates.

16 3. Auditing: ALL EFFECTIVE SECURITY POSTURES INCLUDE AUDITING. Auditing is a critical component of security. Without auditing, we have no effective means to view historical transactions. In respect to our topic, enabling an effective auditing policy is required. Auditing provides us a method by which we can see the historical behavior on our systems. Let's review some caveats: a. First, this is an offline root CA. Auditing it provides insights into the actions which occur on the CA. However, we will be challenged to export the audit data from this server. In your environment you may want to consider how you plan to export, and SECURE, the audit data from the offline root CA. The audit data alone is valuable to an enterprise adversary in that it provides insight into your infrastructure. Protect your logs. b. As a stop gap, I strongly recommend that you identify a means within your environment to track when the offline root CA is powered on/modified. That is to say, if the offline root CA is a virtual machine, how have you secured the virtual machine to prevent export and exfiltration of the VM itself and ensure that that data within the VM is encrypted and secure? HOW ARE YOU SECURING YOUR VIRTUAL INFRASTRUCTURE? This is a critical

17 question that expands beyond the scope of this guide and into the enterprise services scope, such as Active Directory Domain Services, as well as other critical infrastructure services (think DNS, DHCP, etc.). If the machine is a physical machine, what physical safeguards are in place to secure the CA? Closing the Gap: Why did we perform this? First, we are eliminating the possibility of any user other than an offline root CA administrator from performing functions against the offline root CA. Second, we are ensuring that administrators on the offline root CA are not inhibited from performing their tasks. I recommend that you review the built-in Administrators security group of the offline root CA to validate that there are not any unauthorized members within this group. Security Consideration: The offline root CA is the base/root/core of the PKI trust chain. If the root CA is compromised then the entire chain has been compromised and in turn, every certificate which has been issued within the root CA's chain is therefore compromised and no longer valid. This means that every certificate must be revoked, an updated certificate revocation list (CRL) must be published, and every certificate must be replaced with a new certificate from a new certificate chain. In a large organization this could theoretically be impossible, not to mention the financial implications of this. Protect the Root CA. Let me say that one more time. PROTECT THE ROOT CA! At the time of writing this guide, the following article had been published: Securing PKI: Planning a CA Hierarchy: I highly recommend that you review the details and guidance provided within this publication. PKI is one of the most critical components of any enterprise. Failure to properly secure and protect the PKI can, and likely will, result in a security incident. Step 4 - Standalone Root CA Extensions and Properties After finalizing the post deployment tasks, the location for the CRL Distribution Point needs to be configured. We can store this data in two places. First, we can store it within Active Directory by importing the CRL into the LDAP CDP. The second location is on the Intermediate CA within its CDP. We will configure both. Target Configuration - CRL Distribution Point (CDP) Extension: C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl o Publish CRLs to this location o Publish Delta CRLs to this location ldap:///cn=<catruncatedname><crlnamesuffix>,cn=<servershortname>,cn=cdp,cn=public Key Services,CN=Services,CN=Configuration,DC=srv,DC=lab<CDPObjectClass> o Include in all CRLs. Specifies where to publish in Active Directory when publishing manually. o Include in the CDP extension of issued certificates.

18 o Include in CRLs. Clients use this to find Delta CRL locations. o Include in the CDP extension of issued certificates. Authority Information Access (AIA) Extension: C:\Windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.cr t Ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=srv,DC=lab<CAObjectClass> o Include in the AIA extension of issued certificates o Include in the AIA extension of issued certificates o Critical Note: There is an underscore "_" between <ServerDNSName> and <CaName>. That is not visible with the hyperlink. o Without Hyperlink " CertEnroll/<ServerDNSName>_<CaName> " PFE Notes: If you intend of utilize a highly available HTTP CDP location then you may use a DNS name that will be configured in a load balanced array or DNS Round Robin configuration for both the HTTP CDP and AIA extensions. Why might I wish to do this? Not everything that utilizes a CA may be able to query LDAP. In turn, the CDP and AIA information should be available to clients that instead will utilize HTTP. PFE Field Feedback: Why is the CDP and AIA HTTP location not secured with SSL? I've been asked this a few times. Let's first establish what the HTTP CDP (CRL Distribution Point) location is doing. Its use is to validate the revocation status of certificates. A client will connect to the CDP to validate that a certificate assigned to a service it is attempting to access is valid. If the CDP location were secured with SSL then the client would then have to validate the CDP HTTP service's certificate. However, it would not be able to as the CRL is within the HTTP CDP path. This in turn would result in revocation failing. Well, why not use an external CA with an external CDP location to validate the HTTP CDP SSL certificate status? You would not want to do this. It means that you must rely on a third party for you and others to validate your PKI, thus allowing a third party to interfere with your established PKI. Additionally, that would be over HTTP as well. Finally, the data that we are transferring through calls to the CDP does not require protection. We want it to be public and accessible. If you would like to read further about configuring HA for the HTTP AIA and CDP Repositories the following blog is a good start:

19 Also, if you intend to use your PKI to issue certificates which will be used for externally available services, such as services located within the DMZ, you will need to consider how you plan to setup an external CDP or OSCP Responder. That is beyond the scope of this guide. Begin by opening the Certification Authority MMC Snap-in. Once opened right click the CA and select Properties. At the Root CA properties window select the Extensions tab. By default we are presented with the following: Let's remove everything except the file path. We are doing this as this is going to be an offline Root CA. The path defined in the last two values will not be valid as the server is offline. We should be left with the following settings:

20 4. Now, we need to add the path to the CDP located on the Intermediate CA. (We will build that CA later in this guide.) For our purposes, the Intermediate CA's name will be INTCA01.SRV.LAB. Therefore, the path will be: a. b. Note: We are able to add this path on the Intermediate CA due to the fact that we are also going to install the Web Enrollment role service on the Intermediate CA server. However, if you opt to separate the web enrollment role service onto another machine, you will need to use a valid path to that machine. Alternatively, this path can be any valid internal web address. It does NOT have to be located on the Intermediate CA, we re just opting to do that in this lab scenario. c. If you would like to read further about configuring HA for the HTTP AIA and CDP Repositories the following blog is a good start:

21 i. Add the path by selecting the Add radio button. Select Ok once completed. e. Once we have returned to the Root CA Properties screen, and we are still on the Extensions tab, update the new path to include: i. Include in CRLs. Client use this to find Delta CRL locations. ii. Include in the CDP extensions of issued certificates. f. We must also add the LDAP path. We are going to perform this manually as we want to also publish the CRL into Active Directory. a. ldap:///cn=<catruncatedname><crlnamesuffix>,cn=<servershortname>,cn=cdp,cn= Public Key Services,CN=Services,CN=Configuration,DC=srv,DC=lab<CDPObjectClass> i. Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually. ii. Include in CRLs. Clients use this to find Delta CRL locations. iii. Include in the CDP extension of issued certificates.

22 g. We now need to add a new location for the Authority Information Access (AIA). On the extensions tab under Select Extension:, ensure that the Authority Information Access (AIA) extension is selected.

23 8. Now, again, let's remove all paths except the file path location so that we are left with the following:

24 9. We now need to add the path to the AIA locations: a. i. Remember, there is an underscore "_" between <ServerDNSName> and <CaName>. ii. Include in the AIA extension of issued certificates. b. Ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=srv,DC=lab<CAObjectClass> i. Include in the AIA extension of issued certificates.

25 If you wish to validate that you have configured the CRT path name correctly, browse to C:\Windows\System32\CertSrv\CertEnroll. There you will find the CA's CRT file:

26 j. Now, we must update the CA's CRL publication interval. We perform this by right-clicking the Revoked Certificates node and selecting Properties. 11. Update the CRL Publication Interval to an appropriate length of time for your environment. PFE Notes: The offline root CA should only be brought online when it is necessary to renew or issue new certificates for the issuing CAs. This means that you should not have a short publication interval. If your publication date expires without publishing a new CRL from the CA then CRL checks for any certificate issued by the Root CA will fail. In this lab, we will configure the interval for 1 year. This means that within 1 year I must bring this CA back online and publish a new CRL. This setting can be easily changed.

27 Delta CRLs are published in between CRL publications. For the offline root CA this should not be necessary as we will ALWAYS publish a new CRL when we issue/revoke certificates from the offline root CA. 12. We must now publish the CRL. Right click the Revoked Certificates node and select All Tasks and then Publish. At the Publish CRL screen select New CRL and then select Ok. a. The CRL is located at C:\Windows\System32\CertSrv\CertEnroll.

28 13. Now, copy the contents from C:\Windows\System32\CertSrv\CertEnroll to the same location that the exported Root CA certificate was saved from Step 2 of this guide. Copy the all three items to the Intermediate CA. a. Root CA CRT File b. Root CA CER File c. Root CA CRL File Step 5 - Standalone Root CA Issuance Term By default, the Root CA will issue certificates for 1 year only. This creates an issue in that the subordinate CA certificate will be restricted to 1 year. In turn, this means that the subordinate CA can never issue a certificate which is older than its own. Ultimately, this is not ideal in that it will result in a high rate of turnover of certificates via expiration and reissuance. The two keys in the registry that we are specifically interested in are: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ ValidityPeriod HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ ValidityPeriodUnits To resolve this issue, we must extend the issuance term of the root CA. We can perform this by utilizing the certutil command. This command is built into Windows Server and no additional software/feature is required. First, let's review what the settings are to begin with. We can do this at the administrative command prompt. 1. Run the following command to determine the current value for the issuance length. We can see in the example below that the value is 1. This period is too short for our use so we will increase this. Certutil -getreg ca\validityperiodunits

29 2. The following command will allow us to see the type of time used to determine the validity duration. We can tell from this output that the time is measured in years and therefore does not require a change. Certutil - getreg ca\validityperiod 3. Run the following command to increase the validity period. In this lab I am increasing the period to 5 years. Certutil -setreg ca\validityperiodunits 5 Note: You should restart the CA server. Subordinate CA Build Guide Lab Servers ROOTCA01: Offline Root CA; Workgroup Member INTCA01: Online Issuing CA; Domain Member Note: The information provided in this guide is intended to help you get started with a basic PKI infrastructure for issuing certificates to domain joined machines. It is not a fully comprehensive guide. Each organization will have unique requirements which must be accounted for and incorporated into

30 their own PKI. This guide is intended as a basic introduction establishing a foundation for future PKI expansion and use. Step 6 - Subordinate CA Initial Installation Note: To standup the Enterprise Subordinate CA, the account used to perform the install must be a member of the Enterprise Administrators group. Begin by building the subordinate CA. This machine will be the intermediate CA which will be used to issue certificates to machines within the Active Directory domain. Install the Active Directory Certificates Services - Certification Authority role service as well as the Certificate Authority Web Enrollment role service. In respect to the machine's name, ensure that it is sustainable and will not require any modification. Once the role has been installed you will not be able to change its name. PFE Pro Tip: Ensure that your naming conventions are meaningful and can stand the test of time. Remember, this is likely not the last time you will setup a server performing this function. Therefore, ensure that the next server in line can easily be brought into the naming context allowing for a consistent management approach. PFE Notes: In some environments it is best to install the Certification Authority Web Enrollment role service on separate dedicated machines. If additional security is required to segregate the CA from the web traffic required for Web Enrollment, consider doing this. However, this determination will need to be made locally based on local security requirements and guidance. On the Subordinate CA server (INTCA01) install the following Roles and Role Services: Role: Active Directory Certificate Services Role Services: Certification Authority Certification Authority Web Enrollment Begin by installing the Active Directory Certificates Services role within Server Manager. No additional features should be added - allow the defaults to remain in place.

31 At the role services screen, ensure to select Certification Authority & Certificate Authority Web Enrollment. You will be prompted to accept the addition of the IIS role and services. Select Add Features. Finally, select Next.

32 After the role has been installed, complete the post deployment tasks. 3. Proceed through the remaining windows and select to Install the role and all necessary features. 4. We must now complete the post deployment tasks associated with having installed the CA. In the top right of Server Manager we should see a notice for action. Select Configure Active Directory Certificate Services option.

33 5. We will be presented with the AD CS Configuration Credentials screen which will require that an Enterprise Admin user is provided: 6. At the Role Services screen, select to configure both Certification Authority & Certification Authority Web Enrollment.

34 7. This server is going to be an Enterprise CA. 8. This server is going to be a Subordinate CA. It will be a subordinate of the offline Root CA. 9. This server will require a new private key.

35 10. For this deployment, the CA will require a minimum of SHA At the Specify the name of the CA, determine if you need to modify the name. For this lab I have removed the "srv-" (Domain NETBIOS Name) text from within the CA name.

36 12. At the Certificate Request screen, we are going to save a file to send to the offline root CA. In this case we must use a request file due to the root CA being offline. If the root were online, we could send the file directly to it. 13. On the CA Database screen validate the path to which the DB and Logs need to be installed. On systems that are going to receive a high demand, it is recommended to consider providing a

37 dedicate drive for both the DB and Logs. If the machine is virtual, provide a dedicate virtual SCSI controller to each of the drives. 14. At the Confirmation screen validate all the settings are correct and then select Configure. 15. You should see the following screen then appear to configure the server:

38 16. The Results page should display. Take note of the location where the certificate request (.REQ) file was saved. This file is required to move to the offline root CA to complete the intermediate certificate request. At this point, we can select Close.

39 Step 7 - Issue the Subordinate CA Certificate To complete this step we must move the certificate request file from the intermediate CA to the offline root CA. After having moved it, continue with the guided steps below. 1. We will begin by opening the Certification Authority manager from Server Manager. Once it is open, right click the Root CA, select All Tasks, then select Submit New Request. 2. We will be prompted to browse and provide the request file from the intermediate CA. Locate the file and select Open. 3. The request will now be pending in the Pending Requests node. Right click the request, select All Tasks, then select Issue.

40 4. The new certificate will now be located within the Issued Certificates node. That certificate should have a validity period of the number of years that was defined within Step 5 of the Root CA Build. 5. We must now copy the issued certificate to a file and move it to the intermediate CA. You can perform this by double-clicking the certificate and then on the Details tab, select Copy to file. Proceed through the wizard to copy the certificate to a file and then move it to the intermediate CA. Copying the file in.p7b format is required. Ensure that you select Include all certificates in the certification path if possible. 6. We must also issue a new CRL. Perform this by right clicking the Revoked Certificates node and selecting Publish. Ensure that the CRL is copied to the intermediate CA as well. 7. Having moved the intermediate CA's certificate to that machine, let's now complete the certificate install. Within the certification authority management console, right click on the CA, select All Tasks and then select Install CA Certificate. 8. Within the wizard browse to the location of the P7B file copied from the offline root CA and select Open. a. You will receive an error stating that the revocation of the certificate cannot be validated at this time because the CDP offline. This is expected at this step. We have not placed the CRL from the offline root CA into the CDP yet. We will perform this step next. Select Ok to proceed through the error. 9. Copy the offline root CA's CRL and the.crt certificate file to the CDP location on the intermediate CA. This is the CDP location which we defined within the CDP extension on the offline root CA. See Step 4 from the Root CA Build guide.

41 C:\Windows\System32\CertSrv\CertEnroll 10. Return to the Certification Authority management console on the intermediate CA, right click the CA, select All Tasks, then select Start Service. The CA should now come online. Step 8 - Configure the Intermediate CA Extensions The intermediate CA has predefined extensions, the same as the offline root CA had. Updating these extensions is required to ensure that devices which are unable to query via LDAP can perform an HTTP CRL validation check. Fortunately, this is a simple step as we do not have to make any additions, but rather enable options. If clients require checking using SMB then the file extension may be required. Evaluate the requirements within your environment to determine if this extension is required. 1. Within the Certification Authority management console, open the properties for the CA, and select the Extensions tab. Ensure that the CRL Distribution Point (CDP) extension is selected, and then highlight the default http extension, as shown below:

42 1. Place a check in the following two options, and then select Apply. Select Yes when prompted to restart the AD CS service. a. Include in CRLs. Clients use this to find Delta CRL locations. b. Include in the CDP extension of issued certifications.

43 3. Next, we need to include the additional AIA location. Change the extension type to Authority Information Access (AIA) and select the http extension as shown below:

44 4. Place a check in the Include in the AIA extension of issued certificates option and then select Apply. Select Yes when prompted to restart the AD CS service.

45 Intermediate CA Post Installation Tasks Having completed the basic setup of the intermediate CA, we now have a few items that we should address. 1. Review the auditing configuration of the CA. Enable auditing on the Auditing tab. 2. Review the Security settings for the CA. By default, the CA may provide additional permissions that some environments may not wish to allow. 3. Define the Enrollment Agents for the CA. This is not necessary, but recommended. 4. Define the Certificate Managers for your organization. 5. Remove all default published certificates. Complete this on the Certificate Template node within the Certification Manager console. You can complete this by selecting the templates, right clicking, and selecting Delete. Don't worry, you re just removing the publication from the CA. The Template itself is stored in Active Directory and we're not deleting those.

46 Why would I want to delete the published templates? Best practice is to duplicate the default templates, customize the duplicate, and then publish it. Additionally, we don't want to publish templates that we don't intend to use. AD Certificate Services PKI Configuration Lab Servers ROOTCA01: Offline Root CA; Workgroup Member INTCA01: Online Issuing CA; Domain Member Note: The information provided in this guide is intended to help you get started with a basic PKI infrastructure for issuing certificates to domain joined machines. It is not a fully comprehensive guide. Each organization will have unique requirements which must be accounted for and incorporated into their own PKI. This guide is intended as a basic introduction establishing a foundation for future PKI expansion and use. Step 9 - Load Offline Root CA Certificate and CRL to Active Directory We must now load the offline root CA's certificate into Active Directory. We will utilize the CERTUTIL command to complete this step. 1. On the intermediate CA, open an administrative command prompt. Browse to the location where the offline root CA's.CER file is and execute the following command to load the certificate into Active Directory: Certutil -f -dspublish <OfflineRootCA.CER_FileName> RootCA Certutil -f -dspublish RootCA01-CA_19Jan2017_v1.cer RootCA 2. At the same administrative command prompt, execute the following command to load the CRL into Active Directory: Certutil -f -dspublish <OfflineRootCA.CRL_FileName> <RootCA Short Name> Certutil -f -dspublish ROOTCA01-CA.crl ROOTCA01

47 Note: I have seen where an error might occur during the publication of the Offline Root CA CRL into Active Directory: LDAP_NO_SUCH_BOJECT. This is due to the fact that the Offline Root CA container is not created within the CDP container. You must ensure that the Root CA Short Name is included in the command, otherwise you may receive this error. The command will create the correct container within the Active Directory configuration partition. 3. To validate that the PKI is configured correctly, open the Enterprise PKI mmc snap-in on the intermediate CA. It may take a moment to open. Once it does, there should not be any red. If you receive errors review the specific issue and reference this guide to resolve them. 4. Next, right click Enterprise PKI and select Manage AD Containers. You should find: a. The Intermediate CA certificate populated into the NTAuthCertificates container. b. The Intermediate CA and the Root CA certificates populated into the AIA container. c. The Intermediate CA and the Root CA CRLs and Delta CRL within the CDP container. d. The Root CA certificate within the Certification Authorities container. e. The Intermediate CA certificate within the Enrollment Services container. 5. You may also view this via ADSI Edit. Open ADSI Edit and connect to the Configuration Partition:

48 6. Browse to the following path: Configuration > CN=Configuration,DC=srv,DC=lab > CN=Services > CN=Public Key Services

49 Distributing Certificates Lab Servers ROOTCA01: Offline Root CA; Workgroup Member INTCA01: Online Issuing CA; Domain Member Note: the information provided in this guide is intended to help you get started with a basic PKI infrastructure for issuing certificates to domain joined machines. It is not a fully comprehensive guide. Each organization will have unique requirements which must be accounted for and incorporated into their own PKI. This guide is intended as a basic introduction establishing a foundation for future PKI expansion and use. Step 3 - Distribute the Root CA Certificate for Trust

50 At this point, we must distribute the Root CA certificate to all machines within the domain as a trusted Root CA. This is necessary so that all clients will trust the entire certificate chain. There are two methods to perform this function. Method 1 - Utilize a GPO to distribute the certificate. To complete this method, select/create an appropriate GPO and add the certificate to the GPO for distribution. This is located at: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities At the Trusted Root Certification Authorities node within the GPO, right click the node and select Import, then browse to the Root CA's certificate and select it. Method 2 - Utilize Certutil to load the certificate into the Certification Authorities Container in Active Directory. To complete this method, open an administrative command prompt and ensure that the working folder is C:\Windows\System32. Utilize the following command to install the Root CA's certificate (this should already be located on the Intermediate CA as it was copied earlier in the process to install): o Certutil -f -dspublish <cert_file_name> RootCA o Certutil -f -dspublish C:\Software\RootCA\RootCA01_cert.cer RootCA You can verify that this method was successful by using the Enterprise PKI MMC snap-in. At the very least, this should be opened to determine if there are any old CA's which should be removed from this AD container. On the Intermediate CA, add the Enterprise PKI snap-in to MMC. Once it is open, it will immediately fail to connect to the Root CA. This is expected. Right click the Enterprise PKI node and select Manage AD Containers. Select the Certification Authorities Container The Root CA certificate should appear in this container If there are any invalid certificates loaded in this store they should be removed Consideration: The advantage to using a GPO is twofold. First, it is easily repeatable and takes very little in depth knowledge to perform. Second, it allows for targeted deployment of the certificate. The advantage to installing the Root CA certificate in the Certification Authorities Container is that it is distributed to every member of the domain without regard to GPO. This ensures that even machines which block inheritance receive this certificate. Finally, if you perform both of these methods, the certificate will appear twice in the certificate store on any machine which receives the root certificate via GPO as well. This does not hurt anything. In both cases, if an administrator removes the certificate it will be reinstalled on the machine. It is recommended to select only one method and proceed with distributing the Root CA certificate within the domain. At this time, the Root CA may be shut down and disconnected from the network.

51 Security Considerations: Physical access to the Root CA, (virtual or physical machine) constitutes full control of the certificate chain. The machine should be highly protected. Ensure that the username and password have been safely stored. It is recommended that the password is not used in any other location and is stored in a safe with restricted access. Step 4 - Create and Publish Certificate Templates There are two locations to manage certificate templates: First, Within the Certification Authority Certificate Templates node. This is where you publish certificate templates. However, you DO NOT modify the template in this location. Deleting a template from this location simply means that it is no longer published. However, the template itself is not deleted. Second, the Certificate Templates Console. This is where you modify the certificate templates themselves. This is also where you can delete a template. You can get to the Certificate Templates Console from the Certification Authority Console by expanding the tree and right clicking Certificate Templates and selecting Manage.

52 Operating rule: Always Duplicate a template for publishing. Do not use the default templates that are pre-populated within the Certificate Templates Console. You cannot modify the default templates that are provided and therefore are unable to customize the templates to your needs. Let's start by reviewing the certificates which are already published. As a practice, do not publish certificate templates that you do not intend to use. Remove all published templates from within the Certification Authority Templates node by right clicking the template and selecting Delete. After deleting the published template, browse to the Certificate Template Console. You will see that the template is still there. This is because the template itself was not deleted, only that it is no longer published through the CA. Within the Certificate Templates console, duplicate the following templates: Computer Domain Controller Domain Controller Authentication Workstation Authentication Web Server Right click the template and select Duplicate:

53 Lab Duplicate Template Names: Published Remote Desktop Authentication v1 Published Domain Computers v1 Published Web Server v1 Published Workstation Authentication v1 Published Domain Controller Authentication v1 Published Domain Controllers v1 I recommend that you include within the name of the template an identifier that specifies that the template is published and what version it is. If you don't do this, it will become difficult to troubleshoot certificate issues in the future. Once the duplicate template properties page comes up, select the General Tab and provide a valid name. Example: Published Domain Computers v1

54 Ensure that the following properties have been updated: General Tab o Validity Period o Renewal Period Compatibility Tab > Compatibility Settings o Certification Authority: Windows Server 2012 R2 o Certificate Recipient: The oldest operating system that would receive a certificate. Recommend Vista/Server Request Handling Tab (Optional) o Allow private key to be exported (selected) Subject Name Tab > Build from this Active Directory information o Subject Name Format: DNS name o Include this information in alternate subject name: DNS name Issuance Requirements (Optional) o CA certificate manager approval - This will require that a CA manager approve all requests. For all domain machines, this is likely not desired. This is likely only desired for specific types of certificates, such as Web Server certificates. Superseded Templates o Certificate Templates: Computer o This will state that the new template that we are creating is identified as the predecessor of Computer. This will give priority to this template. Security o Domain Computers: Autoenroll = Allow o NOTE: If the certificate template is for Domain Controllers, only allow the Domain Controllers group to Autoenroll. Note: To Create a Remote Desktop Authentication Template: Duplicate the Published Domain Computers v1 template. Add the Remote Desktop Authentication Application Extension by: Extensions Tab Application Policies Edit Remote the Client and Server Authentication Extensions Select Add New Name: Remote Desktop Authentication Object Identifier: OK OK OK

55 See the GPO requirements for this template in Step 5. Note: For the Duplicate Web Server template: Ensure that the option to allow Export the Private Key is selected. This will ensure that the certificate can be used on Web Server Farms if desired. Ensure that the Subject Name is configured to Supply in the Request. Often web sites do not use the name of the server and therefore the requestor must submit the name. Ensure that CA certificate manager approval is required (Issuance Requirements Tab). This will ensure that web servers are not created and issued a certificate without proper authorization. Once the template has been created, publish the certificate on the Certification Authority. Do this by right clicking Certificate Templates, select New then Certificate Template to Issue. Then select the template from the list. Step 5: Configure Domain for Certificate Auto-Enrollment via GPO For this step, select a GPO to create/modify and add the following settings:

56 Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies o Certificate Services Client - Auto-Enrollment Configuration Model: Enabled Select - Renew expired certificates, update pending certificates, and remove revoked certificates Select - Update certificates that use certificate templates o Certificates Services Client - Certificate Enrollment Policy Configuration Model: Enabled Use the default of Active Directory Enrollment GPO Requirements for Remote Desktop Authentication Template: To Ensure that a Remote Desktop Authentication Certificate is used, which is issued by the CA, configure the following policy setting: Computer Configuration > Policies > Administrative Templates > Remote Desktop Services > Remote Desktop Session Host > Security: o Server Authentication Certificate Template: Remote Desktop Authentication Certificate Template Name General Notes On a server with Remote Desktop Connections allowed, run the following command to obtain which certificate is currently in use by the Remote Desktop Service: Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"