I am having an issue with Word’s Table of Contents. This file was working correctly until a couple of months ago. I use RD to reference 5 different word documents to create the Table of Contents and use heading styles in the individual documents to control what is listed on the Table of Contents.

As of right now, every heading is being shown on being on page 1 in each document. As seen in the image, this is from page 2 of one of the individual documents but in the TOC document, it shows page 1. Any suggestions on how to fix this?

​I am having an issue with Word’s Table of Contents. This file was working correctly until a couple of months ago. I use RD to reference 5 different word documents to create the Table of Contents and use heading styles in the individual documents to control what is listed on the Table of Contents.As of right now, every heading is being shown on being on page 1 in each document. As seen in the image, this is from page 2 of one of the individual documents but in the TOC document, it shows page 1. Any suggestions on how to fix this?    Read More

​

Hey, Brent here from the Windows Directory Services team! So, I wanted to share with you some interesting stuff about using one PKI (Public Key Infrastructure) certificate for your Windows Active Directory Domain Controller. It’s simple and can save you many headaches in the long run.

Let me explain what a Windows domain controller is in case you don’t know. It’s a server computer system that controls how devices and users can authenticate to and access a Windows Active Directory domain network. It uses a digital certificate to prove who it is and who its clients are when granting access to the Windows domain. But using different certificates for different things can be tricky and expensive, especially when they need to be changed or revoked. In this document, we will tell you why it is better to set up a Windows domain controller to use one PKI issued certificate instead of many, and how to make the Windows domain controller use one PKI certificate for modern authentication.

Why use one PKI Certificate?

For starters, it makes management a whole lot easier. You only need to request, enroll, renew, and if necessary, revoke one certificate instead of juggling multiple ones used for different purposes. This makes sure that your Windows domain controller can work with new ways of logging in, like smartcards, OAuth 2.0, and Windows Hello for Business (WHfB). Plus, it can save you some cash if you’re using certificates issued from a non-Microsoft Windows Certificate Authority. Let’s also not forget, it is more secure because you only need to protect one private key instead of multiple ones.

What does this one PKI Certificate need?

So, if you want to make a Windows domain controller use only one PKI certificate for modern authentication, you need to get a PKI certificate that has these features:

1. It has a name (Subject Alternative Name) that matches the DNS (Domain Name System) name of the domain.  These are added during the enrollment using the MMC or with a custom request. 
For Example:  Subject Alternative Name 

        DNS Name=2022DC01.FourthCoffee.com 

        DNS Name=FourthCoffee.com 

        DNS Name=FOURTHCOFFEE

2. It can perform digital signature and key encipherment, which are part of the Key Usage (KU) extension. It can do client authentication, server authentication, smartcard logon and KDC (Key Distribution Center) authentication, which are part of the Enhanced Key Usage (EKU) extension. (Note: If you are using Windows Server Enterprise Certificate Authority, you don’t have to worry about these extensions because they are already in the Kerberos Authentication certificate template).

3. It is valid for as long as you need it for your organization.

4. It is issued by a PKI Certificate Authority (CA) that your Windows domain controller and its client systems trust. The certificate template must have an extension encoded with the value of DomainController, encoded as a BMPstring. (Note: If you are using a Windows Server Enterprise CA, the extension is already in the Kerberos authentication certificate template).

How are things setup by default?

Active Directory Certificate Services (ADCS) makes three different kinds of certificates for domain controllers by default: Domain Controller, Directory Email Replication, and Domain Controller Authentication. 

1. Domain Controller template (from Windows Server 2000) has EKUs for client and server authentication, and that’s it.  The KDC service will use any certificate with the template name of DomainController for smart card logon.  All domain controllers are hard coded to automatically enroll for a certificate based on the Domain Controller template if it is available for enrollment at a certificate authority in the forest. Hard coded in this case means it is in the code, it is not configured in any local or domain-based policy. This is one of the few cases where Windows will auto-enroll for a certificate without auto-enrollment being configured in Group Policy.

2. Domain Controller Authentication template has EKUs for client and server authentication as well as smart card logon. This one came with Windows Server 2003 and it can use autoenrollment, which is a version 2 feature. 

3. Directory Email Replication template is not for smart card logon purposes, but for sending Active Directory data over email. But almost nobody does that anymore, they use RPC (Remote Procedure Call) instead as the transport method for Active Directory replication, so you don’t really need this one. 

The problem is that both the Domain Controller and Domain Controller Authentication certificates are too old to work with the new Kerberos rule that says Key Distribution Centers (KDCs) need to have the KDC Authentication extension. So, Windows ADCS has a newer and better certificate template for use by domain controllers, named Kerberos Authentication. It has everything you need: client and server authentication, smart card logon, and KDC authentication. 

When a Windows domain controller discovers a Windows PKI CA in the Windows Active Directory Forest, it will automatically enroll for a certificate using the Domain Controller and Directory Email Replication template, if these templates are published. That means, the domain controller might have at least one computer certificate in its personal store for authentication as a client or a server. So, any certificates that the domain controller already obtained using the old templates need to be replaced by the Kerberos Authentication certificate (or the custom one you made with the same requirements). 

How to configure the Kerberos Authentication Template?

When using a Windows PKI Enterprise CA, you can consolidate the Windows domain controller certificate as follows:

1. Logon to a Windows Enterprise CA and open the Certificate Authority management console using Server Manager and select Tools -> Certificate Authority. 

2. Expand the Windows Enterprise CA object, right-click on the Certificate Templates folder and then select Manage (as shown below): 

3. Find and open the Kerberos Authentication template by right-clicking on it and select Properties.

4. Configure the validity and renewal periods in accord with your organizational requirements. (Bear in mind that you cannot extend past the lifetime of the CA’s certificate).

5. Select the Superseded Templates tab and add the Domain Controller, Domain Controller Authentication, and Directory Email Replication templates and any other custom domain controller templates to the list. 

6. Click the Apply button and then the OK button to exit the template properties page.

Remember, supersedence is used when you want to replace certificates that have already been issued with a new certificate with modified settings. 

Certificate Template supersedence is used by the certificate autoenrollment component only.  When you do manual enrollment and/or existing certificate renewal, supersedence is not considered and requires the exact template to request/renew.

7. To ensure the above superseded templates (Domain Controller, Domain Controller Authentication and Directory Email Replication) are not shown as available during certificate enrollment, delete them from the enterprise CA servers by selecting each template under the Certificate Templates folder, right-click and delete (as shown below): 

Remember, you are not deleting the template object from the configuration partition in AD, you are only removing it from being published on the Issuing CA.

8. Next, you will either need to wait for Windows Active Directory replication to complete or manually initiate replication to ensure the template changes are updated to all the Windows Active Directory domain controllers and available to all the Windows Server Enterprise CAs within the Windows Active Directory Forest. (NOTE: manual replication can be initiated by opening a command prompt as administrator on a Windows domain controller and running the command: repadmin /syncall).

9. Once Windows Active Directory replication is complete, the Kerberos authentication template must be published on the Windows Server Enterprise CAs.

10. To issue the template, right-click on the Certificate Template folder, select New and then Certificate Template to Issue (as shown below): 

11. Select the Kerberos Authentication or your custom certificate template from the list of Enabled Certificate Templates.

12. The Kerberos authentication template is now available for the Windows domain controllers to enroll for a new domain controller. (Note, you can restart the CA service to reduce the time for template availability)

Now that the template is published, is there anything else you need to know before you attempt to enroll?

The Kerberos Authentication template is a special template. After submitting a request to enroll to the CA, the CA is required to make an RPC call back to the domain controller. It does so to validate the NetBios and DNS domain name of the domain controller via RPC calls. These calls require the CA to communicate back to the domain controller over ports 135 and 445. The validation is required because the template has the following two flags set:

CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS = 0x400000 (4194304) 

CT_FLAG_SUBJECT_ALT_REQUIRE_DNS = 0x8000000 (134217728) 

Certificate Name Flag Attribute Details

The following article details the processing rules that are applied to the flags in this attribute: Certificate Name Flag Processing Rules

For the purposes of this article, we are only concerned about the rules shown below:

1. If the CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS flag is set, the CA SHOULD<119>: 

The CA SHOULD retrieve a handle for the information policy using the LsarOpenPolicy method ([MS-LSAD] section 3.1.4.4.2 ), with the SystemName parameter set as the dNSHostName attribute from the requestor’s computer object, all fields of the ObjectAttributes set to NULL, and the DesiredAccess parameter set to POLICY_VIEW_LOCAL_INFORMATION.

The CA SHOULD obtain the requester’s computer DNS Domain Information by using the LsarQueryInformationPolicy method ([MS-LSAD] section 3.1.4.4.4), with the PolicyHandle parameter set to the value obtained in the previous step, and the InformationClass parameter set to PolicyDnsDomainInformation.

2. The CA MUST add the value of the Name and DNSDomainName field in the returned DNS Domain Information from the previous step to the subject alternative name extension of the issued certificate.

 3. If the CT_FLAG_SUBJECT_ALT_REQUIRE_DNS flag is set, the CA MUST add the value of the dNSHostName attribute from the requestor’s computer object in the working directory to the subject alternative name extension of the issued certificate. For this, the CA MUST invoke the processing rules in section 3.2.2.1.2 with input parameter EndEntityDistinguishedName set equal to the requester’s computer object distinguished name and retrieve the dNSHostName attribute from the returned EndEntityAttributes output parameter. 

References to LsarOpenPolicy and LsarQueryInformationPolicy mean the API calls are made directly to the computer that is sending in the certificate request.  This is where the RPC call is being made from the CA back to the domain controller. Keep in mind, it is more than likely going to be a 445 port connection when using these Lsar calls and not specifically RPC 135/Dynamic ports. Lastly this check does require NTLMV2 to be enabled on the domain controller for port 445/SMB. If NTLMV2 is not enabled, it will fail connecting back to the domain controller even if the ports are opened.

The documentation that shows MS-LSAD calls communicate over SMB is: [MS-LSAD]:Transport

What is the takeaway?

You now know why it’s better to use one PKI certificate instead of many for your Windows domain controller, and how to make your Windows domain controller use one PKI certificate for modern authentication in a Windows PKI setup. By doing these things, you can make your life as a Windows Administrator easier and your Windows domain controllers safer. 

Brent Crummey 

​Microsoft Tech Community – Latest Blogs –Read More