Compartilhar via

Automating Active Directory Certificate Services with Windows PowerShell – Part 1

  • Artigo

Hello again, this is Greg Blaum. I am a Program Manager on the Windows Server and System Center CAT team. This is part 1 in a 4 part series on utilizing Windows PowerShell to automate key functionality in Active Directory Certificate Services (AD CS).

The focus of the series will be on utilizing Active Directory Certificate Services (AD CS) as an Enterprise Certificate Authority, which is tightly integrated with Active Directory Domain Services (AD DS).

This post will begin the series by providing some background on the key concepts of using AD CS. Here is a table of contents for the full series.

Table of Contents

· Part 1: Introduction

· Part 2: Automating Installation of AD CS with Windows PowerShell

· Part 3: Creating Custom Certificate Templates

· Part 4: Automating Certificate Requests with Windows PowerShell

Importance of an Enterprise Certificate Authority

An Enterprise CA is a specific type of certification authority that is tightly integrated with Active Directory Domain Services (AD DS). Because of the tight integration with AD DS, Enterprise CAs can utilize a person’s user account credentials as proof of the user’s identity. For example, when I’m authenticated on our corporate domain and request a user certificate from our Enterprise CA, the CA infrastructure will authenticate my identity in AD DS and utilize that information to determine which type of certificate I may request as well as use my identity as part of the certificate request itself. An Enterprise CA may also leverage AD Security Groups for approving or denying certificate requests.

As a service that is integrated with AD DS, Enterprise CAs also publish certificates and Certificate Revocation Lists (CRLs) to Active Directory. AD CS utilizes Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all computers and users that participate in the Active Directory domain. For issuance of certificates, an Enterprise CA will leverage certificate templates. A typical installation of AD CS as an Enterprise CA will install a number of common certificate templates (such as Web Server, IPSec, Exchange User, & Exchange Signature Only), and an AD CS administrator may customize certificate templates or create new ones. Creation of custom certificate templates will be one of the topics in this blog series.

Utilizing certificate templates with an Enterprise CA will provide the following key functionality:

  • Automatic certificate enrollment and approval. This feature is only available with an Enterprise CA that is integrated with Active Directory.
  • Smart card authentication for users. Using an Enterprise CA provides the functionality for a smart card certificate to be mapped automatically to user accounts in Active Directory.
  • Credential checks of the user account during certificate request and enrollment. Each certificate template has a security permission set in Active Directory, which can determine whether the certificate requester is authorized to request a certificate using that template. As mentioned earlier, the certificate template can leverage AD Security Groups.
  • Automatic population of certificate subject name, based on information that is present in Active Directory.
  • Pre-determined list of certificate extensions for any certificates to be issued by a certificate template. The policy module adds this list of certificate extensions to the certificate template. By doing so, this can prevent user error during certificate request and reduce the amount of information a requester needs to provide.

Functionality that leverages Active Directory Certificate Services

Many features and roles in Windows Server, System Center, and other Microsoft products may utilize Active Directory Certificate Services in some manner. AD CS may be used to enhance security for services, devices, or user accounts. The following is a non-exhaustive list of some services that can take advantage of Active Directory Certificate Services. Many of these services can utilize Secure Socket Layer/Transport Layer Security (SSL/TLS).

  • Exchange Server and S/MIME: Leverages digital certificates to enhance email security by providing both Digital Signature and Message Encryption capabilities.
  • Internet Information Services (IIS): Can leverage Secure Socket Layer/Transport Layer Security (SSL/TLS). This enables encrypted data transfer between client web browsers and IIS Web Servers.
  • Remote Desktop Web Access (RD Web Access, which utilizes IIS): RD Web Access enables users to access RemoteApp, Desktop Connection, and Remote Desktop Web Connection. May utilize SSL to encrypt the data channel between the clients and the RD Web Access server.
  • Direct Access: Some implementations of Direct Access may utilize computer certificates for authentication and may optionally take advantage of health certificates if the Direct Access implementation is using Network Access Protection (NAP).
  • Internet Protocol Security (IPSec): IPSec can utilize public/private key signatures from digital certificates. Provides end-to-end security from client to server, server to server, and client to client. Also used for secure remote access from client to gateway using the Layer Two Tunneling Protocol (L2TP). IPSec is also leveraged in Direct Access scenarios.
  • Active Directory Federation Services (AD FS): AD FS utilizes digital certificates to secure communication between federation servers, federation server proxies, claims-aware applications, and Web clients. There are 4 types of digital certificates used by AD FS: Token-signing certificates, Service Communication certificates, Secure Sockets Layer (SSL) certificates, and Token-decryption certificates.
  • Web Application Proxy: The Web Application Proxy is a new Remote Access role service in Windows Server 2012 R2. It provides reverse proxy functionality for web applications, pre-authenticates access to web applications using AD FS and functions as an AD FS proxy. The Web Application Proxy role typically uses Secure Sockets Layer (SSL) certificates.
  • Work Folders: Work Folders is new functionality that was introduced with Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2. On Windows Server 2012 R2, Work Folders is a role service for file servers. To access Work Folders from an Internet-connected device, the Work Folder sync server URL’s must be published with a reverse proxy. The Web Application Proxy role mentioned before, in conjunction with AD FS may be used to publish Work Folders.
  • Workplace Join: Workplace Join is a new feature in Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2. Users can join personal devices with their company to access company resources and services. In doing so, it becomes a known device within Active Directory. Workplace Join is made possible by the Device Registration Service (DRS), which is included within Active Directory Federation Services (AD FS) in Windows Server 2012 R2.
  • Device Registration Service (DRS): The Device Registration Service (DRS) is included with the Active Directory Federation Role in Windows Server 2012 R2. When a device is Workplace Joined, DRS provisions a device object in Active Directory and installs a certificate on the device that is used the represent the device identity.
  • And many more…

Need for Automating Installation and Consumption of Active Directory Certificate Services

Due to the need for enhanced security services and the wide range of features and roles that may utilize Active Directory Certificate Services (AD CS), it is extremely beneficial to have the means to automate both the installation of AD CS and the consumption of AD CS services. Given the broad range of potential types of certificates that may be needed by Windows Server features and roles, examples of how to leverage Windows PowerShell to request and install the appropriate certificates as part of some role installations will be provided in this blog series.

Stay tuned for Part 2 in this series coming soon.

Thanks,

Greg

Links for more information on Active Directory Certificate Services

Comments

  • Anonymous
    January 01, 2003
    Hi Greg, do you guys have any ETA on when you plan on publishing the remainder of the posts in this series? Thank you for choosing to write more about certificates, since while not much of it has changed since server 2003, i've found that it's still a bit tricky to get running correctly in a two-tier setup. Personally, i thought that after following the technet guides that i had a decent understanding, but it didn't turn out that way. My issuing servers needed their certs renewed, the crl's needed to be refreshed from the root, and somehow when trying to do these things and extend the expiration date of the certs, i can't recall what the error was, but i seem to remember it being something about losing synchronization with the order of the certs.Needless to say, i need to yank everything out and redo it all, so a new guide would be wonderful!
  • Anonymous
    January 06, 2014
    Pingback from Windows Azure Pack – Reconfigure portal names, ports and use trusted certificates
  • Anonymous
    January 22, 2014
    Following up from the Installing and configuring Windows Azure Pack (WAP) series we are now at the point
  • Anonymous
    February 27, 2014
    Waiting patiently for Part 4! Looking for methods to populate an offline request custom template with custom data
  • Anonymous
    May 12, 2014
    原文链接： http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal
  • Anonymous
    May 12, 2014
    原文链接： http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal
  • Anonymous
    May 20, 2014
    Where is part 2? part 3? part 4?
  • Anonymous
    May 20, 2014
    Where is part 2? part 3? part 4?
  • Anonymous
    May 20, 2014
    Where is part 2? part 3? part 4?