Fix TOC hierarchy in cred guard not-protected topic

windows/keep-secure/credential-guard-not-protected-scenarios.md

@@ -41,7 +41,7 @@ Credential Guard can provide mitigations against attacks on derived credentials
 
 Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on using devices that have Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used.
 
-#### Kerberos armoring
+### Kerberos armoring
 
 Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring, its TGT is used to protect the user's proof of possession which can mitigate offline dictionary attacks. Kerberos armoring also provides the additional benefit of signed KDC errors this mitigates tampering which can result in things such as downgrade attacks. 
 
@@ -51,7 +51,7 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
 -   All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
 -   All the devices with Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
 
-#### Protecting domain-joined device secrets
+### Protecting domain-joined device secrets
 
 Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Credential Guard, the private key can be protected. Then authentication policies can require that users sign on devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
 
@@ -117,7 +117,7 @@ Beginning with the Windows Server 2008 R2 domain functional level, domain contro
     .\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName:"<name of issuance policy>" –groupOU:"<Name of OU to create>" –groupName:”<name of Universal security group to create>"
     ```
 
-#### Restricting user sign on
+### Restricting user sign on
 
 So we now have completed the following:
 

windows/keep-secure/credential-guard-requirements.md

@@ -9,7 +9,7 @@ localizationpriority: high
 author: brianlic-msft
 ---
 
-# Requirements
+# Credential Guard: Requirements
 
 **Applies to**
 -   Windows 10

windows/keep-secure/credential-guard-scripts.md

@@ -205,7 +205,7 @@ write-host "There are no issuance policies which are not mapped to groups"
 > [!NOTE]  
 > If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
  
-### <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
+## <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
 
 Save the script file as set-IssuancePolicyToGroupLink.ps1.