General Remote Desktop connection troubleshooting

Use these steps when a Remote Desktop client can’t connect to a remote desktop but doesn’t provide messages or other symptoms that would help identify the cause.

Check the status of the RDP protocol

Check the status of the RDP protocol on a local computer

To check and change the status of the RDP protocol on a local computer, see How to enable Remote Desktop.


If the remote desktop options are not available, see Check whether a Group Policy Object is blocking RDP.

Check the status of the RDP protocol on a remote computer


Follow this section’s instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you start modifying the registry, back up the registry so you can restore it in case something goes wrong.

To check and change the status of the RDP protocol on a remote computer, use a network registry connection:

  1. First, go to the Start menu, then select Run. In the text box that appears, enter regedt32.
  2. In the Registry Editor, select File, then select Connect Network Registry.
  3. In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
  4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server and to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
    Registry Editor, showing the fDenyTSConnections entry
    • If the value of the fDenyTSConnections key is 0, then RDP is enabled.
    • If the value of the fDenyTSConnections key is 1, then RDP is disabled.
  5. To enable RDP, change the value of fDenyTSConnections from 1 to 0.

Check whether a Group Policy Object (GPO) is blocking RDP on a local computer

If you can’t turn on RDP in the user interface or the value of fDenyTSConnections reverts to 1 after you’ve changed it, a GPO may be overriding the computer-level settings.

To check the group policy configuration on a local computer, open a Command Prompt window as an administrator, and enter the following command:

Windows Command PromptCopy

gpresult /H c:\gpresult.html

After this command finishes, open gpresult.html. In Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections, find the Allow users to connect remotely by using Remote Desktop Services policy.

  • If the setting for this policy is Enabled, Group Policy is not blocking RDP connections.
  • If the setting for this policy is Disabled, check Winning GPO. This is the GPO that is blocking RDP connections. An example segment of gpresult.html, in which the domain-level GPO Block RDP is disabling RDP.An example segment of gpresult.html, in which Local Group Policy is disabling RDP.

Check whether a GPO is blocking RDP on a remote computer

To check the Group Policy configuration on a remote computer, the command is almost the same as for a local computer:

Windows Command PromptCopy

gpresult /S <computer name> /H c:\gpresult-<computer name>.html

The file that this command produces (gpresult-<computer name>.html) uses the same information format as the local computer version (gpresult.html) uses.

Modifying a blocking GPO

You can modify these settings in the Group Policy Object Editor (GPE) and Group Policy Management Console (GPM). For more information about how to use Group Policy, see Advanced Group Policy Management.

To modify the blocking policy, use one of the following methods:

  • In GPE, access the appropriate level of GPO (such as local or domain), and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services.
    1. Set the policy to either Enabled or Not configured.
    2. On the affected computers, open a command prompt window as an administrator, and run the gpupdate /force command.
  • In GPM, navigate to the organizational unit (OU) in which the blocking policy is applied to the affected computers and delete the policy from the OU.

Check the status of the RDP services

On both the local (client) computer and the remote (target) computer, the following services should be running:

  • Remote Desktop Services (TermService)
  • Remote Desktop Services UserMode Port Redirector (UmRdpService)

You can use the Services MMC snap-in to manage the services locally or remotely. You can also use PowerShell to manage the services locally or remotely (if the remote computer is configured to accept remote PowerShell cmdlets).

Remote Desktop services in the Services MMC snap-in. Do not modify the default service settings.

On either computer, if one or both services are not running, start them.


If you start the Remote Desktop Services service, click Yes to automatically restart the Remote Desktop Services UserMode Port Redirector service.

Check that the RDP listener is functioning


Follow this section’s instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.

Check the status of the RDP listener

For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work both locally and remotely.

  1. To connect to a remote computer, run the following cmdlet:PowerShellCopyEnter-PSSession -ComputerName <computer name>
  2. Enter qwinstaThe qwinsta command lists the processes listening on the computer's ports.
  3. If the list includes rdp-tcp with a status of Listen, the RDP listener is working. Proceed to Check the RDP listener port. Otherwise, continue at step 4.
  4. Export the RDP listener configuration from a working computer.
    1. Sign in to a computer that has the same operating system version as the affected computer has, and access that computer’s registry (for example, by using Registry Editor).
    2. Navigate to the following registry entry:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    3. Export the entry to a .reg file. For example, in Registry Editor, right-click the entry, select Export, and then enter a filename for the exported settings.
    4. Copy the exported .reg file to the affected computer.
  5. To import the RDP listener configuration, open a PowerShell window that has administrative permissions on the affected computer (or open the PowerShell window and connect to the affected computer remotely).
    1. To back up the existing registry entry, enter the following cmdlet:PowerShellCopycmd /c 'reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp" C:\Rdp-tcp-backup.reg'
    2. To remove the existing registry entry, enter the following cmdlets:PowerShellCopyRemove-Item -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp' -Recurse -Force
    3. To import the new registry entry and then restart the service, enter the following cmdlets:PowerShellCopycmd /c 'regedit /s c:\<filename>.reg' Restart-Service TermService -Force Replace <filename> with the name of the exported .reg file.
  6. Test the configuration by trying the remote desktop connection again. If you still can’t connect, restart the affected computer.
  7. If you still can’t connect, check the status of the RDP self-signed certificate.

Check the status of the RDP self-signed certificate

  1. If you still can’t connect, open the Certificates MMC snap-in. When you are prompted to select the certificate store to manage, select Computer account, and then select the affected computer.
  2. In the Certificates folder under Remote Desktop, delete the RDP self-signed certificate. Remote Desktop certificates in the MMC Certificates snap-in.
  3. On the affected computer, restart the Remote Desktop Services service.
  4. Refresh the Certificates snap-in.
  5. If the RDP self-signed certificate has not been recreated, check the permissions of the MachineKeys folder.

Check the permissions of the MachineKeys folder

  1. On the affected computer, open Explorer, and then navigate to C:\ProgramData\Microsoft\Crypto\RSA\.
  2. Right-click MachineKeys, select Properties, select Security, and then select Advanced.
  3. Make sure that the following permissions are configured:
    • Builtin\Administrators: Full control
    • Everyone: Read, Write

Check the RDP listener port

On both the local (client) computer and the remote (target) computer, the RDP listener should be listening on port 3389. No other applications should be using this port.


Follow this section’s instructions carefully. Serious problems can occur if the registry is modified incorrectly. Before you starty modifying the registry, back up the registry so you can restore it in case something goes wrong.

To check or change the RDP port, use the Registry Editor:

  1. Go to the Start menu, select Run, then enter regedt32 into the text box that appears.
    • To connect to a remote computer, select File, and then select Connect Network Registry.
    • In the Select Computer dialog box, enter the name of the remote computer, select Check Names, and then select OK.
  2. Open the registry and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<listener>The PortNumber subkey for the RDP protocol.
  3. If PortNumber has a value other than 3389, change it to 3389. ImportantYou can operate Remote Desktop services using another port. However, we don’t recommend you do this. This article doesn’t cover how to troubleshoot that type of configuration.
  4. After you change the port number, restart the Remote Desktop Services service.

Check that another application isn’t trying to use the same port

For this procedure, use a PowerShell instance that has administrative permissions. For a local computer, you can also use a command prompt that has administrative permissions. However, this procedure uses PowerShell because the same cmdlets work locally and remotely.

  1. Open a PowerShell window. To connect to a remote computer, enter Enter-PSSession -ComputerName <computer name>.
  2. Enter the following command:PowerShellCopycmd /c 'netstat -ano | find "3389"' The netstat command produces a list of ports and the services listening to them.
  3. Look for an entry for TCP port 3389 (or the assigned RDP port) with a status of Listening. NoteThe process identifier (PID) for the process or service using that port appears under the PID column.
  4. To determine which application is using port 3389 (or the assigned RDP port), enter the following command:PowerShellCopycmd /c 'tasklist /svc | find "<pid listening on 3389>"' The tasklist command reports details of a specific process.
  5. Look for an entry for the PID number that is associated with the port (from the netstat output). The services or processes that are associated with that PID appear on the right column.
  6. If an application or service other than Remote Desktop Services (TermServ.exe) is using the port, you can resolve the conflict by using one of the following methods:
    • Configure the other application or service to use a different port (recommended).
    • Uninstall the other application or service.
    • Configure RDP to use a different port, and then restart the Remote Desktop Services service (not recommended).

Check whether a firewall is blocking the RDP port

Use the psping tool to test whether you can reach the affected computer by using port 3389.

  1. Go to a different computer that isn’t affected and download psping from
  2. Open a command prompt window as an administrator, change to the directory in which you installed psping, and then enter the following command:Copypsping -accepteula <computer IP>:3389
  3. Check the output of the psping command for results such as the following:
    • Connecting to <computer IP>: The remote computer is reachable.
    • (0% loss): All attempts to connect succeeded.
    • The remote computer refused the network connection: The remote computer is not reachable.
    • (100% loss): All attempts to connect failed.
  4. Run psping on multiple computers to test their ability to connect to the affected computer.
  5. Note whether the affected computer blocks connections from all other computers, some other computers, or only one other computer.
  6. Recommended next steps:
    • Engage your network administrators to verify that the network allows RDP traffic to the affected computer.
    • Investigate the configurations of any firewalls between the source computers and the affected computer (including Windows Firewall on the affected computer) to determine whether a firewall is blocking the RDP port.

Source :

Cloudflare mitigates record-breaking 71 million request-per-second DDoS attack

This was a weekend of record-breaking DDoS attacks. Over the weekend, Cloudflare detected and mitigated dozens of hyper-volumetric DDoS attacks. The majority of attacks peaked in the ballpark of 50-70 million requests per second (rps) with the largest exceeding 71 million rps. This is the largest reported HTTP DDoS attack on record, more than 35% higher than the previous reported record of 46M rps in June 2022.

The attacks were HTTP/2-based and targeted websites protected by Cloudflare. They originated from over 30,000 IP addresses. Some of the attacked websites included a popular gaming provider, cryptocurrency companies, hosting providers, and cloud computing platforms. The attacks originated from numerous cloud providers, and we have been working with them to crack down on the botnet.

Record breaking attack: DDoS attack exceeding 71 million requests per second

Over the past year, we’ve seen more attacks originate from cloud computing providers. For this reason, we will be providing service providers that own their own autonomous system a free Botnet threat feed. The feed will provide service providers threat intelligence about their own IP space; attacks originating from within their autonomous system. Service providers that operate their own IP space can now sign up to the early access waiting list.

No. This campaign of attacks arrives less than two weeks after the Killnet DDoS campaign that targeted healthcare websites. Based on the methods and targets, we do not believe that these recent attacks are related to the healthcare campaign. Furthermore, yesterday was the US Super Bowl, and we also do not believe that this attack campaign is related to the game event.

What are DDoS attacks?

Distributed Denial of Service attacks are cyber attacks that aim to take down Internet properties and make them unavailable for users. These types of cyberattacks can be very efficient against unprotected websites and they can be very inexpensive for the attackers to execute.

An HTTP DDoS attack usually involves a flood of HTTP requests towards the target website. The attacker’s objective is to bombard the website with more requests than it can handle. Given a sufficiently high amount of requests, the website’s server will not be able to process all of the attack requests along with the legitimate user requests. Users will experience this as website-load delays, timeouts, and eventually not being able to connect to their desired websites at all.

Illustration of a DDoS attack

To make attacks larger and more complicated, attackers usually leverage a network of bots — a botnet. The attacker will orchestrate the botnet to bombard the victim’s websites with HTTP requests. A sufficiently large and powerful botnet can generate very large attacks as we’ve seen in this case.

However, building and operating botnets requires a lot of investment and expertise. What is the average Joe to do? Well, an average Joe that wants to launch a DDoS attack against a website doesn’t need to start from scratch. They can hire one of numerous DDoS-as-a-Service platforms for as little as $30 per month. The more you pay, the larger and longer of an attack you’re going to get.

Why DDoS attacks?

Over the years, it has become easier, cheaper, and more accessible for attackers and attackers-for-hire to launch DDoS attacks. But as easy as it has become for the attackers, we want to make sure that it is even easier – and free – for defenders of organizations of all sizes to protect themselves against DDoS attacks of all types.

Unlike Ransomware attacks, Ransom DDoS attacks don’t require an actual system intrusion or a foothold within the targeted network. Usually Ransomware attacks start once an employee naively clicks an email link that installs and propagates the malware. There’s no need for that with DDoS attacks. They are more like a hit-and-run attack. All a DDoS attacker needs to know is the website’s address and/or IP address.

Is there an increase in DDoS attacks?

Yes. The size, sophistication, and frequency of attacks has been increasing over the past months. In our latest DDoS threat report, we saw that the amount of HTTP DDoS attacks increased by 79% year-over-year. Furthermore, the amount of volumetric attacks exceeding 100 Gbps grew by 67% quarter-over-quarter (QoQ), and the number of attacks lasting more than three hours increased by 87% QoQ.

But it doesn’t end there. The audacity of attackers has been increasing as well. In our latest DDoS threat report, we saw that Ransom DDoS attacks steadily increased throughout the year. They peaked in November 2022 where one out of every four surveyed customers reported being subject to Ransom DDoS attacks or threats.

Distribution of Ransom DDoS attacks by month

Should I be worried about DDoS attacks?

Yes. If your website, server, or networks are not protected against volumetric DDoS attacks using a cloud service that provides automatic detection and mitigation, we really recommend that you consider it.

Cloudflare customers shouldn’t be worried, but should be aware and prepared. Below is a list of recommended steps to ensure your security posture is optimized.

What steps should I take to defend against DDoS attacks?

Cloudflare’s systems have been automatically detecting and mitigating these DDoS attacks.

Cloudflare offers many features and capabilities that you may already have access to but may not be using. So as extra precaution, we recommend taking advantage of these capabilities to improve and optimize your security posture:

  1. Ensure all DDoS Managed Rules are set to default settings (High sensitivity level and mitigation actions) for optimal DDoS activation.
  2. Cloudflare Enterprise customers that are subscribed to the Advanced DDoS Protection service should consider enabling Adaptive DDoS Protection, which mitigates attacks more intelligently based on your unique traffic patterns.
  3. Deploy firewall rules and rate limiting rules to enforce a combined positive and negative security model. Reduce the traffic allowed to your website based on your known usage.
  4. Ensure your origin is not exposed to the public Internet (i.e., only enable access to Cloudflare IP addresses). As an extra security precaution, we recommend contacting your hosting provider and requesting new origin server IPs if they have been targeted directly in the past.
  5. Customers with access to Managed IP Lists should consider leveraging those lists in firewall rules. Customers with Bot Management should consider leveraging the threat scores within the firewall rules.
  6. Enable caching as much as possible to reduce the strain on your origin servers, and when using Workers, avoid overwhelming your origin server with more subrequests than necessary.
  7. Enable DDoS alerting to improve your response time.

Preparing for the next DDoS wave

Defending against DDoS attacks is critical for organizations of all sizes. While attacks may be initiated by humans, they are executed by bots — and to play to win, you must fight bots with bots. Detection and mitigation must be automated as much as possible, because relying solely on humans to mitigate in real time puts defenders at a disadvantage. Cloudflare’s automated systems constantly detect and mitigate DDoS attacks for our customers, so they don’t have to. This automated approach, combined with our wide breadth of security capabilities, lets customers tailor the protection to their needs.

We’ve been providing unmetered and unlimited DDoS protection for free to all of our customers since 2017, when we pioneered the concept. Cloudflare’s mission is to help build a better Internet. A better Internet is one that is more secure, faster, and reliable for everyone – even in the face of DDoS attacks.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet applicationward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you’re looking for a new career direction, check out our open positions.

Source :

3 Overlooked Cybersecurity Breaches

Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.

#1: 2 RaaS Attacks in 13 Months#

Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from other threat actors and ransomware gangs. Common purchasing plans include buying the entire tool, using the existing infrastructure while paying per infection, or letting other attackers perform the service while sharing revenue with them.

In this attack, the threat actor consists of one of the most prevalent ransomware groups, specializing in access via third parties, while the targeted company is a medium-sized retailer with dozens of sites in the United States.

The threat actors used ransomware as a service to breach the victim’s network. They were able to exploit third-party credentials to gain initial access, progress laterally, and ransom the company, all within mere minutes.

The swiftness of this attack was unusual. In most RaaS cases, attackers usually stay in the networks for weeks and months before demanding ransom. What is particularly interesting about this attack is that the company was ransomed in minutes, with no need for discovery or weeks of lateral movement.

A log investigation revealed that the attackers targeted servers that did not exist in this system. As it turns out, the victim was initially breached and ransomed 13 months before this second ransomware attack. Subsequently, the first attacker group monetized the first attack not only through the ransom they obtained, but also by selling the company’s network information to the second ransomware group.

In the 13 months between the two attacks, the victim changed its network and removed servers, but the new attackers were not aware of these architectural modifications. The scripts they developed were designed for the previous network map. This also explains how they were able to attack so quickly – they had plenty of information about the network. The main lesson here is that ransomware attacks can be repeated by different groups, especially if the victim pays well.

“RaaS attacks such as this one are a good example of how full visibility allows for early alerting. A global, converged, cloud-native SASE platform that supports all edges, like Cato Networks provides complete network visibility into network events that are invisible to other providers or may go under the radar as benign events. And, being able to fully contextualize the events allows for early detection and remediation.

#2: The Critical Infrastructure Attack on Radiation Alert Networks#

Attacks on critical infrastructure are becoming more common and more dangerous. Breaches of water supply plants, sewage systems and other such infrastructures could put millions of residents at risk of a human crisis. These infrastructures are also becoming more vulnerable, and attack surface management tools for OSINT like Shodan and Censys allow security teams to find such vulnerabilities with ease.

In 2021, two hackers were suspected of targeting radiation alert networks. Their attack relied on two insiders that worked for a third party. These insiders disabled the radiation alert systems, significantly debilitating their ability to monitor radiation attacks. The attackers were then able to delete critical software and disable radiation gauges (which is part of the infrastructure itself).

Cybersecurity Breaches

“Unfortunately, scanning for vulnerable systems in critical infrastructure is easier than ever. While many such organizations have multiple layers of security, they are still using point solutions to try and defend their infrastructure rather than one system that can look holistically at the full attack lifecycle. Breaches are never just a phishing problem, or a credentials problem, or a vulnerable system problem – they are always a combination of multiple compromises performed by the threat actor,” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

#3: The Three-Step Ransomware Attack That Started with Phishing#

The third attack is also a ransomware attack. This time, it consisted of three steps:

1. Infiltration – The attacker was able to gain access to the network through a phishing attack. The victim clicked on a link that generated a connection to an external site, which resulted in the download of the payload.

2. Network activity – In the second phase, the attacker progressed laterally in the network for two weeks. During this time, it collected admin passwords and used in-memory fileless malware. Then on New Year’s Eve, it performed the encryption. This date was chosen since it was (rightfully) assumed the security team would be off on vacation.

3. Exfiltration – Finally, the attackers uploaded the data out of the network.

In addition to these three main steps, additional sub-techniques were employed during the attack and the victim’s point security solutions were not able to block this attack.

Cybersecurity Breaches

“A multiple choke point approach, one that looks horizontally (so to speak) at the attack rather than as a set of vertical, disjointed issues, is the way to enhance detection, mitigation and prevention of such threats. Opposed to popular belief, the attacker needs to be right many times and the defenders only need to be right just once. The underlying technologies to implement a multiple choke point approach are full network visibility via a cloud-native backbone, and a single pass security stack that’s based on ZTNA.” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

How Do Security Point Solutions Stack Up?#

It is common for security professionals to succumb to the “single point of failure fallacy”. However, cyber-attacks are sophisticated events that rarely involve just one tactic or technique which is the cause of the breach. Therefore, an all-encompassing outlook is required to successfully mitigate cyber-attacks. Security point solutions are a solution for single points of failure. These tools can identify risks, but they will not connect the dots, which could and has led to a breach.

Here’s Watch Out for in the Coming Months#

According to ongoing security research conducted by Cato Networks Security Team, they have identified two additional vulnerabilities and exploit attempts that they recommend including in your upcoming security plans:

1. Log4j#

While Log4j made its debut as early as December of 2021, the noise its making hasn’t died down. Log4j is still being used by attackers to exploit systems, as not all organizations have been able to patch their Log4j vulnerabilities or detect Log4j attacks, in what is known as “virtual patching”. They recommend prioritizing Log4j mitigation.

2. Misconfigured Firewalls and VPNs#

Security solutions like firewalls and VPNs have become access points for attackers. Patching them has become increasingly difficult, especially in the era of architecture cloudification and remote work. It is recommended to pay close attention to these components as they are increasingly vulnerable.

How to Minimize Your Attack Surface and Gain Visibility into the Network#

To reduce the attack surface, security professionals need visibility into their networks. Visibility relies on three pillars:

  • Actionable information – that can be used to mitigate attacks
  • Reliable information – that minimizes the number of false positives
  • Timely information – to ensure mitigation happens before the attack has an impact

Once an organization has complete visibility to the activity on their network they can contextualize the data, decide whether the activity witnessed should be allowed, denied, monitored, restricted (or any other action) and then have the ability to enforce this decision. All these elements must be applied to every entity, be it a user, device, cloud app etc. All the time everywhere. That is what SASE is all about.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :

VMware Security Solutions Advisories VMSA-2021-0002

Advisory ID: VMSA-2021-0002
CVSSv3 Range: 5.3-9.8
Issue Date: 2021-02-23
Updated On: 2021-02-23 (Initial Advisory)
CVE(s): CVE-2021-21972, CVE-2021-21973, CVE-2021-21974
Synopsis: VMware ESXi and vCenter Server updates address multiple security vulnerabilities (CVE-2021-21972, CVE-2021-21973, CVE-2021-21974)

1. Impacted Products
  • VMware ESXi
  • VMware vCenter Server (vCenter Server)
  • VMware Cloud Foundation (Cloud Foundation)
2. Introduction

Multiple vulnerabilities in VMware ESXi and vSphere Client (HTML5) were privately reported to VMware. Updates are available to remediate these vulnerabilities in affected VMware products.

3a. VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client (CVE-2021-21972)


The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

Known Attack Vectors

A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. 


To remediate CVE-2021-21972 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.


Workarounds for CVE-2021-21972 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation



The affected vCenter Server plugin for vROPs is available in all default installations. vROPs does not need be present to have this endpoint available. Follow the workarounds KB to disable it.


VMware would like to thank Mikhail Klyuchnikov of Positive Technologies for reporting this issue to us.

Response Matrix:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
vCenter Server7.0AnyCVE-2021-219729.8Critical 7.0 U1cKB82374None
vCenter Server6.7AnyCVE-2021-219729.8Critical 6.7 U3lKB82374None
vCenter Server6.5AnyCVE-2021-219729.8Critical 6.5 U3nKB82374None

Impacted Product Suites that Deploy Response Matrix 3a Components:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
Cloud Foundation (vCenter Server)4.xAnyCVE-2021-219729.8Critical 4.2KB82374None
Cloud Foundation (vCenter Server)3.xAnyCVE-2021-219729.8Critical
3b. ESXi OpenSLP heap-overflow vulnerability (CVE-2021-21974)


OpenSLP as used in ESXi has a heap-overflow vulnerability. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 8.8.

Known Attack Vectors

A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.


To remediate CVE-2021-21974 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.


Workarounds for CVE-2021-21974 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation



[1] Per the Security Configuration Guides for VMware vSphere, VMware now recommends disabling the OpenSLP service in ESXi if it is not used. For more information, see our blog posting:

[2] KB82705 documents steps to consume ESXi hot patch asynchronously on top of latest VMware Cloud Foundation (VCF) supported ESXi build. 


VMware would like to thank Lucas Leong (@_wmliang_) of Trend Micro’s Zero Day Initiative for reporting this issue to us.

Response Matrix:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
[1] ESXi7.0AnyCVE-2021-219748.8Important ESXi70U1c-17325551KB76372None
[1] ESXi6.7AnyCVE-2021-219748.8Important ESXi670-202102401-SGKB76372None
[1] ESXi6.5AnyCVE-2021-219748.8Important ESXi650-202102101-SGKB76372None

Impacted Product Suites that Deploy Response Matrix 3b Components:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
[1] Cloud Foundation (ESXi)4.xAnyCVE-2021-219748.8Important 4.2KB76372None
[1] Cloud Foundation (ESXi)3.xAnyCVE-2021-219748.8Important [2] KB82705KB76372None
3c. VMware vCenter Server updates address SSRF vulnerability in the vSphere Client (CVE-2021-21973)


The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.3.

Known Attack Vectors

A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure.


To remediate CVE-2021-21973 apply the updates listed in the ‘Fixed Version’ column of the ‘Response Matrix’ below to affected deployments.


Workarounds for CVE-2021-21973 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Additional Documentation



The affected vCenter Server plugin for vROPs is available in all default installations. vROPs does not need be present to have this endpoint available. Follow the workarounds KB to disable it.


VMware would like to thank Mikhail Klyuchnikov of Positive Technologies for reporting this issue to us.

Response Matrix:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
vCenter Server7.0AnyCVE-2021-219735.3Moderate 7.0 U1cKB82374None
vCenter Server6.7AnyCVE-2021-219735.3Moderate 6.7 U3lKB82374None
vCenter Server6.5AnyCVE-2021-219735.3Moderate 6.5 U3nKB82374None

Impacted Product Suites that Deploy Response Matrix 3c Components:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
Cloud Foundation (vCenter Server)4.xAnyCVE-2021-219735.3Moderate 4.2KB82374None
Cloud Foundation (vCenter Server)3.xAnyCVE-2021-219735.3Moderate
4. References

VMware ESXi 7.0 ESXi70U1c-17325551

VMware ESXi 6.7 ESXi670-202102401-SG

VMware ESXi 6.5 ESXi650-202102101-SG

VMware vCloud Foundation 4.2
Downloads and Documentation:

VMware vCloud Foundation
Downloads and Documentation:

vCenter Server 7.0.1 Update 1
Downloads and Documentation:

vCenter Server 6.7 U3l
Downloads and Documentation:

vCenter Server 6.5 U3n
Downloads and Documentation:

Mitre CVE Dictionary Links:

FIRST CVSSv3 Calculator:

5. Change Log

2021-02-23 VMSA-2021-0002
Initial security advisory.

6. Contact

E-mail list for product security notifications and announcements:

This Security Advisory is posted to the following lists: 


PGP key at:

VMware Security Advisories

VMware Security Response Policy

VMware Lifecycle Support Phases

VMware Security & Compliance Blog


Source :

The Definitive Browser Security Checklist

Security stakeholders have come to realize that the prominent role the browser has in the modern corporate environment requires a re-evaluation of how it is managed and protected. While not long-ago web-borne risks were still addressed by a patchwork of endpoint, network, and cloud solutions, it is now clear that the partial protection these solutions provided is no longer sufficient. Therefore, more and more security teams are now turning to the emerging category of purpose-built Browser Security Platform as the answer to the browser’s security challenges.

However, as this security solution category is still relatively new, there is not yet an established set of browser security best practices, nor common evaluation criteria. LayerX, the User-First Browser Security Platform, is addressing security teams’ need with the downable Browser Security Checklistthat guides its readers through the essentials of choosing the best solution and provides them with an actionable checklist to use during the evaluation process.

The Browser is The Most Important Work Interface and the Most Targeted Attack Surface #

The browser has become the core workspace in the modern enterprise. On top of being the gateway to sanctioned SaaS apps and other non-corporate web destinations, the browser is the intersection point between cloud\web environments and physical or virtual endpoints. This makes the browser both a target for multiple types of attacks, as well as a potential source of unintentional data leakage.

Some of these attacks have been around for more than a decade, exploitation of browser vulnerabilities or drive-by download of malicious files, for example. Others have gained recent momentum alongside the steep rise in SaaS adoption, like social engineering users with phishing webpages. Yet others leverage the evolution in web page technology to launch sophisticated and hard-to-detect modifications and abuse of browser features to capture and exfiltrate sensitive data.

Browser Security 101 – What is It That We Need to Protect?#

Browser security can be divided into two different groups: preventing unintended data exposure and protection against various types of malicious activity.

From the data protection aspect, such a platform enforces policies that ensure sensitive corporate data is not shared or downloaded in an insecure manner from sanctioned apps, nor uploaded from managed devices to non-corporate web destinations.

From the threat protection aspect, such a platform detects and prevents three types of attacks:

  • Attacks that target the browser itself, with the purpose of compromising the host device or the data that resides within the browser application itself, such as cookies, passwords, and others.
  • Attacks that utilize the browser via compromised credentials to access corporate data that resides in both sanctioned and unsanctioned SaaS applications.
  • Attacks that leverage the modern web page as an attack vector to target user’s passwords, via a wide range of phishing methods or through malicious modification of browser features.

How to Choose the Right Solution#

What should you focus on when choosing the browser security solution for your environment? What are the practical implications of the differences between the various offerings? How should deployment methods, the solution’s architecture, or user privacy be weighed in the overall consideration? How should threats and risks be prioritized?

As we’ve said before – unlike with other security solutions, you can’t just ping one of your peers and ask what he or she is doing. Browser security is new, and the wisdom of the crowd is yet to be formed. In fact, there’s an excellent chance that your peers are now struggling with the very same questions you are.

The Definitive Browser Security Platform Checklist – What it is and How to Use It#

The checklist (download it here) breaks down the high-level ‘browser security’ headline to small and digestible chunks of the concrete needs that need to be solved. These are brought to the reader in five pillars – deployment, user experience, security functionalities and user privacy. For each pillar there is a short description of its browser context and a more detailed explanation of its capabilities.

The most significant pillar, in terms of scope, is of course, the security functionalities one, which is divided into five sub-sections. Since, in most cases, this pillar would be the initial driver to pursuing browser security platform in the first place it’s worth going over them in more detail:

Browser Security Deep Dive#

The need for browser security platform typically arises from one of the following:

— Attack Surface Management: Proactive reduction of the browser’s exposure to various types of threats, eliminating adversaries’ ability to carry them out.

— Zero Trust Access: Hardening the authentication requirements to ensure that the username and password were indeed provided by the legitimate user and were not compromised.

— SaaS Monitoring and Protection: 360° visibility into all users’ activity and data usage within sanctioned and unsanctioned apps, as well as other non-corporate web destinations, while safeguarding corporate data from compromise or loss.

— Protection Against Malicious Web Pages: Real-time detection and prevention of all the malicious tactics adversaries embed in the modern web page, including credential phishing, downloading of malicious files and data theft.

— Secure 3rd Party Access and BYOD: Enablement of secure access to corporate web resources from unmanaged devices of both the internal workforce as well as external contractors and service providers.

This list enables anyone to easily identify the objective for their browser security platform search and find out the required capabilities for fulfilling it.

The Checklist – A Straightforward Evaluation Shortcut #

The most important and actionable part in the guide is the concluding checklist, which provides, for the first time, a concise summary of all the essential capabilities a browser security platform should provide. This checklist makes the evaluation process easier than ever. All you have to do now is test the solutions you’ve shortlisted against it and see which one scores the highest. Once you have all of them lined up, you can make an informed decision based on the needs of your environment, as you understand them.

Download the checklist here.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :

Is Once-Yearly Pen Testing Enough for Your Organization?

Any organization that handles sensitive data must be diligent in its security efforts, which include regular pen testing. Even a small data breach can result in significant damage to an organization’s reputation and bottom line.

There are two main reasons why regular pen testing is necessary for secure web application development:

  • Security: Web applications are constantly evolving, and new vulnerabilities are being discovered all the time. Pen testing helps identify vulnerabilities that could be exploited by hackers and allows you to fix them before they can do any damage.
  • Compliance: Depending on your industry and the type of data you handle, you may be required to comply with certain security standards (e.g., PCI DSS, NIST, HIPAA). Regular pen testing can help you verify that your web applications meet these standards and avoid penalties for non-compliance.

How Often Should You Pentest?#

Many organizations, big and small, have once a year pen testing cycle. But what’s the best frequency for pen testing? Is once a year enough, or do you need to be more frequent?

The answer depends on several factors, including the type of development cycle you have, the criticality of your web applications, and the industry you’re in.

You may need more frequent pen testing if:

You Have an Agile or Continuous Release Cycle#

Agile development cycles are characterized by short release cycles and rapid iterations. This can make it difficult to keep track of changes made to the codebase and makes it more likely that security vulnerabilities will be introduced.

If you’re only testing once a year, there’s a good chance that vulnerabilities will go undetected for long periods of time. This could leave your organization open to attack.

To mitigate this risk, pen testing cycles should align with the organization’s development cycle. For static web applications, testing every 4-6 months should be sufficient. But for web applications that are updated frequently, you may need to test more often, such as monthly or even weekly.

Your Web Applications Are Business-Critical#

Any system that is essential to your organization’s operations should be given extra attention when it comes to security. This is because a breach of these systems could have a devastating impact on your business. If your organization relies heavily on its web applications to do business, any downtime could result in significant financial losses.

For example, imagine that your organization’s e-commerce site went down for an hour due to a DDoS attack. Not only would you lose out on potential sales, but you would also have to deal with the cost of the attack and the negative publicity.

To avoid this scenario, it’s important to ensure that your web applications are always available and secure.

Non-critical web applications can usually get away with being tested once a year, but business-critical web applications should be tested more frequently to ensure they are not at risk of a major outage or data loss.

Your Web Applications Are Customer-Facing#

If all your web applications are internal, you may be able to get away with pen testing less frequently. However, if your web applications are accessible to the public, you must be extra diligent in your security efforts.

Web applications accessible to external traffic are more likely to be targeted by attackers. This is because there is a greater pool of attack vectors and more potential entry points for an attacker to exploit.

Customer-facing web applications also tend to have more users, which means that any security vulnerabilities will be exploited more quickly. For example, a cross-site scripting (XSS) vulnerability in an external web application with millions of users could be exploited within hours of being discovered.

To protect against these threats, it’s important to pen test customer-facing web applications more frequently than internal ones. Depending on the size and complexity of the application, you may need to pen test every month or even every week.

You Are in a High-Risk Industry#

Certain industries are more likely to be targeted by hackers due to the sensitive nature of their data. Healthcare organizations, for example, are often targeted because of the protected health information (PHI) they hold.

If your organization is in a high-risk industry, you should consider conducting pen testing more frequently to ensure that your systems are secure and meet regulatory compliance. This will help protect your data and reduce the chances of a costly security incident.

You Don’t Have Internal Security Operations or a Pen testing Team#

This might sound counterintuitive, but if you don’t have an internal security team, you may need to conduct pen testing more frequently.

Organizations that don’t have dedicated security staff are more likely to be vulnerable to attacks.

Without an internal security team, you will need to rely on external pen testers to assess your organization’s security posture.

Depending on the size and complexity of your organization, you may need to pen test every month or even every week.

You Are Focused on Mergers or Acquisitions#

During a merger or acquisition, there is often a lot of confusion and chaos. This can make it difficult to keep track of all the systems and data that need to be secured. As a result, it’s important to conduct pen testing more frequently during these times to ensure that all systems are secure.

M&A also means that you are adding new web applications to your organization’s infrastructure. These new applications may have unknown security vulnerabilities that could put your entire organization at risk.

In 2016, Marriott acquired Starwood without being aware that hackers had exploited a flaw in Starwood’s reservation system two years earlier. Over 500 million customer records were compromised. This placed Marriott in hot water with the British watchdog ICO, resulting in 18.4 million pounds in fines in the UK. According to Bloomberg, there is more trouble ahead, as the hotel giant could “face up to $1 billion in regulatory fines and litigation costs.”

To protect against these threats, it’s important to conduct pen testing before and after an acquisition. This will help you identify potential security issues so they can be fixed before the transition is complete.

The Importance of Continuous Pen Testing#

While periodic pen testing is important, it is no longer enough in today’s world. As businesses rely more on their web applications, continuous pen testing becomes increasingly important.

There are two main types of pen testing: time-boxed and continuous.

Traditional pen testing is done on a set schedule, such as once a year. This type of pen testing is no longer enough in today’s world, as businesses rely more on their web applications.

Continuous pen testing is the process of continuously scanning your systems for vulnerabilities. This allows you to identify and fix vulnerabilities before they can be exploited by attackers. Continuous pen testing allows you to find and fix security issues as they happen instead of waiting for a periodic assessment.

Continuous pen testing is especially important for organizations that have an agile development cycle. Since new code is deployed frequently, there is a greater chance for security vulnerabilities to be introduced.

Pen testing as a service models is where continuous pen testing shine. Outpost24’s PTaaS (Penetration-Testing-as-a-Service) platform enables businesses to conduct continuous pen testing with ease. The Outpost24 platform is always up-to-date with an organization’s latest security threats and vulnerabilities, so you can be confident that your web applications are secure.

  • Manual and automated pen testing: Outpost24’s PTaaS platform combines manual and automated pen testing to give you the best of both worlds. This means you can find and fix vulnerabilities faster while still getting the benefits of expert analysis.
  • Provides comprehensive coverage: Outpost24’s platform covers all OWASP Top 10 vulnerabilities and more. This means that you can be confident that your web applications are secure against the latest threats.
  • Is cost-effective: With Outpost24, you only pay for the services you need. This makes it more affordable to conduct continuous pen testing, even for small businesses.

The Bottom Line#

Regular pen testing is essential for secure web application development. Depending on your organization’s size, industry, and development cycle, you may need to revise your pen testing schedule.

Once-a-year pen testing cycle may be enough for some organizations, but for most, it is not. For business-critical, customer-facing, or high-traffic web applications, you should consider continuous pen testing.

Outpost24’s PTaaS platform makes it easy and cost-effective to conduct continuous pen testing. Contact us today to learn more about our platform and how we can help you secure your web applications.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :

Windows Update Commands – USOClient, Powershell, WUAUCLT

The windows Update CLI commands are useful for troubleshooting Windows Update errors. And they are helpful when you need to automate the windows update tasks. In newer versions of windows, the WUAUCLT command has been deprecated and replaced with the usoclient. In this article we have included the options and syntax for using wuault, usoclient, and powershell to detect and install windows updates


The windows update command utility in windows is: WUAUCLT. This stands for Windows Update Automatic Update Client. This client has been deprecated in windows 10 and server 2016. Howeve,r it is still available through windows 7 and server 2012R2.

Below is a list of arguments you can pass to the WUAUCLT commands and a short explanation of what each argument does.

/DetectNowDetect and download updates that are available (will vary by system settings)
/ReportNowTell the client to report its status back to the WSUS server
/ShowSettingsDialogShow Windows Update settings dialog
/ShowWindowsUpdateShows the windows update dialog box or web page (depending on windows version)
/ResetAuthorizationwhen an update check occurs a cookie is stored that prevents a new update or check for 1 hour. So, you should use this to delete this cookie
/ResetEulasResets the accepted EULA’s
/ShowWUShows the windows update dialog on windows vista and above. Opens Windows update on XP
/SelfUpdateManagedScan for windows updates using WSUS
/SelfUpdateUnmanagedTriggers a windows update scan using the windows update website
/ShowOptionsOpen the windows update settings window
/ShowFeaturedOptInDialogShow Opt-In dialog for featured updates
/DemoUIShow the icons for windows update
/ShowFeaturedUpdatesOpen windows update dialog and shows the featured updates
/UpdateNowInstall updates now

Showing 1 to 17 of 17 entries


See below for some examples of running the wuauclt. All examples should be run from an elevated/administrative command prompt

If all you want to do is detect and install updates right now, you would run:

Wuauclt /dectectnow /updatenow

If it is refusing to install, you can run:

Wuauclt /resetauthorization

If you want to have the client report its status back to the WSUS server, you would run:

Wuauclt /reportnow


Powershell will give you the most flexibility in installing windows updates. The other methods are fine for simply downloading and installing all updates. However, with the powershell cmdlets you can do things like get a list of updates, search for updates with a specific word in them, then only install those updates.

The first step is to download the powershell module here:

If you have Powershell verison 5, you can install the module from the gallery by running:

Install-module PSWindowsUpdate

Before you can run any commands, you need to import the windows update module:

Import-Module PSWindowsUpdate

You might need to install the Microsoft Update service. That can be done with this command:

Add-WUServiceManager -ServiceID 7971f918-a847-4430-9279-4a52d1efe18d

You can get a list of available cmdlets in the PSWindowsUpdate module with the following command:

Get-command -module PSWindowsUpdate

I have also included a list of commands below:

  • Add-WUOfflineSync
  • Add-WUServiceManager
  • Get-WUHistory
  • Get-WUInstall
  • Get-WUInstallerStatus
  • Get-WUList
  • Hide-WUUpdate
  • Invoke-WUInstall
  • Get-WURebootStatus
  • Get-WUServiceManager
  • Get-WUUninstall
  • Remove-WUOfflineSync
  • Remove-WUServiceManager
  • Update-WUModule


The most important cmdlet is Get-WUInstall . This will be apparent in the examples below

Download and install updates from Microsoft Update, then reboot:

Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot

**Note, I usually only reboot if required. For that reason, I don’t like to use the AutoReboot flag.

Check if a reboot is required


List available updates on Microsoft Update

Get-WUInstall –MicrosoftUpdate –ListOnly


The USO client is new to windows 10 and Server 2016. This replaces the wuauclt command in these Operating systems. I would recommend using powershell instead of this client when you are doing automation, since it will work on newer and older clients. However, this client is very simple to use. and is useful for one-off purposes. See the table below for all of the command arguments:
Show 102550100 entriesSearch:

startscanscan for updates
startdownloaddownload updates
startinstallinstall updates
RefreshsettingsRefresh settings if any changes were made
StartInteractiveScanOpen a dialog and start scanning for updates
RestartDeviceRestart computer to finish installing updates
ScanInstallWaitScan, Download, and install updates
ResumeUpdateResume installing updates on next boot

Showing 1 to 7 of 7 entries



See below for some examples of how to use the USO client. All of these examples should be run in an administrative command prompt

Scan for updates

usoclient startscan

Download updates

Usoclient startdownload

Install updates

usoclient startinstall

Here are other related links

In case you would like to see some additional information, I hae included some links to good resources on these topics:

WSUS Server Cmdlets

Powershell Execution Policy:

Troubleshoot computers not in WSUS:

Client Side Powershell Module:

Powershell FAQ

Source :

Guide: How to Install Active Directory in Windows Server 2019 Using PowerShell

In a previous article, I showed you how to install Active Directory (AD), the first domain controller (DC) in a new forest and domain, using Server Manager in Windows Server 2019. But if you’re not afraid of the command line, there’s a much quicker way to get Active Directory up and running in Windows Server. In this article, I’ll show you how to configure AD using PowerShell.

There are two steps to installing AD in Windows Server 2019. The first is to install the Active Directory Domain Services (AD DS) server role. The second step is to configure your server as a domain controller. An AD domain must have at least one DC. Your server will be the first DC in a new AD forest and domain.

To complete the instructions below, you will need to have an account with administrator privileges in Windows Server 2019. I will also assume that you are using Windows Server 2019 with the Desktop Experience role installed. If you are using Server Core, the instructions vary a little but are more or less the same.

Active Directory prerequisites

Before you install your first domain controller in the new AD domain, there are a couple of things you should do to prepare the server. While it’s not absolutely necessary, I recommend giving the computer a name that makes it easy to identify. For example, I usually call the first domain controller in a new domain DC1. Secondly, you’ll need to set a static IP address and configure the network adapter’s DNS server.

Let’s start by renaming the server.

  • Log in to Windows Server 2019 as an administrator.
  • Open the Start menu and click the Windows PowerShell
  • In the PowerShell window, run the command below and press ENTER. Replace ‘DC1’ with the name that you would like to use for your domain controller.
Rename-Computer -NewName DC1
  • Restart the server.

Once the server has rebooted, we can configure the network adapter. Your DC will need to communicate with other devices on the local network, so it’s important to speak to whoever oversees your network and get them to provide you with a static IP address that isn’t already in use. On my network, I will assign a static IP address of and the default gateway is

  • Log in to Windows Server 2019 as an administrator.
  • Open the Start menu and click the Windows PowerShell
  • In the PowerShell window, run the New-NetIPAddress command below and press ENTER. Replace the values for IPAddress, DefaultGateway, and PrefixLength to those provided by your network administrator.
New-NetIPAddress –IPAddress -DefaultGateway -PrefixLength 24 -InterfaceIndex (Get-NetAdapter).InterfaceIndex

The above command is designed to work on servers that have only one network adapter installed. If you have more than one adapter, you’ll need to enter the interface number instead of (Get-NetAdapter).InterfaceIndex. You can get the interface index number (ifIndex) for each adapter using Get-NetAdapter.

  • Now configure the adapter’s DNS settings. We’ll set the preferred DNS server to be our domain controller’s IP address because the domain controller will also perform the function of DNS server for the domain. So, replace with the same IP address you configured for the adapter. Run Set-DNSClientServerAddress as shown, and press ENTER.
Set-DNSClientServerAddress –InterfaceIndex (Get-NetAdapter).InterfaceIndex –ServerAddresses

Again, the command is designed to work on servers that have only one network adapter installed. If you have more than one adapter, you’ll need to enter the interface number instead of (Get-NetAdapter).InterfaceIndex.

How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

Install the Active Directory Domain Services role

The next step is to install the AD DS server role. It’s easy to do using the Install-WindowsFeature cmdlet as shown below. If you are using Server Core, remove the -IncludeManagementTools parameter.

Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools
How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

Once the AD DS server role is installed, you’ll get a message in the PowerShell window. The Success column should read True.

How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

Configure the first domain controller in a new Active Directory forest

Before you continue, you should decide on a Fully Qualified Domain Name (FQDN) for your new domain. I’m going to use in this example. Where ‘ad’ is the name of my new domain and is the top-level domain (TLD). You should make sure that you own the public TLD. In this example, I should own the domain name. AD in the FQDN defines my internal DNS namespace for Active Directory.

To configure Windows Server 2019 as a domain controller, run Install-ADDSForest as shown in the example below. Replace with your chosen FQDN. DomainNetBIOSName is usually set to the part of your FQDN that identifies your internal AD DNS namespace. So, the part that comes to the left of the first period. In this case, ‘ad’.

Install-ADDSForest -DomainName -DomainNetBIOSName AD -InstallDNS

You should note that Install-ADDSForest is only used when you are installing the first domain controller in a new AD forest. Install-ADDSDomain and Install-ADDSDomainController are used respectively to create a new domain in an existing forest and install a new DC in an existing AD domain.

DomainName and DomainNetBIOSName are the only two compulsory parameters for the Install-ADDSForest cmdlet. If you want to explore what other options you can configure, run the command line below:

Get-Help Install-ADDSForest

When you run the Install-ADDSForest cmdlet, you’ll be prompted to enter a password for Directory Services Restore Mode (DSRM). Or Safe Mode password as it’s sometimes referred to. Enter a password and confirm it when prompted.

You’ll then see a message:

The target server will be configured as a domain controller and restarted when this operation is complete.

Do you want to continue with this operation?

Type y in the PowerShell window and press ENTER to confirm that you want to configure the server as a domain controller.

How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

As AD is configured, you’ll see some yellow warnings appear in the PowerShell window. They are normal and you can safely ignore them. The server will automatically reboot. Once Windows Server has rebooted, you will need to log in with the domain administrator account. The domain administrator account is assigned the same password as the built-in administrator account.

On the sign-in page, type administrator in the User name field. Type the password for the administrator account, which is the same as the password for the previous built-in administrator account, and press ENTER.

How to Install Active Directory in Windows Server 2019 Using PowerShell (Image Credit: Russell Smith)

And that is it! You are now logged in to your AD domain’s first domain controller. You can access Server Manager from the Start menu. In Server Manager, click the Tools menu and then select Active Directory Users and Computers to start managing your domain.

Source :

Active Directory: harden the security of your environment

In this tutorial dedicated to Active Directory and security, I will give you some tips to harden the level of security in order to be less vulnerable to attacks.

The different configuration points, which will be discussed, simply allow attacks to be made more difficult and longer internally, in no way will they guarantee that you are invulnerable.

What you need to know is that your first ally is time, the more “difficult” and longer it will be, the more likely you are that the attacker(s) will move on.

Before applying the settings, they should be tested in a restricted environment so as not to create more problems, especially on Active Directory environments that are several years old.

  1. Disable SMBv1 support
  2. Enable signing on the SMB protocol
  3. Disable LM and NTLMv1 authentication
  4. Disable LLMNR and NBT-NS
  5. Some additional tracks

Disable SMBv1 support

One of the first points is to disable support for the SMBv1 protocol on all computers (servers and client workstations).

Since Windows 10 and Windows Server 2019, SMBv1 support is disabled by default.

To find out if the SMBv1 protocol is enabled, use the following command:

Get-SmbServerConfiguration | Select EnableSMB1Protocol
SMBv1 Enable

Before disabling SMBv1, it is possible to check if it is still used on a server.

To do this, use the command below:

Get-SmbSession | Select-Object -Property ClientComputerName, ClientUserName, Dialect

This command returns the device IP address, username, and SMB version used to access the shares.

If you have “old” equipment (copiers, scanners …), it is possible that they do not support a higher version of SMB.

It is also possible to enable SMBv1 access auditing:

Set-SmbServerConfiguration -AuditSmb1Access $true

Once activated, you must search for events with ID 3000 in the log: Microsoft-Windows-SMBServer\Audit.

To disable the SMBv1 protocol, there are several solutions.

Disable the SMBv1 protocol, this solution is effective immediately and does not require a restart (Windows 8.1 / Server 2012R2 or newer):

Set-SmbServerConfiguration -EnableSMB1Protocol $false

To disable the SMBv1 protocol on later versions of Windows (7, Vista, Server 2008 and Server 2008R2), modify the registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 -Force

To take an account a restart is necessary.

For Windows 8.1 / Server 2012R2, it is also possible to uninstall the SMBv1 protocol support, here a restart is necessary:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

I also wrote a tutorial on disabling SMBv1 protocol (Server/Client) by group policy:

Enable signing on the SMB protocol

In order to “protect” against Man-in-the-middle (MITM) attacks, it is possible to activate the signature on SMB protocol exchanges.

SMB signing works with SMBv2 and SMBv3.

The configuration of the signature can be done:

  • at the client level
  • at the server level

From the moment one of the two negotiates the signature, the SMB flow will be signed.

The configuration is done at the level of group policies: Computer configuration / Windows settings / Security settings / Security options. The two parameters to activate:

  • Microsoft network client: digitally sign communications (always)
  • Microsoft network server: digitally sign communications (always)

Again, I advise you to test on a few computers before applying this to your entire fleet, for my part, I had problems with RDS servers in terms of access to shares.

For more information I invite you to read this page :

Disable LM and NTLMv1 authentication

Still in the “old” protocols, it is necessary to disable the LM and NTLMv1 protocols which have password hashes that are very easy to brute force.

Once again, deactivation can be done by group policy at: Computer Configuration / Windows Settings / Security Settings / Security Options

You need to configure the parameter: Network Security: LAN Manager Authentication Level.

To do this, check Define this policy parameter and select: Send NTLM version 2 responses only\Refuse LM and NTLM

This setting is in an ideal world, if NTLMv1 should still be used, use this setting to disable LM: Only send NTLMv2 responses\Refuse LM

If you must use this parameter, NTLMv1 HASHes can still circulate on the network and are vulnerable to brute force attacks faster than NTLMv2.

It is possible to audit NTLM traffic by enabling settings to identify where NTMLv1 is being used

  • Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
  • Network Security: Restrict NTLM: NTLM authentication in this domain

The NTLM configuration allows quite a bit of flexibility in terms of configuring it and adding exceptions.

Disable LLMNR and NBT-NS

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (Netbios Name Service) are two broadcast/multicast name resolution “protocols” that are enabled by default, they are used when dns name resolution fails.

If you use Wireshark type software to listen to the network, you will see that there is a lot of LLMNR and NBT-NS traffic.

The main danger of LLMNR and NBT-NS is that it is easy to send a false response with another computer in order to retrieve an NTLM hash of the requesting client.

Below are screenshots of the responder which allows you to respond to LLMNR and NBT-NS requests


Now we will see how to deactivate LLMNR and NBT-NS

Disable LLMNR

Good news, LLMNR is disabled by group policy in configuring the DNS client of computers.

To disable LLMNR, you must enable the Disable multicast name resolution setting located at: Computer Configuration / Administrative Templates / Network / DNS Client.

After applying the GPO on the computers in the domain, they will no longer use LLMNR.

If you have non-domain computers, it will be necessary to do this on them.

Disable NBT-NS

Here it gets a little complicated because NBT-NS is configured at the NIC level and there is no applicable group policy. The good news is that for client computers (mainly workstations), it is possible to do this by an option on the DHCP server.

At the options level (extended or server), option 001 Microsoft Options for disabling NetBios must be configured in the Microsoft Windows 2000 Option vendor class. The value 0x2 must be entered to disable NBT-NS.

For computers that are not in automatic addressing, Netbios must be disabled on the network card(s).

Open network card properties.

Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.

From the General tab, click on Advanced.

Go to the WINS tab, and select Disable NetBIOS over TCP/IP.

Close the different ones by validating the configuration.

It is possible to disable Netbios by GPO using a PowerShell script run at startup.

Here is the script:

 ps-disable-netbios.ps1 248 Bytes 


# Get network cards
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
# Disable Netbios on each
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Some additional tracks

Here are some additional tips:

  • Deploy LAPS on computers and servers in order to have different local administrator passwords.
  • Sign your DNS zone (DNSSEC)
  • Regularly audit privileged accounts.

It is also important to follow some simple “hygiene” rules:

  • Limit privileged account usage (domain admins)
  • Do not use domain admin accounts on workstations
  • Update servers and computers regularly
  • Update applications (Web server, database, etc.)
  • Make sure you have up-to-date antivirus
  • Learn about security bulletins

Regarding the last point that I will address, it is passwords, for domain administrator accounts, privileged long passwords (20 to 30 characters) which will take much longer to be “brute-forced” than an 8-character password even with complexity.

Don’t forget to audit your Active Directory for free with Ping Castle.CategoriesActive DirectoryTagsActive DirectorySecurity

Source :

Active Directory: Add a Domain Controller to PowerShell

Table Of Contents

  1. Introduction
  2. Prerequisites
  3. Installing the ADDS role in PowerShell
  4. Domain Controller Promotion in PowerShell
  5. Complements


In this tutorial, we will see how to add an Active Directory domain controller to an existing domain using PowerShell.

To do this through the GUI, I invite you to read this article: Add an AD DS Domain Controller to an Existing Domain. (fr)

Adding a domain controller to PowerShell is done in two command lines, which saves time….


On the server that is going to be promoted domain controller, it is necessary:

  • A fixed IP address.
  • Configure an existing domain controller as a DNS server on the network adapter.
  • Make sure the ping of the domain name answers.

Dans le cas d’ajout où vous ajoutez un contrôleur de domaine sur une autre plage IP et que vous en novice, je vous conseille avant la lecture du l’article pour le faire en mode graphique et l’article suivant : Active Directory : configuration multi sites, sous réseau et réplication.

Installing the ADDS role in PowerShell

From a Powershell command prompt launched as administrator enter:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install ADDS role in powershell

Wait during the installation ….

The AD DS role is installed:

Domain Controller Promotion in PowerShell

Always from a Powershell command prompt enter:

Install-ADDSDomainController -DomainName "domain.tld" -InstallDns:$true -Credential (Get-Credential "DOMAIN\administratreur")

Enter the password of the account passed as a parameter in the login window, then in the Powershell console enter the password of the directory recovery mode and confirm the promotion as a domain controller.

Wait during the promotion operation ….

After the operation completes, the following message appears and the server restarts.

At reboot the server is domain control.


There are 3 different Powershell commands that allow promotion as a domain control. Each of the commands is to be used in a particular case:

CategoriesActive DirectoryTagsActive DirectoryDomain

Source :