Israeli cybersecurity researchers have disclosed details about a new flaw impacting DNS protocol that can be exploited to launch amplified, large-scale distributed denial-of-service (DDoS) attacks to takedown targeted websites.
Called NXNSAttack, the flaw hinges on the DNS delegation mechanism to force DNS resolvers to generate more DNS queries to authoritative servers of attacker's choice, potentially causing a botnet-scale disruption to online services.
"We show that the number of DNS messages exchanged in a typical resolution process might be much higher in practice than what is expected in theory, mainly due to a proactive resolution of name-servers' IP addresses," the researchers said in the paper.
"We show how this inefficiency becomes a bottleneck and might be used to mount a devastating attack against either or both, recursive resolvers and authoritative servers."
Following responsible disclosure of NXNSAttack, several of the companies in charge of the internet infrastructure, including PowerDNS (CVE-2020-10995), CZ.NIC (CVE-2020-12667), Cloudflare, Google, Amazon, Microsoft, Oracle-owned Dyn, Verisign, and IBM Quad9, have patched their software to address the problem.
The DNS infrastructure has been previously at the receiving end of a rash of DDoS attacks through the infamous Mirai botnet, including those against Dyn DNS service in 2016, crippling some of the world's biggest sites, including Twitter, Netflix, Amazon, and Spotify.
The NXNSAttack Method
A recursive DNS lookup happens when a DNS server communicates with multiple authoritative DNS servers in a hierarchical sequence to locate an IP address associated with a domain (e.g., www.google.com) and return it to the client.
This resolution typically starts with the DNS resolver controlled by your ISPs or public DNS servers, like Cloudflare (184.108.40.206) or Google (220.127.116.11), whichever is configured with your system.
The resolver passes the request to an authoritative DNS name server if it's unable to locate the IP address for a given domain name.
But if the first authoritative DNS name server also doesn't hold the desired records, it returns the delegation message with addresses to the next authoritative servers to which DNS resolver can query.
In other words, an authoritative server tells the recursive resolver: "I do not know the answer, go and query these and these name servers, e.g., ns1, ns2, etc., instead".
This hierarchical process goes on until the DNS resolver reaches the correct authoritative server that provides the domain's IP address, allowing the user to access the desired website.
Researchers found that these large undesired overheads can be exploited to trick recursive resolvers into forcefully continuously sending a large number of packets to a targeted domain instead of legitimate authoritative servers.
In order to mount the attack through a recursive resolver, the attacker must be in possession of an authoritative server, the researchers said.
"This can be easily achieved by buying a domain name. An adversary who acts as an authoritative server can craft any NS referral response as an answer to diﬀerent DNS queries," the researchers said.
The NXNSAttack works by sending a request for an attacker-controlled domain (e.g., "attacker.com") to a vulnerable DNS resolving server, which would forward the DNS query to the attacker-controlled authoritative server.
Instead of returning addresses to the actual authoritative servers, the attacker-controlled authoritative server responds to the DNS query with a list of fake server names or subdomains controlled by the threat actor that points to a victim DNS domain.
The DNS server, then, forwards the query to all the nonexistent subdomains, creating a massive surge in traffic to the victim site.
The researchers said the attack can amplify the number of packets exchanged by the recursive resolver by as much as a factor of more than 1,620, thereby overwhelming not only the DNS resolvers with more requests they can handle, but also flood the target domain with superfluous requests and take it down.
What's more, using a botnet such as the Mirai as a DNS client can further augment the scale of the attack.
"Controlling and acquiring a huge number of clients and a large number of authoritative NSs by an attacker is easy and cheap in practice," the researchers said.
"Our initial goal was to investigate the efficiency of recursive resolvers and their behavior under different attacks, and we ended up finding a new seriously looking vulnerability, the NXNSAttack," the researchers concluded.
"The key ingredients of the new attack are (i) the ease with which one can own or control an authoritative name server, and (ii) the usage of nonexistent domain names for name servers and (iii) the extra redundancy placed in the DNS structure to achieve fault tolerance and fast response time," they added.
It's highly recommended that network administrators who run their own DNS servers update their DNS resolver software to the latest version.
In this post, you’ll get a short introduction into Azure Bastion Host. To be honest, I still don’t know if I should pronounce it as [basˈti̯oːn] (German), /bæstʃən/ (US engl.) or [basˈt̪jõn] (french) but that shouldn’t stop us from learning more about Azure Bastion Host, what is it, and when it’s useful.
We will also discuss a webinar on Azure Security –
So let’s start.
What is Azure Bastion Host?
Azure Bastion Host is a Jump-server as a Service within an Azure vNet (note that this service is currently in preview). What does that mean exactly? Well, a jump server is a fixed point on a network that is the sole place for you to remote in, get to other servers and services, and manage the environment. Now some will say, but I build my own jump server VM myself! While you’re certainly free to do that yourself, there are some key differences between the self-built VM option and a Bastion Host.
A regular Jump-server VM must either be reachable via VPN or needs to have a public IP with RDP and/or SSH open to the Internet. Option one, in some environments, is rather complex. Option two is a security nightmare. With Azure Bastion Host, you can solve this access issue. Azure Bastion enables you to use RDP and SSH via the Internet or (if available) via a VPN using the Azure Portal. The VM does not need a public IP, which GREATLY increases security for the target machine.
After the deployment (which we’ll talk about in a second), Bastion becomes the 3rd option when connecting to a VM through the Azure Portal, as shown below.
After you hit connect, an HTTPs browser Window will open and your session will open within an SSL encrypted Window.
Azure Bastion Use Cases
Now let’s list some possible use-cases. Azure Bastion can be very useful (but not limited) to these scenarios:
Your Azure-based VMs are running in a subscription where you’re unable to connect via VPN, and for security reasons, you cannot set up a dedicated Jump-host within that vNet.
The usage of a Jump-host or Terminal Server in Azure would be more cost-intensive than using a Bastion Host within the VNet (e.g. when you have more than one admin or user working on the host at the same time.)
You want to give developers access to a single VM without giving them access to additional services like a VPN or other things running within the VNet.
You want to implement Just in Time (JIT) Administration in Azure. You can deploy and enable Bastion Host on the fly and as you need it. This allows you yo implement it as part of your Operating System Runbook when you need to maintain the OS of an Azure-based VM. Azure Bastion allows you to do this without setting up permanent access to the VM.
How to deploy Azure Bastion Host in preview
The way you deploy Azure Bastion Host within a VNet is pretty straightforward. Let’s go through the steps together.
Open the Azure Preview Portal through the following link.
Search for the feature in the Azure Marketplace and walk through the deployment wizard by filling out the fields shown below.
Again, the deployment is quite simple and most options are fairly well explained within the UI. However, if you want further details, you can find them in the official feature documentation here.
Also, be aware that a Bastion Host must be implemented in every vNet where you want to connect to a VM. Currently, Bastion does not support vNet Peering.
How Much Does Azure Bastion Cost?
Pricing for Bastion is pretty easy to understand. As all Microsoft VM Services, you pay for the time the Bastion hast is deployed and for any Bastion service you have deployed. You can easily calculate the costs for the Bastions Hosts you need via Azure Price Calculator.
I made my example for one Bastion Host in West Europe, with the assumption it would be needed all month long.
Bastion Roadmap Items
Being in preview there are still a number of things that Microsoft is adding to Bastion’s feature set. This includes things like:
Single-Sign-On with Azure AD
vNet Peering (Not confirmed, but being HEAVILY requested by the community right now)
vNet Peering support would make it so that only a single Bastion Host in a Hub or Security vNet is needed.
You can see additional feature request or submit your own via the Microsoft Feedback Forum.
If you like a feature request or want to push your own request, keep an eye on the votes. The more votes a piece of feedback has, the more likely Microsoft will work on the feature.
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.
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:
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:
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.
Windows Server 2012, all editions
Windows Server 2012 R2, all editions
Windows Server 2016, all editions
Windows Server 2019, all editions
Windows 7, all editions
Windows 8.1, all editions
Windows 10, all editions
This article contains recommendations that may help an administrator determine the cause of potential instability on a computer that is running a supported version of Microsoft Windows when it is used together with antivirus software in an Active Directory domain environment or in a managed business environment.
Note We recommend that you temporarily apply these settings to evaluate system behavior. If your system performance or stability is improved by the recommendations that are made in this article, contact your antivirus software vendor for instructions or for an updated version or settings of the antivirus software.
Important This article contains information that shows how to help lower security settings or how to temporarily turn off security features on a computer. You can make these changes to understand the nature of a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.
For computers that are running Windows 7 and later versions of Windows
Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.
We are aware of the risk of excluding the specific files or folders that are mentioned in this article from scans that are made by your antivirus software. Your system will be safer if you do not exclude any files or folders from scans.
When you scan these files, performance and operating system reliability problems may occur because of file locking.
Do not exclude any one of these files based on the file name extension. For example, do not exclude all files that have a .dit extension. Microsoft has no control over other files that may use the same extensions as the files that are described in this article.
This article provides both file names and folders that can be excluded. All the files and folders that are described in this article are protected by default permissions to allow only SYSTEM and administrator access, and they contain only operating system components. Excluding an entire folder may be simpler but may not provide as much protection as excluding specific files based on file names.
Turn off scanning of Windows Update or Automatic Update related files
Turn off scanning of the Windows Update or Automatic Update database file (Datastore.edb). This file is located in the following folder:
Turn off scanning of the log files that are located in the following folder:
Specifically, exclude the following files:
The wildcard character (*) indicates that there may be several files.
Turn off scanning of Windows Security files
Add the following files in the %windir%\Security\Database path of the exclusions list:
Note If these files are not excluded, antivirus software may prevent proper access to these files, and security databases can become corrupted. Scanning these files can prevent the files from being used or may prevent a security policy from being applied to the files. These files should not be scanned because antivirus software may not correctly treat them as proprietary database files.
These are the recommended exclusions. There may be other file types that are not included in this article that should be excluded.
Turn off scanning of Group Policy-related files
Group Policy user registry information. These files are located in the following folder:
Specifically, exclude the following file:
Group Policy client settings files. These files are located in the following folder:
User registry information and supporting files. The files are located in the following folder:
Specifically, exclude the following files:
Running antivirus software on domain controllers
Because domain controllers provide an important service to clients, the risk of disruption of their activities from malicious code, from malware, or from a virus must be minimized. Antivirus software is the generally accepted way to reduce the risk of infection. Install and configure antivirus software so that the risk to the domain controller is reduced as much as possible and performance is affected as little as possible. The following list contains recommendations to help you configure and install antivirus software on a Windows Server domain controller.
Warning We recommend that you apply the following specified configuration to a test system to make sure that in your specific environment it does not introduce unexpected factors or compromise the stability of the system. The risk from too much scanning is that files are inappropriately flagged as changed. This causes too much replication in Active Directory. If testing verifies that replication is not affected by the following recommendations, you can apply the antivirus software to the production environment.
Note Specific recommendations from antivirus software vendors may supersede the recommendations in this article.
Antivirus software must be installed on all domain controllers in the enterprise. Ideally, try to install such software on all other server and client systems that have to interact with the domain controllers. It is optimal to catch the malware at the earliest point, such as at the firewall or at the client system where the malware is introduced. This prevents the malware from ever reaching the infrastructure systems that the clients depend on.
Use a version of antivirus software that is designed to work with Active Directory domain controllers and that uses the correct Application Programming Interfaces (APIs) to access files on the server. Older versions of most vendor software inappropriately change a file's metadata as the file is scanned. This causes the File Replication Service engine to recognize a file change and therefore schedule the file for replication. Newer versions prevent this problem.
For more information, see the following article in the Microsoft Knowledge Base:
815263 Antivirus, backup, and disk optimization programs that are compatible with the File Replication Service
Do not use a domain controller to browse the Internet or to perform other activities that may introduce malicious code.
We recommend that you minimize the workloads on domain controllers. When possible, avoid using domain controllers in a file server role. This lowers virus-scanning activity on file shares and minimizes performance overhead.
Do not put Active Directory or FRS database and log files on NTFS file system compressed volumes.
Turn off scanning of Active Directory and Active Directory-related files
Exclude the Main NTDS database files. The location of these files is specified in the following registr subkey:
The default location is %windir%\Ntfrs. Exclude the following files.
Note Settings for specific file exclusions is documented here for completeness. By default, these folders allow access only to System and Administrators. Please verify that the correct protections are in place. These folders contain only component working files for FRS and DFSR.
Edb*.log (if the registry key is not set)
FRS Working Dir\Jet\Log\Edb*.jrs
Turn off scanning of the NTFRS Staging folder as specified in the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Stage
By default, staging uses the following location:
Turn off scanning of the DFSR Staging folder as specified in the msDFSR-StagingPath attribute of the object CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DomainControllerName,OU=Domain Controllers,DC=DomainName in AD DS. This attribute contains the path to the actual location that DFS replication uses to stage files. Specifically, exclude the following files:
Turn off scanning of files in the Sysvol\Sysvol folder or the SYSVOL_DFSR\Sysvol folder.
The current location of the Sysvol\Sysvol or SYSVOL_DFSR\Sysvol folder and all the subfolders is the file system reparse target of the replica set root. The Sysvol\Sysvol and SYSVOL_DFSR\Sysvol folders use the following locations by default:
The Preinstall folder is always open when FRS is running.
Exclude the following files from this folder and all its subfolders:
Turn off scanning of files in the DFSR database and working folders. The location is specified by the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Services\DFSR\Parameters\Replication Groups\GUID\Replica Set Configuration File=Path
In this registry subkey, "Path" is the path of an XML file that states the name of the Replication Group. In this example, the path would contain "Domain System Volume."
The default location is the following hidden folder:
%systemdrive%\System Volume Information\DFSR
Exclude the following files from this folder and all its subfolders:
If any one of these folders or files is moved or is put in a different location, scan or exclude the equivalent element.
Turn off scanning of DFS files
The same resources that are excluded for a SYSVOL replica set must also be excluded when FRS or DFSR is used to replicate shares that are mapped to the DFS root and link targets on Windows Server 2008 R2-based or Windows Server 2008-based member computers or domain controllers.
Turn off scanning of DHCP files
By default, DHCP files that should be excluded are present in the following folder on the server:
Exclude the following files from this folder and all its subfolders:
The location of DHCP files can be changed. To determine the current location of the DHCP files on the server, check the DatabasePath, DhcpLogFilePath, and BackupDatabasePath parameters that are specified in the following registry subkey:
Exclude the following files from this folder and all its subfolders:
Turn off scanning of WINS files
By default, WINS uses the following folder:
Exclude the following files from this folder and all its subfolders:
For computers that are running Hyper-V based versions of Windows
In some scenarios, on a Windows Server 2008-based computer that has the Hyper-V role installed or on a Microsoft Hyper-V Server 2008 or on a Microsoft Hyper-V Server 2008 R2-based computer, it may be necessary to configure the real-time scanning component within the antivirus software to exclude files and entire folders. For more information, see the following article in the Microsoft Knowledge Base:
961804 Virtual machines are missing, or error 0x800704C8, 0x80070037, or 0x800703E3 occurs when you try to start or create a virtual machine
Cybercriminals will stop at nothing to exploit every chance to prey on internet users.
Even the disastrous spread of SARS-COV-II (the virus), which causes COVID-19 (the disease), is becoming an opportunity for them to likewise spread malware or launch cyber attacks.
Reason Cybersecurity recently released a threat analysis report detailing a new attack that takes advantage of internet users' increased craving for information about the novel coronavirus that is wreaking havoc worldwide.
The malware attack specifically aims to target those who are looking for cartographic presentations of the spread of COVID-19 on the Internet, and trickes them to download and run a malicious application that, on its front-end, shows a map loaded from a legit online source but in the background compromises the computer.
New Threat With An Old Malware Component
The latest threat, designed to steal information from unwitting victims, was first spotted by MalwareHunterTeam last week and has now been analyzed by Shai Alfasi, a cybersecurity researcher at Reason Labs.
It involves a malware identified as AZORult, an information-stealing malicious software discovered in 2016. AZORult malware collects information stored in web browsers, particularly cookies, browsing histories, user IDs, passwords, and even cryptocurrency keys.
With these data drawn from browsers, it is possible for cybercriminals to steal credit card numbers, login credentials, and various other sensitive information.
AZORult is reportedly discussed in Russian underground forums as a tool for gathering sensitive data from computers. It comes with a variant that is capable of generating a hidden administrator account in infected computers to enable connections via the remote desktop protocol (RDP).
Alfasi provides technical details upon studying the malware, which is embedded in the file, usually named as Corona-virus-Map.com.exe. It's a small Win32 EXE file with a payload size of only around 3.26 MB.
Double-clicking the file opens a window that shows various information about the spread of COVID-19. The centerpiece is a "map of infections" similar to the one hosted by Johns Hopkins University, a legitimate online source to visualize and track reported coronavirus cases in the real-time.
Numbers of confirmed cases in different countries are presented on the left side while stats on deaths and recoveries are on the right. The window appears to be interactive, with tabs for various other related information and links to sources.
It presents a convincing GUI not many would suspect to be harmful. The information presented is not an amalgamation of random data, instead is actual COVID-19 information pooled from the Johns Hopkins website.
To be noted, the original coronavirus map hosted online by Johns Hopkins University or ArcGIS is not infect or backdoored in any way and are safe to visit.
The malicious software utilizes some layers of packing along with a multi-sub-process technique infused to make it challenging for researchers to detect and analyze. Additionally, it employs a task scheduler so it can continue operating.
Signs of Infection
Executing the Corona-virus-Map.com.exe results in the creation of duplicates of the Corona-virus-Map.com.exe file and multiple Corona.exe, Bin.exe, Build.exe, and Windows.Globalization.Fontgroups.exe files.
Additionally, the malware modifies a handful of registers under ZoneMap and LanguageList. Several mutexes are also created.
Execution of the malware activates the following processes: Bin.exe, Windows.Globalization.Fontgroups.exe, and Corona-virus-Map.com.exe. These attempt to connect to several URLs.
These processes and URLs are only a sample of what the attack entails. There are many other files generated and processes initiated. They create various network communication activities as malware tries to gather different kinds of information.
How the Attack Steals Information
Alfasi presented a detailed account of how he dissected the malware in a blog post on the Reason Security blog. One highlight detail is his analysis of the Bin.exe process with Ollydbg. Accordingly, the process wrote some dynamic link libraries (DLL). The DLL "nss3.dll" caught his attention as it is something he was acquainted with from different actors.
Alfasi observed a static loading of APIs associated with nss3.dll. These APIs appeared to facilitate the decryption of saved passwords as well as the generation of output data.
This is a common approach used by data thieves. Relatively simple, it only captures the login data from the infected web browser and moves it to the C:\Windows\Temp folder. It's one of the hallmarks of an AZORult attack, wherein the malware extracts data, generates a unique ID of the infected computer, applies XOR encryption, then initiates C2 communication.
The malware makes specific calls in an attempt to steal login data from common online accounts such as Telegram and Steam.
To emphasize, malware execution is the only step needed for it to proceed with its information-stealing processes. Victims don't need to interact with the window or input sensitive information therein.
Cleaning and Prevention
It may sound promotional, but Alfasi suggests Reason Antivirus software as the solution to fix infected devices and prevent further attacks. He is affiliated with Reason Security, after all. Reason is the first to find and scrutinize this new threat, so they can handle it effectively.
Other security firms are likely to have already learned about this threat, since Reason made it public on March 9. Their antiviruses or malware protection tools will have been updated as of publication time.
As such, they may be similarly capable of detecting and preventing the new threat.
The key to removing and stopping the opportunistic "coronavirus map" malware is to have the right malware protection system. It will be challenging to detect it manually, let alone remove the infection without the right software tool.
It may not be enough to be cautious in downloading and running files from the internet, as many tend to be overeager in accessing information about the novel coronavirus nowadays.
The pandemic level dispersion of COVID-19 merits utmost caution not only offline (to avoid contracting the disease) but also online. Cyber attackers are exploiting the popularity of coronavirus-related resources on the web, and many will likely fall prey to the attacks.
Microsoft today finally released an emergency software update to patch the recently disclosed very dangerous vulnerability in SMBv3 protocol that could let attackers launch wormable malware, which can propagate itself from one vulnerable computer to another automatically.
The vulnerability, tracked as CVE-2020-0796, in question is a remote code execution flaw that impacts Windows 10 version 1903 and 1909, and Windows Server version 1903 and 1909.
Server Message Block (SMB), which runs over TCP port 445, is a network protocol that has been designed to enable file sharing, network browsing, printing services, and interprocess communication over a network.
The latest vulnerability, for which a patch update (KB4551762) is now available on the Microsoft website, exists in the way SMBv3 protocol handles requests with compression headers, making it possible for unauthenticated remote attackers to execute malicious code on target servers or clients with SYSTEM privileges.
Compression headers is a feature that was added to the affected protocol of Windows 10 and Windows Server operating systems in May 2019, designed to compress the size of messages exchanged between a sever and clients connected to it.
"To exploit the vulnerability against a server, an unauthenticated attacker could send a specially crafted packet to a targeted SMBv3 server. To exploit the vulnerability against a client, an unauthenticated attacker would need to configure a malicious SMBv3 server and convince a user to connect to it," Microsoft said in the advisory.
At the time of writing, there is only one known PoC exploit that exists for this critical remotely exploitable flaw, but reverse engineering new patches could now also help hackers find possible attack vectors to develop fully weaponized self-propagating malware.
A separate team of researchers have also published a detailed technical analysis of the vulnerability, concluding a kernel pool overflow as the root cause of the issue.
As of today, there are nearly 48,000 Windows systems vulnerable to the latest SMB compression vulnerability and accessible over the Internet.
Since a patch for the wormable SMBv3 flaw is now available to download for affected versions of Windows, it's highly recommended for home users and businesses to install updates as soon as possible, rather than merely relying on the mitigation.
In cases where immediate patch update is not applicable, it's advised to at least disable SMB compression feature and block SMB port for both inbound and outbound connections to help prevent remote exploitation.
By now, you’ve likely heard of Microsoft’s relatively recent file system “ReFS”. Introduced with Windows Server 2012, it seeks to exceed NTFS in stability and scalability. Since we typically store the VHDXs for multiple virtual machines in the same volume, it seems as though it pairs well with ReFS. Unfortunately, it did not… in the beginning. Microsoft has continued to improve ReFS in the intervening years. It has gained several features that distanced it from NTFS. With its maturation, should you start using it for Hyper-V? You have much to consider before making that determination.
Integration with Storage Spaces: Many of ReFS’s features only work to their fullest in conjunction with Storage Spaces.
Before you get excited about some of the earlier points, I need to emphasize one thing: except for capacity limits, ReFS requires Storage Spaces in order to do its best work.
ReFS Benefits for Hyper-V
ReFS has features that accelerate some virtual machine activities.
Block cloning: By my reading, block cloning is essentially a form of de-duplication. But, it doesn’t operate as a file system filter or scanner. It doesn’t passively wait for arbitrary data writes or periodically scan the file system for duplicates. Something must actively invoke it against a specific file. Microsoft specifically indicates that it can greatly speed checkpoint merges.
Sparse VDL (valid data length): All file systems record the amount of space allocated to a file. ReFS uses VDL to indicate how much of that file has data. So, when you instruct Hyper-V to create a new fixed VHDX on ReFS, it can create the entire file in about the same amount of time as creating a dynamically-expanding VHDX. It will similarly benefit expansion operations on dynamically-expanding VHDXs.
Take a little bit of time to go over these features. Think through their total applications.
ReFS vs. NTFS for Hyper-V: Technical Comparison
With the general explanation out of the way, now you can make a better assessment of the differences. First, check the comparison tables on Microsoft’s ReFS overview page. For typical Hyper-V deployments, most of the differences mean very little. For instance, you probably don’t need quotas on your Hyper-V storage locations. Let’s make a table of our own, scoped more appropriately for Hyper-V:
ReFS wins: Really large storage locations and really large VHDXs
ReFS wins: Environments with excessively high incidences of created, checkpointed, or merged VHDXs
ReFS wins: Storage Space and Storage Spaces Direct deployments
I think most of these things speak for themselves. The last two probably need a bit more explanation.
Single-Volume Deployments Require NTFS
In this context, I intend “single-volume deployment” to mean installations where you have Hyper-V (including its management operating system) and all VMs on the same volume. You cannot format a boot volume with ReFS, nor can you place a page file on ReFS. Such an installation also does not allow for Storage Spaces or Storage Spaces Direct, so it would miss out on most of ReFS’s capabilities anyway.
Mixed-Purpose Deployments Might Require NTFS
Some of us have the luck to deploy nothing but virtual machines on dedicated storage locations. Not everyone has that. If your Hyper-V storage volume also hosts files for other purposes, you might need to continue with NTFS. Go over the last table near the bottom of the overview page. It shows the properties that you can only find in NTFS. For standard file sharing scenarios, you lose quotas. You may have legacy applications that require NTFS’s extended properties, or short names. In these situations, only NTFS will do.
Note: If you have any alternative, do not use the same host to run non-Hyper-V roles alongside Hyper-V. Microsoft does not support mixing. Similarly, separate Hyper-V VMs onto volumes apart from volumes that hold other file types.
Unexpected ReFS Behavior
The official content goes to some lengths to describe the benefits of ReFS’s integrity streams. It uses checksums to detect file corruption. If it finds problems, it engages in corrective action. On a Storage Spaces volume that uses protective schemes, it has an opportunity to fix the problem. It does that with the volume online, providing a seamless experience. But, what happens when ReFS can’t correct the problem? That’s where you need to pay real attention.
On the overview page, the documentation uses exceptionally vague wording: “ReFS removes the corrupt data from the namespace”. The integrity streams page does worse: “If the attempt is unsuccessful, ReFS will return an error.” While researching this article, I was told of a more troubling activity: ReFS deletes files that it deems unfixable. The comment section at the bottom of that page includes a corroborating report. If you follow that comment thread through, you’ll find an entry from a Microsoft program manager that states:
ReFS deletes files in two scenarios:
ReFS detects Metadata corruption AND there is no way to fix it. Meaning ReFS is not on a Storage Spaces redundant volume where it can fix the corrupted copy.
ReFS detects data corruption AND Integrity Stream is enabled AND there is no way to fix it. Meaning if Integrity Stream is not enabled, the file will be accessible whether data is corrupted or not. If ReFS is running on a mirrored volume using Storage Spaces, the corrupted copy will be automatically fixed.
The upshot: If ReFS decides that a VHDX has sustained unrecoverable damage, it will delete it. It will not ask, nor will it give you any opportunity to try to salvage what you can. If ReFS isn’t backed by Storage Spaces’s redundancy, then it has no way to perform a repair. So, from one perspective, that makes ReFS on non-Storage Spaces look like a very high risk approach. But…
Mind Your Backups!
You should not overlook the severity of the previous section. However, you should not let it scare you away, either. I certainly understand that you might prefer a partially readable VHDX to a deleted one. To that end, you could simply disable integrity streams on your VMs’ files. I also have another suggestion.
Do not neglect your backups! If ReFS deletes a file, retrieve it from backup. If a VHDX goes corrupt on NTFS, retrieve it from backup. With ReFS, at least you know that you have a problem. With NTFS, problems can lurk much longer. No matter your configuration, the only thing you can depend on to protect your data is a solid backup solution.
When to Choose NTFS for Hyper-V
You now have enough information to make an informed decision. These conditions indicate a good condition for NTFS:
Configurations that do not use Storage Spaces, such as single-disk or manufacturer RAID. This alone does not make an airtight point; please read the “Mind Your Backups!” section above.
Single-volume systems (your host only has a C: volume)
Mixed-purpose systems (please reconfigure to separate roles)
Storage on hosts older than 2016 — ReFS was not as mature on previous versions. This alone is not an airtight point.
Your backup application vendor does not support ReFS
If you’re uncertain about ReFS
As time goes on, NTFS will lose favorability over ReFS in Hyper-V deployments. But, that does not mean that NTFS has reached its end. ReFS has staggeringly higher limits, but very few systems use more than a fraction of what NTFS can offer. ReFS does have impressive resilience features, but NTFS also has self-healing powers and you have access to RAID technologies to defend against data corruption.
Microsoft will continue to develop ReFS. They may eventually position it as NTFS’s successor. As of today, they have not done so. It doesn’t look like they’ll do it tomorrow, either. Do not feel pressured to move to ReFS ahead of your comfort level.
When to Choose ReFS for Hyper-V
Some situations make ReFS the clear choice for storing Hyper-V data:
You might make an additional performance-based argument for ReFS in an environment with a very high churn of VHDX files. However, do not overestimate the impact of those performance enhancements. The most striking difference appears when you create fixed VHDXs. For all other operations, you need to upgrade your hardware to achieve meaningful improvement.
However, I do not want to gloss over the benefit of ReFS for very large volumes. If you have storage volume of a few terabytes and VHDXs of even a few hundred gigabytes, then ReFS will rarely beat NTFS significantly. When you start thinking in terms of hundreds of terabytes, NTFS will likely show bottlenecks. If you need to push higher, then ReFS becomes your only choice.
ReFS really shines when you combine it with Storage Spaces Direct. Its ability to automatically perform a non-disruptive online repair is truly impressive. On the one hand, the odds of disruptive data corruption on modern systems constitute a statistical anomaly. On the other, no one that has suffered through such an event really cares how unlikely it was.
ReFS vs NTFS on Hyper-V Guest File Systems
All of the above deals only with Hyper-V’s storage of virtual machines. What about ReFS in guest operating systems?
To answer that question, we need to go back to ReFS’s strengths. So far, we’ve only thought about it in terms of Hyper-V. Guests have their own conditions and needs. Let’s start by reviewing Microsoft’s ReFS overview. Specifically the following:
“Microsoft has developed NTFS specifically for general-purpose use with a wide range of configurations and workloads, however for customers specially requiring the availability, resiliency, and/or scale that ReFS provides, Microsoft supports ReFS for use under the following configurations and scenarios…”
I added emphasis on the part that I want you to consider. The sentence itself makes you think that they’ll go on to list some usages, but they only list one: “backup target”. The other items on their list only talk about the storage configuration. So, we need to dig back into the sentence and pull out those three descriptors to help us decide: “availability”, “resiliency”, and “scale”. You can toss out the first two right away — you should not focus on storage availability and resiliency inside a VM. That leaves us with “scale”. So, really big volumes and really big files. Remember, that means hundreds of terabytes and up.
For a more accurate decision, read through the feature comparisons. If any application that you want to use inside a guest needs features only found on NTFS, use NTFS. Personally, I still use NTFS inside guests almost exclusively. ReFS needs Storage Spaces to do its best work, and Storage Spaces does its best work at the physical layer.
Combining ReFS with NTFS across Hyper-V Host and Guests
Keep in mind that the file system inside a guest has no bearing on the host’s file system, and vice versa. As far as Hyper-V knows, VHDXs attached to virtual machines are nothing other than a bundle of data blocks. You can use any combination that works.
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:
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:
A public and private key is generated to represent the identity.
A “Certificate Signing Request” (CSR) is generated using the public key and some information about the identity.
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.
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 abilityto auto-enroll a certificate by setting security on the template. You use group policy to set the scopeof who will attemptto 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 Configuration\Policies\Windows Settings\Security Settings\Public 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.
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.
From the File menu, select Add/Remove Snap-in…
Highlight Certificates and click Add:
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.
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.
If you selected Service account in step 4, you will now have a list of service accounts to choose from.
If you want, you can repeat the above steps to connect one console to multiple targets:
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:
Right-click Certificates and click Request New Certificate.
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.
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:
Right-click Certificates, go to All Tasks, then Advanced Operations, and click Create Custom Request.
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.
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.
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.
Choose the output file name and format. Most CAs will work with either type. Most prefer the default of Base64.
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.
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.
Locate the [ req ] section. Find the following line, and remove the # that comments it out (or add it if it is not present):
req_extensions = v3_req
Locate the section named [ v3_req ]. Create one if you cannot find it. Add the following line:
subjectAltName = @alt_names
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.
[ 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
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.
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:
Execute the following (feel free to research these options and change any to fit your needs):
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.
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.
Transfer the CSR file to a Windows system using the tool of your choice.
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.
The utility will ask you to browse to the request file. You may need to change the filter to select all files.
You will next need to select the certification authority.
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):
Transfer the certificate file back to the Linux system.
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:
Open Internet Information Services (IIS) Manager on the system running the Web Enrollment service or on any system that can connect to it.
Highlight the server in the left pane. In the right pane, under IIS, double-click Server Certificates.
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.
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.
Double-click the https line or highlight it and click Edit… at the right.
Under SSL certificate, choose the newly-issued certificate. Click OK, then Close to return to IIS Manager.
Drill down under Default web site and click on CertSrv. In the center pane, double-click Authentication.
In the center pane, highlight Windows Authentication. It should already be Enabled. In the right pane, click Providers.
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.
Exchange Management Console
Other tools exist.
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.
When installing Windows Server 2019, as with previous versions of Windows, you are prompted to enter the product key during installation, however if you are waiting for licensing to arrive, you can skip this and continue building your server. Once the licensing arrives, you can enter the product key from the Settings app, but in my case, clicking the Change Product Key button resulted in absolutely nothing. The window did not pop up, no error in the event logs, nothing at all. In this article, I will show you how to enter your product key manually using command line utilities, then activating using the same utility.
Click Start and type CMD in the Start Search menu
Right Click and choose Run as administrator
To remove any existing product key (in case you used a trial key), enter and run the command slmgr.vbs /upk .
Clear the product key from registry by running slmgr.vbs /cpky
To enter your new product key, use the command: slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx where the x’s are your actual product key.
Lastly, activate Windows by entering the command slmgr.vbs /ato
Windows is now activated.
From my research, this appears to be a fairly common issue. Some users reported completely reloading Windows and entering the key from the start to resolve the issue, but if you have already configured the server or workstation, that’s not really an option. After running the above commands, my servers were activated and running normally. So far, this is my only hiccup with Server 2019.