Windows Server 2012 builds on the powerful features of its predecessors and also brings new features and functionalities to some of the familiar server roles. One area that has seen many improvements is the Active Directory Certificate Services (AD CS). Microsoft first got serious about providing Windows network administrators with a way to deploy their own public key infrastructures (PKIs) with the introduction of Windows 2000 Server, which made it easy to create a certification authority (CA) to receive certificate requests, verify the information in the request (including identity of the requestor) and issue and revoke digital certificates to be used for various purposes (server authentication, client authentication, code signing, secure email, etc.).
A PKI is built on a foundation of certification authorities, which can be arranged in a hierarchical fashion. Deployment of a Windows Server 2012-based PKI involves installing the AD CS server role on one or more servers that will act as the CA(s). Digital certificates can be used for the purposes mentioned above, and more – but the use of particular certificate types is a topic better suited for our Windowsecurity site. This article series will focus on the server and networking aspect and how to go about deploying certification authorities for your organization.
What's new for Windows Server 2012
Microsoft has steadily improved Certificate Servers over the years and many of those enhancements have been done in an effort to make things easier for the administrators who need to install, configure and manage the PKI. They've continued along those same lines with the changes in Windows Server 2012, giving you more choices than ever before.
Expanded flexibility
One of the nicest changes is that you no longer have to struggle with figuring out which Certificate Services role services could run on which editions of the operating system. If you ever tried to deploy Certificate Services in Windows Server 2008 R2, you know that this could be a planning and deployment nightmare for small and medium sized businesses. Whereas all the roles and features were available on the enterprise and datacenter editions, some of the Certificate Services components wouldn't run on the standard edition (and none of them were available on the Web edition). In addition, although the CA role service would run on the standard edition of the OS, certain features (for example, role separation and certificate manager restrictions) were not available on those standard edition CAs, only on enterprise and datacenter CAs. The complete tables showing which editions supported which role services and features can be found in the Active Directory Certificate Services Overview for Windows Server 2008 R2 in the TechNet library.
Administrators will be relieved to find out that all that has changed in Windows Server 2012. Now it's simple: all AD CS role services will run on all editions of Windows Server 2012. Windows Server 2012 comes in four different editions: Datacenter, Enterprise, Essentials and Foundation (the last two have user account limits of 25 and 15 users, respectively, whereas the first two are licensed per-processor with Client Access Licenses required). AD CS includes the same six different role services as in previous versions: Certification Authority, CA Web Enrollment, Online Responder, Network Device Enrollment Service, Certificate Enrollment Policy Web Service, and Certificate Enrollment Web Service. Any of these can now be installed on any Windows Server 2012 edition.
And that includes the Server Core installation of Windows Server 2012, too. In the past, you couldn't run all of the AD CS role services on a server core installation because some required the graphical interface that is not present on a machine running Server Core. Now, you can use Windows PowerShell cmdlets to deploy and manage the AD CS role services. This is great news for those who prefer to run their servers as Server Core installations for better security, more stability and better performance.
More options for managing Certificate Services
If you don't install in Server Core mode, the new Server Manager interface is front and center in Windows Server 2012; it's readily available on the taskbar and it's one of the two primary means for performing administrative tasks (the other, of course, is PowerShell). The Server Manager has been completely redesigned to provide a more streamlined look that's in keeping with the Windows 8 tile-based style and many new functionalities have been integrated into it. For those who prefer to use the graphical tools, Server Manager is the centralized location from which you can configure and manage Active Directory Certificate Services. Of course, Server Manager allows you to manage multiple remote AD CS servers in addition to the local server.
You can benefit from Server Manager even if you're going to run your servers as Server Core machines. That's because a new installation option in Windows Server 2012 lets you install your server with the graphical interface, which you can use for all the initial setup and configuration of your server roles and role services, and then switch over to Server Core afterward.
Even better, if you run into situations where you aren't entirely comfortable using the command line (or you need to perform troubleshooting tasks that aren't possible from the command line), you can switch back to the full graphical interface and then back to Server Core again when you're finished. And it's easy. All it takes is a couple of simple PowerShell cmdlets (Import-Module ServerManager and Uninstall-WindowsFeature Server-Gui-Shell-Restart) and a reboot of the server. You can see screenshots of the steps involved in the process here in this TechNet blog post.
Of course, a third option is to install the Minimal Server Interface, which is Server Core but with GUI management.
Version 4 certificate templates
Certificate templates are used in the enterprise environment to define format and content of certificates, the enrollment process (including which users/computers are allowed to enroll for which certificate types), etc. Each template is configured with specific permissions and the templates are available to all the CAs in a forest. The templates make it easier for users to get certificates for the purposes that fit their needs. The user doesn't have to "reinvent the wheel" by submitting a complicated certificate request for a type of certificate that is frequently requested by members of the organization.
The first templates were introduced with Windows 2000 Server but they were very limited because they couldn't be modified. Version 2 templates were introduced with Windows Server 2003 and they allowed for some customization. Version 3 templates were introduced with Windows Server 2008, to support features such as Cryptography Next Generation (CNG).
Windows Server 2012 brings us version 4 certificate templates. These even more sophisticated templates support both cryptographic service providers and key service providers, they can be set to require that the same key be used for renewal, and they specify the minimum CA and client OS that can use the template – they are only available for use with Windows Server 2012 and Windows 8 client computers.
Note:
Some folks are confused by the fact that there is a Compatibility tab that lets you specify minimum down-level operating systems. This does not mean those OSes will be able to use the version 4 templates; it means they can still enroll for certificates through the CA using earlier version templates.
Better support for globalized organizations
More and more organizations that use Windows Server Certificate Services are located in countries across the world. The languages in some of those countries include characters that can't be represented in ASCII. This can cause problems because our Domain Name System (DNS) was originally created in the 1980s in the United States by Boston computer scientist Paul V. Mockapetris who likely never envisioned how communications relying on the system would spread around the globe. Thus he based DNS on the use of the ASCII character set and that limited the characters that could be used in domain names.
The concept of Internationalized Domain Names (IDNs) came along in the late 90s to translate domain names that were written in languages other than ASCII-character-compatible ones to be translated into an ASCII representation. You can read more about IDNs here.
The problem with this solution is that it only works with applications that are designed to recognize these IDNs. Past iterations of AD CS did not work with IDNs. Windows Server 2012 AD CS brings some (but not full) support for IDNs. What that means is that AD CS can utilize IDNs in some specific scenarios. This is a step in the right direction. The scenarios that are supported include the following:
Computers that use IDNs can be enrolled for certificates.
You can generate and submit a request for a certificate with an IDN (you need to use the command line utility certreq.exe)
Certificate Revocation Lists (CRLs) and Online Certificate Status Protocols (OCSPs) can be published to servers that use IDNs.
IDNs are now supported by the Certificate user interface.
IDNs can be used in the Certificate Properties in the Certificate management console.
These changes will be useful for those organizations that must use IDNs for compatibility with DNS.
No comments:
Post a Comment