Add Active Directory Certificate Services as a valid CAS

[unreality]

Active Directory Certificate Services

This pull adds initial support for ADCS as an upstream RA.

ADCS does not support ACME or the other provisioners step-ca does - using ADCS as an RA allows users to add ACME functionality to their existing ADCS PKI infrastructure, simplifying certificate renewal for non-windows environments that may want to use existing PKI infrastructure.

The following configuration is used to define the authority:

"authority": {
                "type": "adcscas",
                "config": {
                  "serverAddr":"adcs-pki-server.example.local",
                  "authUser":"DOMAIN\\user.name",
                  "authPass":"anInsecurePassword",
                  "caName":"CA NAME",
                  "templateMap": {"povisionerName": "adcsTemplateName"},
                  "defaultTemplateName":"CertificateTemplateDefinedOnADCS",
                  "rootCAPath": "/path/to/root_ca.pem",
                  "intermediateCAPath": "/path/to/any/intermediates.pem"
                },
		"provisioners": [...etc...]
}

It requires the following settings:

• serverAddr - hostname for the ADCS server. Must be a FQDN (not an IP) as the DCOM target is derived from it.
• authUser and authPass - Username/Password. Must be in the format DOMAIN\user.name
• caName - the CA name set when setting up ADCS. Can be found as the Subject name of the CA cert (without the CN=), or by looking at the Certification Authority in the management console.
• templateMap - Allows you to set different ADCS Certificate Templates for different provisioners.
• defaultTemplateName - If a match isnt found within templateMap, use this Certificate Template. Ensure this is the Template Name, not the Template display name.
• rootCAPath - Path to the root CA for this ADCS server
• intermediateCAPath - Path to a pem containing all intermediates.

Currently only NTLM authentication is supported, however Kerberos (with PKINIT for certificate-based auth) could be implemented reasonably easily.

Caveats

• ADCS Certificate Templates define required key types and sizes - users should define templates that enforce those requirements otherwise they may see unclear Denied by Policy Module error messages (e.g if a user attempts to request a certificate using ECDSA when the template is configured for RSA).
• ADCS Certificate Templates should be strictly controlled and managed. There are a number of security implications for misconfigured templates. A new template should be created for use with step-ca and Enroll rights should be limited to the authUser via the Security tab in the Certificate Templates Console.
• Revocation and renewal are not implemented, however should be possible since endpoints exist for those functions in ADCS.
• ADCS does provide an endpoint for obtaining the issuing certificate (which may remove the need for intermediateCAPath, but i'm unsure whether you can obtain the full chain via RPC.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Raal Goff seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}