Sorry for being absence from the blog right now. A lot of time consuming stuff is happening at work right now, but I will better myself, I promise! 
A very common problem I see regarding ADCS and PKI is that many structures “survive them self” and are used for purposes that they were not initially designed for.
Some problems that I run in to are that people initially install an classic “next-next-finish” Enterprise Root “just to issue some internal SSL certificates” and after two or three years, the CA has got Sub-CA’s for other Issuing or NAP CA’s and suddenly we have requirements of publically available CRL’s for IP-HTTPS in DirectAccess, or even worse, external parties are trusting this structure for their usage or Sub-CA!
So I thought that is a good idea to “lock down” a PKI to the intended purpose of what the structure was actually designed for.
This can very, very easily be done by using (creating) the %WINDIR%\CAPolicy.inf before your install your Enterprise Root.
The following CAPolicy.inf is an example of a PKI lockdown for an internal Enterprise Root:
[Version]
Signature=”$Windows NT$”
[PolicyStatementExtension]
Policies=InternalUseOnly
[InternalUseOnly]
OID=2.5.29.32.0
Notice=”This PKI is intended for internal use only.”
[BasicConstraintsExtension]
PathLength=0
Critical=Yes
[Certsrv_Server]
LoadDefaultTemplates=False
So what does all this text mean? Well, the PolicyStatementExtension section defines the associated policies with the CA. We specify a policy that we call “InternalUseOnly”. First when I tested this, the ADCS wizard did not parse the content of that section if didn’t had and OID (I just wanted the populate the User Notice field).
A quick phone call to my dear friend and mentor Hasain Alshakarti @ http://www.secadmins.com confirmed the conclusion that I already had come to. A OID MUST be specified. But since a Root CA have the “All Issuance Policy” by default, Hasain came up with the clever idea that we can simply walk around that problem by simply specifying that OID for our policy.
The BasicConstraintsExtension is a very powerful section and by specifying PathLength we can specify how many levels of CA’s we allow underneath the root. A very common configuration that I usually do when I design/implement two tiers is that I have a PathLength=1 on the Root CA and a PathLength=0 on the Issuing CA.
The LoadDefaultTemplates part tells the ADCS setup wizard to NOT populate the default list of certificates in the certificateTemplates attribute in the pKIEnrollmentService object in Enrollment Services under Public Key Services that exists in the Configuration partition in Active Directory. By doing this, we do not enroll any certificates “by accident” and we can ourselves choose the exact templates we want to use on our CA. 
Here are some screenshots!
We can clearly see that our critical extension PathLength does not allow any Subordinay CA’s.
We can also see that our notice text is associated with the All Issuance Policy.
// Fredrik “DXter” Jonsson
The script are made to be in c:\scripts and be named menuwin8.ps1 
