There are two Hyper-V-related topics that I simply will not take questions on anymore. It’s not because I don’t like you or because I doubt that you’re truly in crisis. It’s because I believe that the cornucopia of warning signs has existed long enough that you could have easily avoided your predicament and that there will be no positive return on any time invested in helping you continue on your current path. The first of these topics is pass-through disks. Stop using them and you’ll stop having trouble with them; it really is as simple as that. The second is the topic of this post: Hyper-V hosts in workgroup mode. I have tried to find the poisoned wellspring whose judgment-clouding miasma has caused so many administrators to make this ill-fated decision, but have come up empty. I see a great many people explaining how to do it, which lends the practice an undeserved credibility. I realize that I have contributed to that as well; people wanted to know how to do it so I talked about how to do it. However, I can’t find anyone with any recognized level of authority claiming that a Hyper-V host should be excluded from the domain. It is time that we, as a community, start proclaiming that the act of placing Hyper-V hosts in workgroup-mode is poor practice.

Exceptions

Few things in this industry are fixed rules, and the domain vs. workgroup decision for Hyper-V is not one of the few. Here are a few solid reason for not joining a Hyper-V host to a domain:

• You don’t have a domain. If not having a domain is working for you, I wouldn’t create one just for Hyper-V. Home systems are great examples. Very tiny networks are good examples. Networks where the Hyper-V host is the only Microsoft server system are good examples.
• All the guests are in a DMZ and you don’t want to connect the physical unit to your internal network. I have done a fair bit with DMZ-based systems in my career and I don’t really believe that this reason is very solid. The Hyper-V host and its guests can be completely isolated from each other so that there is no meaningful risk of having the host exist on a protected internal network while one or more guests live entirely in a DMZ. That said, the principle is not entirely without merit and might be worth it if it makes your security officer happier. However, if the host is in the DMZ, then it must be treated like any other computer in the DMZ; that means that you cannot perform any of the security-reducing tasks that must be done to manage it remotely.
• You have committed crimes against humanity and are seeking redemption. Remotely managing a non-domain-joined Hyper-V host by anything but RDP is ridiculously complicated and frustrating. It will work one day and not the next, just because. Every time you install an operating system update on any involved system, you’ll wonder if that’s the last time the remote connection will ever work. If you believe that you have done something so terrible as to deserve this fate, then I suppose I shouldn’t hinder you. But, I also shouldn’t help you, because that would defeat the purpose. Looking up the answers on the Internet is cheating. [Note: if you have actually committed crimes against humanity, then you are a bad person. However horrid the experience may be, using workgroup-joined Hyper-V will not absolve anyone of any atrocities.]

Even if one of the above situations applies to you, your solution should be to open the firewall on port 3389 to specified sources, enable Remote Desktop, and work with your host in an RDP session.

Responding to the Common Reasons for Leaving a Hyper-V Host Out of the Domain

Just as it’s tough to find any experts recommending this configuration, it’s surprisingly difficult to find people giving reasons for why they choose this route. I can’t tell if they think that everyone does it that way and that they’re just following the crowd or if they’ve locked themselves onto a particular course of action and reason and logic aren’t playing a part. I did find a couple of explanations, so we’ll tackle them head on.

Myth 1: Leaving a Hyper-V Host Out of the Domain Increases Security

Repeat after me: There is absolutely no condition in which a workgroup configuration is more secure than a domain configuration. It might be possible that your domain’s security is awful, but putting any connected system in a workgroup just makes everything more awful. If you then take the next step of configuring the host so that you can manage it remotely by MMC consoles, you have reduced its security below the already-pitiful protection of the workgroup system.

• Using the TrustedHosts configuration at all lowers security. What this does is tell the system: “any computer, literally any computer, that claims to have a name on this list — trust it completely”. It is trivially simple to watch computer names travel across a network via broadcast, determine who is communicating with whom, and then spoof a name.
• Authentication to remote workgroup-connected machines requires the full credential set to be passed to the target system on each connection. If the authentication communication is intercepted, it can be compromised. I don’t dabble much in black/white hat techniques so I wouldn’t know for sure, but I wouldn’t be surprised if simply duplicating the response packet would work just as well since machine authentication has been bypassed with TrustedHosts.
• That tinkering that you have to do in DCOMCNFG? All of that is reducing security. I don’t even like granting read permissions to Anonymous, and here some of you are giving it administrative privileges.

I’m sure that this myth arose from some well-meaning place. Someone was probably thinking that if their Hyper-V host was compromised and a member of the domain, that the domain would similarly be compromised. Examine that for what it is. If it were true, then no computer should ever be joined to any domain for precisely the same reason. Think of what would happen if any domain member were compromised. The risks are the same. If your workgroup-connected Hyper-V host is operating even one domain-joined virtual machine, then a successful assault against the host makes its domain-joined status irrelevant. Maybe someone believed the opposite — that if the domain were compromised and the Hyper-V host wasn’t part of it, that the Hyper-V host would remain unaffected. All else being equal, cracking domain security is exceedingly more difficult than cracking workgroup security. If someone has broken into your directory, they’ll have your workgroup hosts as soon as they want them, especially if you’ve taken all of the security-reducing steps necessary for remote connectivity.

To expose this as a myth, if I were interviewing a systems administration job candidate and that person said that s/he chooses workgroup mode for anything except roles intentionally exposed directly to the Internet on the grounds that workgroup mode is more secure than domain mode, that person would not be hired. Qualifying it with, “but only for Hyper-V,” is nonsensical.

Myth 2: The Hyper-V Domain Controller Myths

I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.

Not-Quite-Myth 3: The DMZ Issue

A lot of people leave Internet-facing systems, such as web servers and Exchange Edge servers, out of the domain. That makes sense because there is a greater-than-insignificant chance that the operating systems on such units could be compromised and any local credential stores cracked. Active communications sessions could also be compromised. Because some of these roles have traversal paths across the firewall into protected networks, compromised credentials or sessions would be extremely dangerous for the environment. In illustration:

Edge Traversal

A similar example is the web server/SQL server combination. The web server sits outside the domain but has a tunnel to an internal SQL server. It is definitely a valid security measure to leave these hosts off the domain so that domain credentials are (theoretically) never placed in jeopardy. There is one critical difference between leaving those out of the domain and leaving your Hyper-V host out of the domain: There are additional steps that administrators must take to ensure that no sensitive information is ever left on a web or e-mail host in the DMZ. No one who talks about leaving Hyper-V out of the domain ever brings up the topic of hardening the host against intrusion. All they talk about is crippling the security so that it can be remotely managed.

Unfortunately, some administrators have trouble with the full picture when those DMZ-based systems live on a Hyper-V host. In truth, the diagram is still exactly the same as above, provided that your network segmentation is done correctly. However, those administrators may not mentally separate the Hyper-V host from its guests; to them, a compromise of a guest is also a compromise of the host. This is not how virtualization works.

Myth 4: Workgroup Mode is the Only Way to Protect Hyper-V from Bad Group Policies

It’s no secret that there are a couple of group policies that can cause problems for Hyper-V. That’s hardly a reason to exclude it from the domain. Mitigating facts:

• As I said before, these policies are not secret. Don’t override the Create symbolic links policy. In fact, most everything under User Rights Assignment is likely to break something somewhere, so just stay out of that branch when setting domain policies. If you’re using iSCSI, don’t enable the policy that forces it to be disabled.
• Group policy settings that cause problems for Hyper-V cause problems for other things. If you have a policy that breaks Hyper-V, then it’s only a matter of time until it breaks something else. The proper answer is to fix the policy, not go leaving things out of the domain.
• Active Directory has features that make these problems a non-issue. Look into Organizational Units and, if you’re really stuck, Block Inheritance. Ideally, your Hyper-V hosts will be in their own OU. If you can attach it directly to the root domain OU, that’s best. If you attach it to a sub-OU, that sub-OU can have policies that reverse those coming down from the parent.

Punishing yourself and reducing the security of your Hyper-V host is not the proper way to address a poorly configured domain. All those things do is add to your management burden which reduces the amount of time that you have available to fix your problems.

The Truths of the Domain and Hyper-V

To understand why everything is OK with plugging your Hyper-V host into the domain, you need to dig a bit into Active Directory, workgroup mode, and the basics of virtualization. I’m going to start with virtualization because it is the most important part and it explains why the DMZ issue is mostly a myth.

Virtualization is Segregation

The entire purpose behind placing systems into a DMZ is to keep them as separate as possible from your sensitive systems. Whether people realize it or not, it’s tough to have systems any more separated than they are in the inner space of a hypervisor. I often wish that the term partition hadn’t fallen out of favor in the hypervisor lexicon. This is how you should think of a hypervisor, its management operating system, and its guests:

Hypervisor Partitions

These machines share nothing in common except the Hyper-V host. This is virtually like having a lot of physical servers in the same datacenter. This is what virtualization is. Yes, there’s the VMBus and whatnot, so the management operating system isn’t entirely disconnected from the guests, but are there any known exploits of VMBus? I have heard of one “possible” compromise that was patched out. If there are any surviving issues, what difference do you expect domain membership to make? The separation is at least as good as having all of your servers in the same room using common rack, cooling, power, and switching equipment. The following is a perfectly valid configuration:

Domain and DMZ Together

In the above image, the only system that isn’t domain-joined is the web server. Its only access to the SQL server is via the firewall. Functionally, this configuration is no different than the Edge image that I showed you earlier. The only difference is that we’re talking about virtual systems instead of physical systems… as far as you know. The Edge system in the first image could very well be a guest of a domain-joined Hyper-V host that is sitting on a protected network. Although it’s not shown in these diagrams, you could certainly use dedicated NICs to host a DMZ-only virtual switch if you want. That way, the networking for the domain systems and the DMZ systems do not need to share any common physical network pathways. However, VLANs should work just as well.

The benefit of this build is that only the web server is exposed to the Internet. You don’t need to place your Hyper-V host in the DMZ at all. Should you decide to go that route anyway, make sure that you don’t make any of the security-lowering settings on the Hyper-V host so that it can be managed remotely. RDP is all you get.

The Reality of Workgroup Mode

Workgroup mode is inherently insecure. It is, in many ways, an anachronism from an era when there were no domain controllers. It survived into the early domain days for many reasons: Microsoft and backward-compatibility were once more or less synonymous terms, there was no hardware-sharing virtualization, and server-class hardware was so expensive that the phrase “entry-level server hardware” wasn’t even coined yet. Many companies just couldn’t afford the multi-thousand dollar expenditure of a domain controller, so they skipped it. Those were also the days when Microsoft’s operating system security deserved most of the ridicule that it received. Even so, Microsoft really only went far enough so as to allow members of a workgroup to share some things, like Word files. If they ever intended for one workgroup system to handle the task of managing or being managed by another, I certainly missed the memo. This was peer-to-peer networking in the truest sense of the word peer.

If all those things that you have to do in order to manage a remote workgroup system feel like dirty hacks, that’s because they are dirty hacks. In today’s era, when Microsoft has worked very hard to repair their security practices and processes, it’s simply not practical to expect them to allow anyone to break down the walls that they have spent so much time building. While they are making a few changes starting in 2016 that will coincidentally improve ease of remote workgroup management in some ways, you will still be enabling security-reducing dirty hacks in order to make Hyper-V host manageable in workgroup mode.

The Reality of the Domain

The domain is the way of the hierarchical Microsoft network. When Hyper-V is present with even one guest, the environment is automatically hierarchical. Nothing else comes close enough to even bother making comparisons. I think everyone knows this part.

With that said, each computer is still its own entity. That includes Hyper-V hosts. I know that this is a conceptual struggling point for a great many people; I have lost track of the number of times I’ve lost my temper trying to explain to vendors that if I place a domain account into the local Administrators group, then the account is a local administrator. I believe that lack of understanding around the Windows security model is what leads many administrators do some of the things that they do. When you join a computer to a domain, its local security is altered in a number of ways; Domain Admins become local admins, so on and so forth. However, local accounts remain. Services continue to run under the “LocalSystem” account. The identity of LocalSystem and other built-in accounts is unaltered. The local Security Accounts Manager (SAM) database remains, with some new entries. Group policies are enforced from the domain, but enforcement utilizes existing mechanisms on the local computer. In short, the local computer does not cease to exist as a unique entity just because it is part of a domain. Local credentials still work. Joining a domain allows you to leave the peer-to-peer network where you must compromise security in order to enable remote management and enter a hierarchical environment where you can easily establish superior/subordinate relationships without giving up any protections.

The Benefits of the Domain and Hyper-V

The summary of all of the above works itself out as several benefits that you get from joining the domain as opposed to leaving it out:

• Drastically simplified remote management. Everything just works. The pages and pages of instructions and frustration are just not necessary. The firewall ports are automatically open, the accounts are already there, and you don’t have to do much of anything except follow industry best practices.
• Drastically improved security. The control that your domain can exert over a Hyper-V host is the same as for any other member server. You can have a group policy that locks the host down the moment that it becomes a member. You can add and remove domain accounts and manipulate local accounts without ever directly touching the Hyper-V system again. You can authenticate with expiring Kerberos tickets instead of transmitting user name/password combinations that are valid until someone remembers that they should change passwords occasionally (read: never). When your Hyper-V host accepts a connection from a remote machine, it has the assurance of the domain controller that the remote computer is who it says that it is. Secure DNS registration works.
• The incentive to use Hyper-V Server or Windows Server Core as opposed to GUI Windows Server is stronger. With so many things being controlled centrally, the need to directly access any individual Hyper-V host is nearly eliminated. We’ve all been told, and should understand, that a GUI-less system provides security benefits. With the plethora of historical evidence indicating that remote management of a workgroup system is going to break at some point, how comfortable will you be if your only control option is RDPing to a command line?
• All of the features work. Shared Nothing Live Migration requires domain membership. SMB 3 shares require domain membership. Assigning SSL certificates to a domain member from your Enterprise Certificate Authority so that it can participate in secure Hyper-V Replica takes a fraction of the time of any other method. Source :
  https://www.altaro.com/hyper-v/domain-joined-hyper-v-host/

Q. Can Windows Server Standard Edition really only run 2 Hyper-V virtual machines?

A. No. Standard Edition can run just as many virtual machines as Datacenter Edition.

I see and field this particular question quite frequently. A misunderstanding of licensing terminology and a lot of tribal knowledge has created an image of an artificial limitation with standard edition. The two editions have licensing differences. Their Hyper-V related functional differences:

• Datacenter Edition has automatic virtual machine activation
• Datacenter Edition can run Storage Spaces Direct

Otherwise, the two editions share functionality.

The True Limitation

The correct statement behind the misconception: a physical host with the minimum Windows Standard Edition license can operate two virtualized instances of Windows Server Standard Edition, as long as the physically-installed instance only operates the virtual machines. That’s a lot to say. But, anything less does not tell the complete story. Despite that, people try anyway. Unfortunately, they shorten it all the way down to, “you can only run two virtual machines,” which is not true.

Virtual Machines Versus Instances

First part: a “virtual machine” and an “operating system instance” are not the same thing. When you use Hyper-V Manager or Failover Cluster Manager or PowerShell to create a new virtual machine, that’s a VM. That empty, non-functional thing that you just built. Hyper-V has a hard limit of 1,024 running virtual machines. I have no idea how many total VMs it will allow. Realistically, you will run out of hardware resources long before you hit any of the stated limits. Up to this point, everything applies equally to Windows Server Standard Edition and Windows Server Datacenter Edition (and Hyper-V Server, as well).

The previous paragraph refers to functional limits. The misstatement that got us here sources from licensing limits. Licenses are legal things. You give money to Microsoft, they allow you to run their product. For this discussion, their operating system products concern us. The licenses in question allow us to run instances of Windows Server. Each distinct, active Windows kernel requires sufficient licensing.

Explaining the “Two”

The “two” is the most truthful part of the misconception. One Windows Server Standard Edition license pack allows for two virtualized instances of Windows Server. You need a certain number of license packs to reach a minimum level (see our eBook on the subject for more information). As a quick synopsis, the minimum license purchase applies to a single host and grants:

• One physically-installed instance of Windows Server Standard Edition
• Two virtualized instances of Windows Server Standard Edition

This does not explain everything — only enough to get through this article. Read the linked eBook for more details. Consult your license reseller. Insufficient licensing can cost you a great deal in fines. Take this seriously and talk to trained counsel.

What if I Need More Than Two Virtual Machines on Windows Server Standard Edition?

If you need to run three or more virtual instances of Windows Server, then you buy more licenses for the host. Each time you satisfy the licensing requirements, you have the legal right to run another two Windows Server Standard instances. Due to the per-core licensing model introduced with Windows Server 2016, the minimums vary based on the total number of cores in a system. See the previously-linked eBook for more information.

What About Other Operating Systems?

If you need to run Linux or BSD instances, then you run them (some distributions do have paid licensing requirements; the distribution manufacturer makes the rules). Linux and BSD instances do not count against the Windows Server instances in any way. If you need to run instances of desktop Windows, then you need one Windows license per instance at the very least. I do not like to discuss licensing desktop Windows as it has complications and nuances. Definitely consult a licensing expert about those situations. In any case, the two virtualized instances granted by a Windows Server Standard license can only apply to Windows Server Standard.

What About Datacenter Edition?

Mostly, people choose Datacenter Edition for the features. If you need Storage Spaces Direct, then only Datacenter Edition can help you. However, Datacenter Edition allows for an unlimited number of running Windows Server instances. If you run enough on a single host, then the cost for Windows Server Standard eventually meets or exceeds the cost of Datacenter Edition. The exact point depends on the discounts you qualify for. You can expect to break even somewhere around ten to twelve virtual instances.

What About Failover Clustering?

Both Standard and Datacenter Edition can participate as full members in a failover cluster. Each physical host must have sufficient licenses to operate the maximum number of virtual machines it might ever run simultaneously. Consult with your license reseller for more information.

I will use this article to show you how to perform the most common day-to-day operations: requesting certificates from a Windows Certification Authority.

I used “SSL” in the title because most people associate that label with certificates. For the rest of the article, I will use the more apt “PKI” label.

The PKI Certificate Request and Issuance Process

Fundamentally, the process of requesting and issuing PKI certificates does not depend on any particular vendor technology. It follows this pattern:

1. A public and private key is generated to represent the identity.
2. A “Certificate Signing Request” (CSR) is generated using the public key and some information about the identity.
3. The certification authority uses information from the CSR, its own public key, authorization information, and a “signature” generated by its private key to issue a certificate.

The particulars of these steps vary among implementations. You might have some experience generating CSRs to send to third-party signers. You might also have some experience using web or MMC interfaces. All the real magic happens during the signing process, though. Implementations also vary on that, but they all create essentially the same final product.

I want you to focus on the issuance portion. You do not need to know in-depth details unless you intend to become a security expert. However, you do need to understand that certificate issuance follows a process. Sometimes, an issuer might automate that process. You may have encountered one while signing up for a commercial web certificate. Let’s Encrypt provides a high degree of automation. At the other end, “Extended Validation” certificates require a higher level of interaction. At the most extreme, one commercial issuer used to require face-to-face contact before issuing a certificate. Regardless of the degree, every authority defines and follows a process that determines whether or not it will issue.

In your own environment, you can utilize varying levels of automation. More automation means more convenience, but also greater chances for abuse. Less automation requires greater user and administrative effort but might increase security. I lean toward more automation, myself, but will help you to find your own suitable solutions.

Auto-Enroll Method

I am a devoted fan of auto-enrollment for certificates. You only need to set up a basic group policy object, tie it to the right places, and everything takes care of itself.

If you recall from the previous article on certificate templates, you control who has the ability to auto-enroll a certificate by setting security on the template. You use group policy to set the scope of who will attempt to enroll a certificate.

In the above graphic, the template’s policy allows all members of the default security group named “Domain Computers” to auto-enroll. Only the example “Certified Computers” OU links a group policy that allows auto-enrollment. Therefore, only members of the Certified Computers OU will receive the certificate. However, if Auto-Enroll is ever enabled for any other OU that contains members of the “Domain Computers” group, those members will receive certificates as well.

In summary, in order for auto-enroll to work, an object must:

• Have the Autoenroll security permission on the certificate template
• Fall within the scope of a group policy that enables it to auto-enroll certificates

You saw how to set certificate template security permissions in the previous article. We’ll go to the auto-enrollment policies next.

Auto-Enrollment Group Policies

The necessary policies exist at Computer or User ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key Policies. I am concerned with two policies: Certificate Services Client – Auto-Enrollment Settings and Certificate Services Client – Certificate Enrollment Policy.

First, Certificate Services Client – Auto-Enrollment Settings. To get going, you only need to set Configuration Model to Enabled. The default enrollment policy uses Windows Authentication to pull certificate information from Active Directory. If you’ve followed my directions, then you have an Active-Directory-integrated certification authority and this will all simply work. You will need to perform additional configuration if you need other enrollment options (such as requesting certificates from non-domain accounts).

Second, Certificate Services Client – Certificate Enrollment Policy. You only need to set Configuration Model to Enabled. Choose other options as desired.

I think the first option explains itself. The second, Update certificates that use certificate templates, allow the certificate bearer to automatically request a replacement certificate when the certificate has updates. I showed you how to do that in the previous article.

Auto-Enrollment Security Implications

In general, you should not have many concerns with automatic certificate issuance. As followed so far, my directions keep everything under Active Directory’s control. However, you can enable auto-enrollment using other techniques, such as simple user/password verification via a URI. Anyone with local administrative powers can set local policies. Certificate templates can allow the requester to specify certificate subject names. Furthermore, some systems, like network access controls, sometimes simply require a particular certificate.

Think through who can request a certificate and who will accept them when configuring auto-enrollment scopes.

MMC Enrollment Procedure

MMC enrollment provides a great deal of flexibility. You can request certificates for you, your computer, or another entity entirely. It works on every single version of Windows and Windows Server in support, as long as they have a GUI. Since you can connect the console to another computer, you can overcome the need for a GUI. The procedure takes some effort to explain, but don’t let that deter. Once you have the hang of it, you can get through the process quickly.

First, you need to access the necessary console.

Accessing Certificate MMCs on Recent Windows Versions

On Windows 10 or Windows Server 2016+, just open up the Start menu and start typing “certificate”. At some point, Cortana will figure out what you want and show you these options:

These options will work only for the local computer and the current user. If you want to target another computer, you can follow the upcoming steps.

Note: If you will use the console to request a certificate on behalf of another entity, it does not matter which console you start. The certificate template must allow exporting the private key for this mode to have any real use.

Accessing Specific Certificate MMCs Directly

On any version of Windows, you can quickly access the local computer and user certificates by calling their console snap-ins. You can begin from the Start menu, a Run dialog, or a command prompt. For the local computer, you must run the console using elevated credentials. Just enter the desired snap-in name and press Enter:

• certlm.msc: Local machine certificates
• certmgr.msc: Current user certificates

Note: If you will use the console to request a certificate on behalf of another entity, it does not matter which console you start. The certificate template must allow exporting the private key for this mode to have any real use.

Manually Add Specific Certificate Targets in MMC

You can manually add the necessary snap-in(s) from an empty MMC console.

1. From the Start menu, any Run dialog, or a command prompt (elevated, if you need to use a different account to access the desired target), run mmc.exe.
   
2. From the File menu, select Add/Remove Snap-in…
   
3. Highlight Certificates and click Add:
   
4. Choose the object type to certify. In this context, My user account means the account currently running MMC. If you pick My user account, the wizard finishes here.
   
5. If you picked Service account or Computer account in step 4, the wizard switches to the computer selection screen. If you choose any computer other than local, you will view that computer’s certificate stores and changes will save to those stores. If you choose Computer account, the wizard finishes here.
   
6. If you selected Service account in step 4, you will now have a list of service accounts to choose from.
   
7. If you want, you can repeat the above steps to connect one console to multiple targets:
   
8. Once you have the target(s) that you like, click OK on the Add or Remove Snap-ins window. You will return to the console and your target(s) will appear in the left pane’s tree view.

Using the Certificates MMC Snap-In to Request Certificates

Regardless of how you got here, certificate requests all work the same way. We operate in the Personal branch, which translates to the My store in other tools.

Requesting a Certificate Using Template Defaults

You can quickly enroll a certificate template with template defaults. This is essentially the manual corollary to auto-enroll. You could use this method to perform enrollment on behalf of another entity, provided that you the template allows you to override the subject name. For that, you must have selected a console that matches the basic certificate type (a user console can only request user certificates and a computer console can only request computer certificates). You must also use an account with Enroll permissions on the desired template. I recommend that you only use this method to request certificates for the local computer or your current user. Skip to the next section for a better way to request certificates for another entity.

To request a certificate using a template’s defaults:

1. Right-click Certificates and click Request New Certificate.
   
2. The first screen is informational. The next screen asks you for a certificate enrollment policy. Thus far, we only have the default policy. You would use the Configured by you policy if you needed to connect without Active Directory. Click Next.
   
3. You will see certificate templates that you have Enroll permissions for and that match the scope of the console. In this screenshot, I used a computer selection, so it has computer certificates. If you expand Details, it will show some of the current options set in the certificate. If you click Properties, you can access property sheets to control various aspects of the certificate. I will go over some of those options in the next section. Remember that the certificate template to manually supply subject name information or it will ignore any such settings in your requests. Click Enroll when you are ready. The certificate will appear in the list.
   

Once you have a certificate in your list, double-click it or right-click it and click Open. Verify that the certificate looks as expected. If you requested the certificate for another entity, you will find the Export wizard on the certificate’s All Tasks context menu.

Creating an Advanced Certificate Request

You can use MMC to create an advanced certificate request. Most importantly, this process works offline by creating a standard certificate signing request file (CSR). Since it does not check your permissions in real time, you have much greater flexibility. I recommend that you use this method when requesting certificates on behalf of another entity. Follow these steps:

1. Right-click Certificates, go to All Tasks, then Advanced Operations, and click Create Custom Request.
   
2. The first screen is informational only. Click Next. On the next screen, choose your enrollment policy. If you’ve followed my guide, you only have two (real) choices: the default Active Directory policy or a completely custom policy. You could also choose to create a new local policy, which I will not cover. If you pick the Active Directory policy, it will allow you to pick from all of its known templates, which you can customize if needed. If you choose to Proceed without enrollment policy, you will start with an empty template and need to provide almost every detail. Make your selection and click Next.
   
3. I took this screenshot after choosing the Active Directory enrollment policy. I then selected one base template. You can see that you also have options for the CSR format to use. If you chose to proceed without a policy, your Template options are No template (CNG key) or No template (Legacy key). CNG (Certificate Next Generation) creates v3 certificates while the Legacy option generates v2 certificates. Practically, they mostly deal with how the private key is stored and accessed. Common Microsoft apps (like IIS) work with CNG. Legacy works with almost everything, so choose that if you need to guess.
   
4. On the Certificate Information screen, you will either see the template name that you chose or Custom request if you did not select an enrollment policy. To the right of that, near the edge of the dialog, click the down-pointing triangle next to Details. If you selected a policy, that will show the defaults. If you did not, it will show empty information. Click the Properties button to access property sheets where you can specify certificate options. Look at the screenshot in step 3 in the previous section. I will show the details dialog in the next section. Click Next when you have completed this screen.
5. Choose the output file name and format. Most CAs will work with either type. Most prefer the default of Base64.
   
6. You can now process the request on your Certification Authority.

Configuring Advanced Certificate Options in a Request

As mentioned step 3 in the above directions on using MMC to request a default template and in step 4 of the advanced request, you can use the Properties button on the Details section to modify parts of the certificate request prior to submitting it to the CA. If you selected a template that requires you to supply information, you will see an additional link that opens this dialog. You should always take care to inspect such a certificate after issuance to ensure that the CA honored the changes.

I will not cover every single detail. We will look at a few common items.

• General: These fields are cosmetic. They appear when you see the certificate in the list.
  
• Subject: This busy tab contains identity information about the certificate holder. If the template only allows Active Directory information, then the CA will not accept anything that you enter here. For each type on the left, you can add multiple values. Make certain that you Add items so that they move to the right panes! Some of the more important parts:
  • Subject Name group: The fields in this group appear all combine to describe the certificate holder.
    • Common name: The primary identity of the certificate. Use a fully-qualified domain name for a computer or a full name for a user. Modern browsers no longer accept the value in the common name for authentication. Other tools still expect it. Always provide a value for this field to ensure the completeness of the subject group.
    • Country, Locality, Organization, etc.: Public CAs often require several of these other identity fields.
  • Alternative Name group: The fields in this group appear in the “Subject Alternate Name” (SAN) section of a certification. Browsers and some other tools will match entries in the SAN fields with the URL or other access points
    • DNS: Use this field to designate fully-qualified and short names that clients might use to access the certificate holder. Since web browsers no longer use the common name, enter all names that the owner might present during communications, including what you entered as the common name. Only use short names with LAN-scoped certificates. For instance, I might have a certificate with a common name of “internalweb.sironic.life” and give it an alternative DNS entry of “internalweb”. For load-balanced servers in a farm, I might have multiple DNS entries like “webserver1.sironic.life”, “webserver2.sironic.life”, etc.
    • IP Address (v4 and v6): If clients will access the certified system by IP address, you might want to add those IPs in these fields.

• Extensions: The extensions govern how the bearer can use the issued certificate. Especially take note of the Extended Key Usage options.
  
• Private Key: You don’t have a huge amount of private key options. In particular, you may wish to make the private key exportable.
  

The wizard will contain your options in the certificate request. The CA may choose to issue the certificate without accepting all of them.

Handling Certificate Signing Requests from a Linux System on a Microsoft Certification Authority

You can use a utility on a non-Windows system to create certificate requests. Linux systems frequently employ OpenSSL. These non-Microsoft tools generally do not know anything about templates, which the Windows Certification Authority requires. You could use the MMC tool on a Windows system to request a certificate on behalf of another. But, if you have a certificate signing request file, you can use the certreq.exe tool on a Windows system to specify a template during the request.

You can use OpenSSL to create CSRs fairly easily. Most of the one-line instructions that you will find today still generate basic requests that identify the system with the Common Name field. Modern browsers will reject such a certificate. So, generating a usable CSR takes a bit more work.

1. Locate openssl.cnf on your Linux system (some potential locations: /etc/pki/tls, /etc/ssl). I recommend creating a backup copy. Open it in the text editor of your choice.
2. Locate the [ req ] section. Find the following line, and remove the # that comments it out (or add it if it is not present):

   1	req_extensions = v3_req

3. Locate the section named [ v3_req ]. Create one if you cannot find it. Add the following line:

   1	subjectAltName = @alt_names

4. Create a section named [ alt_names ]. Use it to add at least the system’s Common Name. You can use it to add as many names as you like. It will also accept IP addresses. If you will host the system on an internal network, you can use short names as well. Remember that most public CAs will reject CSRs with single-level alternative names because it looks like you are trying to make a certificate for a top-level domain.

   1 2 3 4 5 6

   [ alt_names ] DNS.1 = pkidemo.sironic.life DNS.2 = pkidemo   # only works internally DNS.3 = load-balanced-pkidemo.sironic.life IP.1 = 192.168.20.47 IP.2 = 10.10.60.3

5. Make any other changes that you like. Remember that if the CA has a preset value for a setting, it will override. Save the file and exit your editor.
6. Make sure that you’re in a directory that your current user account can write in and that you can transfer files out of. You could:

   1 2	mkdir ~/csr cd ~/csr

7. Execute the following (feel free to research these options and change any to fit your needs):

   1	openssl req -new -newkey rsa:2048 -keyout demo.key -out demo.csr -nodes

8. You will receive prompts for multiple identifier fields. If you explicitly set them in openssl.cnf, then it will present them as defaults and you can press Enter to accept them. I recommend skipping the option to create a challenge password. That does not passphrase-protect the key. To do that, you first need to run openssl with the genpkey command, then pass the generated key file to the openssl req command using the key parameter instead of newkey/keyout. A ServerFault respondent explains the challenge password and key passphrase well, and includes an example.
9. Move the key file to a properly secured location and set permissions accordingly. Remember that if anyone ever accesses this file, then your key, and therefore any certificate generated for it, is considered compromised. Do not transfer it off of its originating system! Example location: /etc/pki/tls/private.
10. Transfer the CSR file to a Windows system using the tool of your choice.
11. On the Windows system, ensure that you have logged on with an account that has Enroll permissions for the template that you wish to use.
12. Discover the Name of the template. Do not use the Display Name (which is usually the Name, with spaces). You can uncover the name with PowerShell if you have the ADCSAdministration module loaded. Use Get-CATemplate:
    
    Alternatively, open up the Certification Authority snap-in and access template management. Find the template you want to use and open its properties sheet. Check the Template name field.
    
13. On the Windows system where you transferred the file, run the following, substituting your file name and template name:

    1	certreq -submit -attrib “CertificateTemplate:SironicWebServerManual”

14. The utility will ask you to browse to the request file. You may need to change the filter to select all files.
    
15. You will next need to select the certification authority.
    
16. The utility will show the CA’s response to your request. If it issues a certificate, it will prompt you to save it. Be aware that even though you can choose any extension you like, it will always create an x509 encoded certificate file.
    

At this point, you have your certificate and the request/signing process is complete. However, in the interest of convenience, follow these steps to convert the x509 certificate into PEM format (which most tools in Linux will prefer):

1. Transfer the certificate file back to the Linux system.
2. Run the following:

   1	openssl x509 -in pkidemo.crt -outform PEM -out pkidemo.pem

3. Move the created file to its final location (such as /etc/pki/tls/certs).

This procedure has multiple variants. Check the documentation or help output for the commands.

Deprecated Web Enrollment Method

Once upon a time, Microsoft built an ASP page to facilitate certificate requests. They have not updated it for quite some time, and as I understand it, have no plans to update it in the future. It does still work, though, with some effort. One thing to be aware of: it can only provide v2 (legacy) certificates. It was not updated to work with v3 (CNG). If a certificate template specifies the newer cryptography provider, web enrollment will not present it as an enrollable option. Certificates must use the Legacy Cryptographic Service Provider.

First, you must issue it a certificate. It responds on 80 and 443, but some features behave oddly on a port 80 connection. Installation of the Web Enrollment role creates the web site and enables it for 443, but leaves it without a certificate.

Follow the steps in the previous article to set up a web server certificate (requires Server Authentication extended key usage). Once you finish that, use one of the MMC methods above to request a certificate for the site. Remember to use its FQDN and optionally its NetBIOS names as DNS fields on the Subject tab. Then, follow these steps to assign it to the certificate server’s web site:

1. Open Internet Information Services (IIS) Manager on the system running the Web Enrollment service or on any system that can connect to it.
2. Highlight the server in the left pane. In the right pane, under IIS, double-click Server Certificates.
   
   
3. The newly-issued certificate should appear here. Highlight it and click Enable automatic rebind of renewed certificate in the right pane. If it does not appear here, verify that it appears in MMC and reload this page. If it still does not appear, then you made a mistake during the certificate request or issuance process.
4. In the left pane, drill down from the server name to Sites, then Default Web Site. Right-click Default web site and click Edit Bindings. You can also find a Bindings link in the far right pane.
   
5. Double-click the https line or highlight it and click Edit… at the right.
   
6. Under SSL certificate, choose the newly-issued certificate. Click OK, then Close to return to IIS Manager.
   
7. Drill down under Default web site and click on CertSrv. In the center pane, double-click Authentication.
   
8. In the center pane, highlight Windows Authentication. It should already be Enabled. In the right pane, click Providers.
   
9. NTLM should appear in the provider list. If it does not, use the drop-down to select it, then Add to put it in the list. Use the Up button to move NTLM to the top of the list. Ensure that your dialog looks like the following screenshot, then click OK.
   

You can now access the site via https://yourcertserver.domain.tld/certsrv. You will need to supply valid credentials. It will display the start screen, where you can begin your journey.

Because of the v2 certificate limitation, I neither use nor recommend this site for certificate requests. However, it does provide a convenient access point for your domain’s certificate chain and CRL.

Alternative Request Methods

The methods that I displayed above are the easiest and most universally-applicable ways to request certificates. However, anything that generates a CSR may suffice. Some tools have interfaces that can communicate directly with your certificate server. Some examples:

• certreq.exe: Microsoft provides a built-in command-line based tool for requesting certificates. You can use it to automate bulk requests without involving auto-enroll. Read up on its usage on docs.microsoft.com.
• IIS Manager
• Exchange Management Console

Other tools exist.

What’s Next

At this point, you can create PKI certificate templates and request them. With an Active Directory-integrated certificate system, all should work easily for you. However, if you were following the directions for the custom request, you ended up with a CSR. Passing a CSR to the certification authority requires different tools. In the next article, I will show how to perform routine operations from the Certification Authority side, such as accepting CSRs and revoking certificates.