HOWTO: Enable Windows Hello for Business FIDO2 Key sign-in without Microsoft Intune

eWBM's GoldenGate FIDO2 Key

The official Microsoft documentation teaches us that Microsoft Intune is an optional requirement to configure Windows Hello for Business to show the option to display the FIDO security key sign-in method as part of the Sign-in options on the Windows Logon Screen.

However, a method to achieve the same goal without Microsoft Intune is not part of the documentation…

 

Getting ready

To make FIDO Key sign-in work, you’ll need to meet the following requirements:

  • You need a compatible FIDO2 security key.
    I choose the above eWBM GoldenGate FIDO2 security key of South Korean origin.
  • The device you’re configuring must run Windows 10 1809, or a newer version of Windows 10.
  • The device you’re configuring needs to be Azure AD-joined.
    This is an Azure AD Free feature.
  • You need local administrator or System privileges on the device.
    This can be easily achieved by assigning the Device administrator role to a person, but requires Azure AD Premium licenses. This can also be achieved using Microsoft Intune, but the entire purpose is to make this work without Microsoft Intune…
  • You need Global administrator privileges in the Azure AD tenant that the device is joined to.
  • The Azure AD tenant the device is joined to must be configured to use the combined security information registration.

 

How to do it

Enabling FIDO2 Security Keys as a sign-in method for Windows Hello for Business requires four steps:

  1. Enabling FIDO2 as an authentication method in Azure AD
  2. Configuring a security key for sign-in for the user account
  3. Configuring the Windows 10 device with the right policy setting (without Intune)
  4. Signing in in with the FIDO2 security key

 

Enabling FIDO2 as an authentication method in Azure AD

Perform these steps to enable FIDO2 security keys as a valid authentication method in Azure Active Directory:

  • Sign in to the Microsoft Azure portal.
  • Open the navigation menu, if it’s not open by default.
  • In the navigation menu, click on Azure Active Directory.
  • In the Azure Active Directory navigation menu, click on Security.
  • In the Security navigation menu, click on Authentication methods.
  • In the Authentication Methods navigation menu, click on Authentication method policy (Preview).
  • In the main pane, click on the FIDO2 Security Key method.
  • In the blade that emerges from the bottom of the Azure portal, enable the ability for people in the Azure AD tenant to use this authentication method by switching from No to Yes in the Enabled field.
  • Make a decision between targeting All users or only selected users in the Target field.
  • Save the configuration by clicking the Save button in the top bar of the blade.

 

Configuring a security key for sign-in for the user account

Perform these steps to configure an actual security key for sign-in for the user account that will use the key as the sign-in method. This can be the same account as used in the previous steps, but the best way to show off the feature is with an account that has no privileges in the Azure AD tenant:

  • Browse to the Microsoft MyProfile portal.
  • Sign in if not already.
  • Click the UPDATE INFO link on the Security Info tile.
  • Perform multi-factor authentication.
  • Register a FIDO2 security key as an additional Azure Multi-Factor Authentication method by clicking Add method
  • Choose Security key from the drop-down list.
  • Choose USB device or NFC device.
  • Click Next.
  • Create or enter a PIN for the security key.
  • Perform the required gesture for the key, either biometric or touch.
  • Returning to the combined registration experience, provide a meaningful name for the security key to easily identify it.
  • Click Next.
  • Click Done.
  • Close the browser.

 

Configuring the Windows 10 device with the right policy setting

Perform these steps to configure the Windows 10 device:

  • Sign in to the device with an account that has local administrator privileges.
  • Open the Registry Editor (regedit.exe)
  • Navigate to the following registry location:HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey

Note:
If the PassportForWork and SecurityKey registry keys don’t exist, create them.

  • Create a new DWORD (32-bit) value, named UseSecurityKeyForSignIn.
  • Provide 1 as the data for the new value.

The UseSecurityKeyForSignIn Registry value

  • Close the Registry Editor.
  • Restart the device.

 

Signing in with the FIDO2 security key

  1. On the Windows login screen, click the Sign-in options text.
  2. Select the FIDO security key option.
  3. Insert the pre-configured security key.
  4. Enter the PIN and/or
    perform the required gesture for the key, either biometric or touch.

 

Concluding

The above steps show how to configure Windows Hello for Business to show the option to display the FIDO security key sign-in method as part of the Sign-in options on the Windows Logon Screen without using Microsoft Intune.

Further reading

Windows Hello for Business Overview
Enable passwordless security key sign in (preview)
Passwordless authentication options

Posted on January 22, 2020 by Sander Berkouwer in Azure Active Directory, Multi-Factor Authentication, Security, Setup and Deployment

0  

Citrix’ NetScaler patch may break the Azure MFA NPS Extension for people who use text messages as their method

Vulnerable

The Internet has been on fire for the last week, as a vulnerability in Citrix appliances was actively attacked. In the Netherlands, the National Cyber Security Center advised organizations to switch off Citrix networking appliances. Dutch 

Now that organizations are switching them back on to patch the affected systems, they may be in for another surprise when they use these devices in combination with Microsoft’s Azure MFA NPS Extension: People using text messages as multi-factor authentication method are still locked out.

 

About the vulnerability in Citrix appliances

Citrix ADC appliances and Citrix Gateway servers, formerly known as Citrix NetScaler appliances, and Citrix SD-WAN WANOP appliances are vulnerable to a remote code execution bug that might provide access to sensitive data and system data.

An attacker can exploit this vulnerability, known as CVE-2019-19781, to gain root access to these devices. An attack does not require access to (leaked) credentials. Any attacker can exploit this vulnerability with the exploit code snippets available on the Internet.

On Sunday January 19th, 2020, Citrix has provided an update to patch Citrix appliances running versions 11.1 and 12. Patches for versions 10.5, 12.1 and 13 are expected before the end of January 2020.

 

About the Azure MFA NPS Extension

Microsoft’s Azure MFA service allows for multi-factor authentication as a requirement for access to Azure AD-integrated applications, systems and services. However, some applications, systems and services cannot be integrated.

For these systems, if they support RADIUS, they can be connected to a Network Policy Server (NPS) running on Windows Server.

The Network Policy Server (NPS) extension for Azure MFA can be used in this scenario to add cloud-based MFA capabilities. With the NPS extension, admins can add phone call, text message, or phone app verification to the existing RADIUS flow.

 

Citrix’ Patch may break RADIUS’ challenge-response flow

What several people and some of our customers are experiencing is that Citrix’ patch, updating the firmware of their appliances to version 11.1.63.15, breaks the RADIUS’ challenge-response flow of traffic. In the logs, people are seeing RADIUS access requests sent to the Network Policy Server containing the username and password. But when the RADIUS server sends back the access challenge, the Citrix appliance stops responding.

The Azure MFA NPS Extension uses this challenge-response flow when people are using text message as their multi-factor authentication method; The person has to type in the One-time Passcode (OTP) that was sent to the mobile device in an additional field.

This method breaks. People using text messages as their multi-factor authentication method still can’t access the back-end infrastructure protected by the Citrix appliance(s). Using OTPs with the Microsoft Authenticator App and third-party authenticator apps (authy, Google Authenticator, etc.) may also be broken, but we haven’t come across people using these methods, yet.

 

How to deal with this situation

There are several ways to deal with this situation:

Uninstalling the Citrix update

Obviously, uninstalling the Citrix update is not an option. The vulnerability that is patched is already actively exploited. Waiting another couple of weeks or months for another update from Citrix to patch this unwanted behavior is also a gloomy prospect.

Creating a new RADIUS profile

The first valid way to handle this situation is by creating a new RADIUS profile. For many organizations, this seems to solve the situation. It’s been a solution known to Citrix admins for the situation when RADIUS suddenly fails after an update.

Switch to non-challenge-response methods

Another way to handle this situation is to help people make the switch from one of the affected multi-factor methods. The Azure MFA NPS extension offers additional methods that people can use for multi-factor authentication that don’t rely on input of an OTP in the Citrix interface:

  • Phone call
  • Microsoft Authenticator (in verification mode)

As long as the method used by people doesn’t use a challenge-response method interacting with the Citrix appliance to input a One-time Passcode, they can successfully perform multi-factor authentication and meet the requirements to access the resources protected by the Citrix appliance(s).

Tip!
To find out the Azure multi-factor authentication methods used by people in your organization, use the information in my blogpost Getting to know the colleagues using Azure Multi-Factor Authentication. This will quickly provide insights on the impact of the above situation.

Tip!
Every multi-factor authentication method has its pros and cons.  Choosing the right Azure MFA authentication method for each affected person, within the scope of available methods within the organization is a delicate art. Find out how to choose the right Azure MFA method.

Switch to modern authentication methods

As detailed above, the Azure MFA NPS extension is intended to provide multi-factor authentication, based on the legacy RADIUS protocol. RADIUS is proven technology, but newer methods are available to provide authentication to (web) applications:

  • Publishing the back-end application, system or service through the Web Application Proxy as part of a Windows Server 2016-based (or newer version) Active Directory Federation Services (AD FS) farm, using the built-in Azure MFA AD FS Adapter.
  • Creating a Relying Party Trust (RPT) for the back-end application, system or service to a Windows Server 2016-based (or newer version) Active Directory Federation Services (AD FS) farm, using the built-in Azure MFA AD FS Adapter.
  • Publishing the back-end application, system or service through the Azure AD Application Proxy, leveraging Azure AD’s Conditional Access feature to require multi-factor authentication.
  • Creating a Relying Party Trust (RPT) for the back-end application, system or service to Azure AD, leveraging Azure AD’s Conditional Access feature to require multi-factor authentication.
  • On Citrix NetScaler devices running version 11.0 or above and equipped with the AAA module, you can switch from RADIUS authentication to a SAML-based Relying Party Trust (RPT) towards AD FS or Azure AD. This switch implies switching all back-end applications, systems and services in terms of authentication and should not require any changes to these applications, systems and services themselves.
  • Citrix NetScaler devices running version 13 or above and equipped with the AAA module, can be used as a full-fledged Web Application Proxy for the AD FS farm and publish back-end applications, systems and services this way. Technical Preview Again, this switch implies switching all back-end applications, systems and services in terms of authentication and should not require any changes to these applications, systems and services themselves.

To remediate the situation, you can migrate the application, system or service over to one (or more) of the newer authentication methods.

 

Concluding

We’re closely watching reports coming in. At this point in time, it seems that:

  • Only Citrix’ patch for version 11.1 seems affected.
  • Only challenge-response multi-factor authentication methods relying on OTPs entered in the NetScaler authentication interface are affected, including text messages, Authenticator app OTPs and hardware tokens.

Posted on January 21, 2020 by Sander Berkouwer in Azure Active Directory, Multi-Factor Authentication

0  

I’m speaking at the 2020 Nordic Infrastructure Conference

NIC 20/20 Vision - February 6th-7th - Oslo Spektrum

After a year’s absence, I’m proud to announce I’m back at the Nordic Infrastructure Conference speaking on Active Directory, Azure Active Directory and Active Directory Federation Services.

  

About the Nordic Infrastructure Conference

The Nordic Infrastructure Conference (NICConf) provides IT and business professionals with unmissable networking and learning experiences from the leading Global IT experts.

NIC is the industry’s foremost collaboration and learning event offering global best in class content and structure, delivered by some of the leading technical IT speakers in the world. The main focus is on Cloud technology, automation & management, security, client & server, collaboration and productivity & analytics.

NICConf will be hosted for the ninth time from February 5 to February 7, 2020. Its location will be the Oslo Spektrum in the heart of Oslo, Norway, again.

The theme for the 2020 Nordic Infrastructure Conference (NICConf) in Oslo is 20/20 Vision.

Are all your IT-systems from just one manufacturer? Like Microsoft? If the answer is no, and it most certainly is, then you need to build competence and knowledge on a wider range of technology. This might span from different cloud providers, through line of business application, open source servers, hardware and peripherals. Where do you go to find a conference that support all that? To one of Microsoft’s or another one-brand-conference?

Of course not! What you need is an independent, open, inviting and including conference like NIC 20/20. A conference that embraces all modern technology, is independent of vendor, who opens the scene and the exhibition floor to all types of companies as long as they bring knowledge and experience at their front and center.

     

About my sessions

I will deliver two 60-minute sessions:

From the trenches: Eight common mistakes with Hybrid Identity

Cloud track, Room 8, Thursday February 6 11:20AM-12:20PM

Do you wish a seasoned expert would tell you all the mistakes to avoid before you begin your Hybrid Identity journey? Or do you need substantial, real-world proven tips for your current setup of Active Directory and Azure AD?

Then this session is for you!

Deep Dive into managing AD FS with Azure AD Connect

Cloud track, Room 8, Friday February 7 2PM-3PM

Wouldn’t it be nice to manage Active Directory Federation Services more effectively? Now you can! Discover how Azure AD Connect can be used to setup, manage and even decommission AD FS.

You know what… I’ll show you all of that in under 60 minutes just to make my point. Winking smile

Join us!

I look forward to the Nordic Infrastructure Conference!

It’s a nice conference with an honest audience. A lot of my friends also present, like Aleksandar Nikolic, Alex de Jong, Andy Malone, John Craddock, Mirko Colemberg, Paula Januszkiewicz, Peter Schmidt, Sami Laiho and Sasha Kranjac (in alphabetic order). Off course, I’ll be sharing a room with Raymond Comvalius again, which is always a joy.

Join us! Buy your tickets here.

Posted on January 20, 2020 by Sander Berkouwer in Community, Microsoft MVP, Personal

0  

HOWTO: Deploy AD FS with SQL Server to gain Artifact Resolution and Replay Detection

This entry is part 23 of 23 in the series Hardening Hybrid Identity

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at the benefits of implementing AD FS with a back-end SQL Server (cluster) as opposed to implementing it with Windows Internal Database (WID):

  • SAML Artifact Resolution
  • Token Replay Detection

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

 

Why deploy AD FS with Microsoft SQL?

There are several reasons to deploy Active Directory Federation Services (AD FS) with a Microsoft SQL Server back-end. The organizations for which I’ve deployed AD FS with SQL Server chose to do so mainly because they have a strategy to centralize their Microsoft SQL databases on a highly-available Microsoft SQL cluster. This way, all the information security measures surrounding that data had to be applied only once.

Other benefits of using a back-end Microsoft SQL Server are:

  • AD FS admins have read/write access to the database on all AD FS servers, eliminating the situation where only the primary AD FS server has read/write access and, thus, can only be used to manage the AD FS farm.
  • AD FS admins are not limited to 30 AD FS servers in their AD FS farm.
  • SQL admins can more easily manage the Microsoft SQL Server, since it is not limited in the same way Windows Internal Database is limited.

However, there are two other reasons as well:

Why would you want SAML Artifact Resolution?

In an AD FS implementation using Windows Internal Database to store and replicate the AD FS configuration, when a SAML authentication is performed, the responding claim is sent back.

With Artifact Resolution, instead of the actual claim, a reference is sent back. Based on the reference, the claim can then be retrieved. When used, Artifact Resolution allows for all parties involved to reference the original SAML claim. All access to the references can then be logged and audited to allow for the permitted access, only.

Artifact Resolution is only available when AD FS is implemented with a back-end Microsoft SQL Cluster.

Why would you want Token Replay Detection?

In an AD FS implementation using Windows Internal Database to store and replicate the AD FS configuration, tokens that are retrieved can be reused to an extent. When Replay detection is enabled, AD FS no longer allows for the WS-Federation passive profile and the SAML WebSSO profile.

 

Getting ready

To change the security headers throughout the AD FS infrastructure, make sure to meet the following requirements:

Information requirements

In the organization, make sure there is consensus on the name for the AD FS farm.
Make sure a TLS certificate is available for the AD FS farm name, or request it from a Certification Authority (CA). Install the certificate in the personal certificate store for the local machine.

SYSTEM REQUIREMENTS for proposed AD FS Servers

To create an AD FS Farm, make sure a domain-joined Windows Server 2016 installation is available to commission as an AD FS server. Additionally, make sure the AD FS farm name is resolvable to this machine in the appropriate DNS zones.

Make sure these systems are installed with the latest cumulative Windows Updates. At a minimum, make sure the proposed AD FS Servers running Windows Server 2016 have the July 2019 Cumulative update (KB4507459) installed

System requirements for SQL Servers

For AD FS with SQL Server-based databases, have a SQL Server available on the network, that is also resolvable via DNS and reachable by the proposed AD FS server(s).

Make sure the Microsoft SQL Server is configured with a TLS certificate to be able to encrypt the data with the AD FS Servers.  Also make sure the Microsoft SQL Server installation supports TLS 1.2 by installing the required hotfixes as described in KB3135244.

PRIVILEGE REQUIREMENTS

Perform all the below steps with an account that has these specific permissions:

  1. Domain Administrator privileges in Active Directory, through a direct membership of the Domain Admins group.
  2. Local Administrator privileges on the Windows Server installations you intend to use as AD FS servers. (This is a default permission that comes with Domain Admins privileges when the server is domain-joined)
  3. SysAdmin (sa) privileges on the Microsoft SQL Server.

 

How to install the first AD FS Server with Microsoft SQL Server

Setting up an AD FS farm with Windows Internal Database and implementing the first AD FS server, consists of the following steps:

  1. Creating a gMSA in Active Directory
  2. Creating the database script
  3. Creating the databases
  4. Installing the AD FS Server role
  5. Configuring AD FS

 

Creating a gMSA

We need a group Managed Service Account (gMSA) to be used as the AD FS service account across the AD FS farm. A gMSA is the safest way to host this account from Active Directory.

When using SQL Server opposed to using WID, however, the serviceaccount becomes really important, because it is not only used to run the AD FS service on AD FS servers in the AD FS Farm, but also to connect to the SQL Server backend: The service account specified when using the script from Export-AdfsDeploymentSQLScript, will be added as a login to the SQL Server installation and will be provided with privileges in the database.

Use the following lines of PowerShell on a system with the Active Directory Module for Windows PowerShell installed, while signed in with a user account that is a member of the Domain Admins group, supposing ADFSServer1 is the hostname of the first AD FS server in the farm:

Import-Module ActiveDirectory

New-ADServiceAccount ADFSgMSA -DNSHostName adfsgmsa.domain.tld -PrincipalsAllowedToRetrieveManagedPassword ADFSServer1

 

Creating the script

On the first proposed AD FS server, install the AD FS Server role with the following line of Windows PowerShell in an elevated window:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

 

With the AD FS Server role installed, we can use the specific Windows PowerShell cmdlet to create the SQL scripts to create the databases on the SQL Server Back-end.

Use the following lines of Windows PowerShell to install the AD FS Server role in an elevated window:

New-Item “C:\ADFSSQLScript” -Type Directory

Export-AdfsDeploymentSQLScript -DestinationFolder “C:\ADFSSQLScript” –ServiceAccountName DOMAIN\ADFSgMSA$

 

This will create two files in the specified folder:

  1. CreateDB.sql
  2. Set-Permissions.sql

Creating the databases

Copy both files to the Microsoft SQL Server you intend to use as the back-end for the AD FS farm. Perform these steps:

  1. Open the SQL Server Management Studio.
  2. From the File menu, click the Open option. Then click File (Ctrl+O).
  3. Browse to the CreateDB.sql script and open it.
  4. From the Query menu, click the Execute (F5) option.
  5. From the File menu, click the Open option. Then click File (Ctrl+O) again.
  6. This time, browse to the SetPermissions.sql script and open it.
  7. From the Query menu, click the Execute (F5) option.

The CreateDB.sql script creates two databases: the AdfsConfigurationV4 database that stores the AD FS Farm settings, and the AdfsArtifactStore database, that is used for AD FS Artifact Resolution.

Note:
Do not configure the database as part of a SQL Server Always-on Availability Group at this moment. Wait with this action, until you’ve successfully configured the first AD FS server, as the AD FS server wants a lock on the database at that time.

Configuring AD FS

On the proposed first AD FS server, perform the following lines of Windows PowerShell  in an elevated window to configure the AD FS Server role with a SQL Server named SQLServer, listening on the default port (TCP 1433):

$ADFSFarmName = “sts.domain.tld”

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match $ADFSFarmName}).Thumbprint

Install-ADFSFarm -CertificateThumbPrint $thumb -FederationServiceDisplayName “Organization Name” -FederationServiceName $ADFSFarmName -GroupServiceAccountIdentifier “DOMAIN\ADFSgMSA$” -OverwriteConfiguration -SQLConnectionString “Data Source=SQLSERVER;IntegratedSecurity=True”

Restart-Computer

 

In some environments, complex SQL connection strings might be returned by a SQL admin as answer to the AD FS SQL scripts. In these cases, it is wise to test the SQL connection string manually on the AD FS Servers, before implementation. Use the following lines of Windows PowerShell to this purpose:

$conn = New-Object System.Data.SqlClient.SqlConnection

$conn.ConnectionString = “Data Source=SQLServerName:Port;Integrated Security=True;”

# If no error occurs here, then connection was successful.

$conn.Open();

$conn.Close();

   

How to install additional AD FS Servers with Microsoft SQL Server

After setting up the AD FS farm by implementing the first AD FS server, adding additional AD FS servers to the farm is straightforward.

Make sure:

  1. The same TLS certificate is available for the additional AD FS servers as used on the first AD FS server in the AD FS farm. Install the certificate in the personal certificate store for the local machine.
  2. The proposed AD FS server is a domain-joined Windows Server installation and you are logged on with a domain account that is a member of the Domain Admins group.
  3. The Microsoft SQL Server is available.

On the proposed AD FS server, install the AD FS Server role with the following line of Windows PowerShell in an elevated window:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Then, in the same PowerShell window, use the following lines of Windows PowerShell, replacing the values for $ADFSFarmName, -GroupServiceAccountIdentifier and -SQLConnectionString in the same way as you did for the first AD FS server:

$ADFSFarmName = “sts.domain.tld”

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match $ADFSFarmName}).Thumbprint

Add-AdfsFarmNode -CertificateThumbPrint $thumb -GroupServiceAccountIdentifier “DOMAIN\ADFSgMSA$” -SQLConnectionString “Data Source=SQLSERVER;IntegratedSecurity=True”

Restart-Computer

 

Checking for Token Replay Detection

Token replay detection is enabled by default when you deploy AD FS with SQL Server. However, after deploying AD FS with SQL Server, you may want to check if Token Replay Detection is enabled. Run the following line of Windows PowerShell in an elevated window to do so:

(Get-ADFSProperties).PreventTokenReplays

 

Concluding

SAML Artifact Resolution and Token Replay Detection should be available for hardened Hybrid Identity implementation. To gain access to these features, install Active Directory Federation Services (AD FS) with Microsoft SQL Server as its back-end.

Further reading

The Role of the AD FS Configuration Database
How does Artifact Resolution work?
AD FS Deployment Topology Considerations

Posted on January 17, 2020 by Sander Berkouwer in Active Directory, Active Directory Federation Services, Azure Active Directory, Security

0  

TODO: Install the January 2020 Cumulative Update in your networking infrastructure

Windows Server

This Tuesday, Microsoft released an update that fixes a critical vulnerability in Windows and Windows Server. I urge you to install this update as soon as possible.

 

About the vulnerability

The vulnerability, labeled CVE-2020-0601 was responsibly disclosed by the NSA to Microsoft. It is dubbed ‘NSACrypt’.

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates.

Any software, including third-party non-Microsoft software, that relies on the Windows CertGetCertificateChain() function to determine if an X.509 certificate can be traced to a trusted root Certification Authority may incorrectly determine the trustworthiness of a certificate chain.

Microsoft Windows versions that support certificates with ECC keys that specify parameters are affected. This includes Windows 10 as well as Windows Server 2016 and 2019.

Note:
Windows 8.1 and prior, as well as the Server 2012 R2 and prior counterparts, do not support ECC keys with parameters. For this reason, such certificates that attempt to exploit this vulnerability are inherently untrusted by older Windows versions.

By exploiting this vulnerability, an attacker may be able to spoof a valid X.509 certificate chain on a vulnerable Windows system. This may allow various actions including, but not limited to, interception and modification of TLS-encrypted communications or spoofing an Authenticode signature. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider.

 

About the update

The following security updates address the vulnerability by ensuring that Windows’ CryptoAPI completely validates Elliptic Curve Cryptography (ECC)certificates:

Windows 10 version 1607 KB4534271
Windows 10 version 1709 KB4534276
Windows 10 version 1803 KB4534293
Windows 10 version 1809 KB4534273
Windows 10 version 1903 KB4528760
Windows Server 2016 KB4534271
Windows Server 2019 KB4534273
Windows Server, version 1803 KB4534293
Windows Server, version 1903 KB4538760
Windows Server, version 1909 KB4538760

A system restart is required after you apply this security update.

After the applicable Windows update is applied, the system will generate Event ID 1 in the Event Viewer after each reboot under Windows Logs/Application when an attempt to exploit a known vulnerability ([CVE-2020-0601] cert validation) is detected

 

NON-SECURITY-RELATED FIXES THAT ARE INCLUDED IN THIS SECURITY UPDATE

This security update also addresses an issue to support new SameSite cookie policies by default for release 80 of Google Chrome.

 

MITIGATING FACTORS

Microsoft has not identified any mitigating factors for this vulnerability.

 

WORKAROUNDS

Microsoft has not identified any workarounds for this vulnerability..

 

Call to action

I urge you to install the necessary security updates on systems in a test environment as soon as possible, assess the risk and possible impact on your production environment and then, roll out this update to systems in the production environment.

From our tests, we concluded that there was no negative impact, but we have updated our systems and our customers’ systems monthly. As this is a cumulative update, all fixes, addressing all vulnerabilities between the last cumulative update, or the release of the Operating System will be applied.

 

FURTHER READING

National Vulnerability Database: CVE-2020-0601

CVE-2020-0601 | Windows CryptoAPI Spoofing Vulnerability
January 2020 Security Updates: CVE-2020-0601
Microsoft Windows CryptoAPI fails to properly validate ECC certificate chains

Posted on January 16, 2020 by Sander Berkouwer in Active Directory, Active Directory Federation Services, Security

2  

HOWTO: Design a networking infrastructure for Hybrid Identity components

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

For many organizations the Active Directory administrative tier model is a reality, or at least something they strive to embrace to increase their information security.

How do the Hybrid Identity systems fit into this model?

About the Active Directory administrative tier model

The Active Directory administrative tier model protects identity systems using a set of buffer zones between full control of the environment (Tier 0) and the high risk workstation assets that attackers frequently compromise. The administrative tier model is composed of three levels and only includes administrative accounts, not standard user accounts. The Tier model prevents escalation of privilege by restricting what administrators can control and where they can log on (because logging on to a computer grants control of those credentials and all assets managed by those credentials).

In the model, Active Directory Domain Controllers are placed in Tier 0.

As Tier 0 is the only tier intended to allow direct control of enterprise identities in the environment, Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it.

 

Creating a Tier Strategy for Hybrid Identity components

Designing a tier strategy for Hybrid Identity components consists of four separate tasks:

  1. Designing AD FS Server placement
  2. Designing Web Application Proxy placement
  3. Designing Azure AD Connect Server placement
  4. Designing Azure AD Password Protection placement

    

Designing AD FS Server placement

AD FS Servers should be placed in Tier 0.
Communications between AD FS servers and between AD FS servers and Domain Controllers should be isolated in Tier 0, too. This traffic should not be permitted to cross less-secure networking zones. 

In the RFCs, AD FS servers are referred to as Security Token Service (STS) servers. Functionally, they translate Kerberos tokens to claim tokens. Claim tokens are the equivalent of Kerberos tokens for their respective open protocols, like WS-Federation, SAML, OAuth2, Open ID Connect and SCIM.

The way an attacker may use claim tokens is to forge a claim token for an administrative user account and then reset its password using Azure AD Self-Service Password Reset.

When Microsoft SQL Server is used as the back-end for AD FS, the SQL server(s) hosting the database should also be placed in Tier 0. This might mean that the SQL Server (cluster) hosting the ADFSConfigurationVx and ADFSArtifactStore databases should be a separate SQL Server (cluster) than the one(s) hosting other non-Tier0 databases.

Designing Web Application Proxy placement

Web Application Proxies should be placed on the extranet.
They should not be joined to an Active Directory domain.

For their communications to AD FS servers, Web Application Proxies only use TCP443 (https), leveraging MS-ADFSPIP with short-lived certificates that are signed and distributed by the AD FS farm. However, this communications flow into Tier 0 cannot be intercepted or inspected, as it would break MS-ADFSPIP. Instead, intercept and inspect at the edge of the network.

Designing Azure AD Connect Server placement

Azure AD Connect servers should be placed in Tier 0.

Azure AD Connect uses an ADSync database per Azure AD Connect installation. This database contains information on all objects in scope for Azure AD Connect. It also contains information on its service accounts, used to write objects in Azure AD and to perform write-back operations into Active Directory.

An attacker can use the information in the ADSync database to create and alter objects in both Azure AD and Active Directory.

As Tier 0 dictates no Internet access, Azure AD Connect should be configured to use  proxy servers to transit from Tier 0 into Tier 1 and, ideally, from Tier 1 to the Internet.

Designing Azure AD Password Protection placement

Azure AD Password Protection can be used to prevent weak passwords. It offers a hybrid model, where password changes are intercepted using a password filter driver on each Domain Controller and a proxy component to update the password filter driver.

The Azure AD Password Protection agent component is installed on each Domain Controller and therefore resides in Tier 0.

The Azure AD Password Protection proxy component should be placed in Tier 1. This component was designed to do so, as Microsoft specifically signs and encrypts each update that goes to the Domain Controllers.

    

Designing a networking infrastructure for Hybrid Identity components

Designing a networking infrastructure for Hybrid Identity components consists of four separate tasks:

  1. Designing AD FS Server networking
  2. Designing Web Application Proxy networking
  3. Designing Azure AD Connect Server networking

  

Designing AD FS Server networking

AD FS Servers should be placed as close as possible to Domain Controllers from a networking perspective. This prevents time-outs that may result in authentication failures for end-users.

AD FS servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As AD FS servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.

AD FS servers need to exchange federation metadata with federation partners, when the relying party trust (RPT) to these partners is configured through a Federation Metadata URL. AD FS servers also need to perform certificate revocation checks for the certificates of federation partners. The above traffic can be allowed through a proxy.

Designing Web Application Proxy networking

Web Application Proxies can be integrated with the networking infrastructure in two ways:

  1. Web Application Proxies can be placed on a perimeter network.
  2. Web Application Proxies can be domain-joined.

In the first scenario, the Web Application Proxy acts as an AD FS Proxy to publish the AD FS servers in the AD FS farm to the Internet. Publishing AD FS to the Internet is a requirement for federating with Azure AD and Office 365. In this scenario, the Web Application Proxy is capable of publishing application with pass-through authentication.

In the second scenario, the Web Application Proxy acts as both an AD FS Proxy and an App-publishing proxy. However, the web applications in this scenario need to be published requiring AD FS authentication to access the applications. To this purpose, the Web Application Proxy needs to be joined to the same Active Directory domain as the AD FS server(s).

The first scenario is the preferred scenario. In this scenario, Web Application Proxies only need TCP 443 access to the (load-balancer of the) internal AD FS Servers from the perimeter network. The AD FS Fam must be discoverable through HOSTS or DNS.

To the Internet, the (load-balancer of the) Web Applications Proxies need to be accessible on TCP 443. TCP 49443 may be required on Windows Server 2012 R2-based AD FS implementations and Windows Server 2016/2019-based AD FS implementation that do not have the certauth.adfsname.domain.tld DNS name registered in the AD FS Service Communications certificate.

Designing Azure AD Connect Server networking

Azure AD Connect servers should be placed as close as possible to Domain Controllers from a networking perspective. Azure AD Connect servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As Azure AD Connect servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.

The traffic from Azure AD Connect to its Azure-based endpoints cannot be inspected, as it uses mTLS. However, the traffic can be passed through a proxy server (multiple times).

In contrast to earlier versions of the Azure AD Connect Health agent, the current Azure AD Connect Health agent is capable of using a proxy server, if manual registration is performed through Windows PowerShell and the PowerShell session is configured to use a proxy.

Organizations may choose to domain-join or not to domain-join Azure AD Connect installations. non-Domain-joined Azure AD Connect installations cannot be used to manage AD FS. non-Domain-joined Azure AD Connect installations also require more administrative effort to maintain, activate, update, audit and monitor.

   

Concluding

The Active Directory administrative tier model that dominates many of today’s Active Directory implementations, can be used to make the right design decisions for Hybrid Identity components, too.

Posted on January 10, 2020 by Sander Berkouwer in Active Directory, Active Directory Federation Services, Azure Active Directory, Security

0  

HOWTO: Design a networking infrastructure for Hybrid Identity components

This entry is part 22 of 23 in the series Hardening Hybrid Identity

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

For many organizations the Active Directory administrative tier model is a reality, or at least something they strive to embrace to increase their information security.

How do the Hybrid Identity systems fit into this model?

 

About the Active Directory administrative tier model

The Active Directory administrative tier model protects identity systems using a set of buffer zones between full control of the environment (Tier 0) and the high risk workstation assets that attackers frequently compromise. The administrative tier model is composed of three levels and only includes administrative accounts, not standard user accounts. The Tier model prevents escalation of privilege by restricting what administrators can control and where they can log on (because logging on to a computer grants control of those credentials and all assets managed by those credentials).

In the model, Active Directory Domain Controllers are placed in Tier 0.

As Tier 0 is the only tier intended to allow direct control of enterprise identities in the environment, Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it.

 

Creating a Tier Strategy for Hybrid Identity components

Designing a tier strategy for Hybrid Identity components consists of four separate tasks:

  1. Designing AD FS Server placement
  2. Designing Web Application Proxy placement
  3. Designing Azure AD Connect Server placement
  4. Designing Azure AD Password Protection placement

 

Designing AD FS Server placement

AD FS Servers should be placed in Tier 0.
Communications between AD FS servers and between AD FS servers and Domain Controllers should be isolated in Tier 0, too. This traffic should not be permitted to cross less-secure networking zones.

In the RFCs, AD FS servers are referred to as Security Token Service (STS) servers. Functionally, they translate Kerberos tokens to claim tokens. Claim tokens are the equivalent of Kerberos tokens for their respective open protocols, like WS-Federation, SAML, OAuth2, Open ID Connect and SCIM.

The way an attacker may use claim tokens is to forge a claim token for an administrative user account and then reset its password using Azure AD Self-Service Password Reset.

When Microsoft SQL Server is used as the back-end for AD FS, the SQL server(s) hosting the database should also be placed in Tier 0. This might mean that the SQL Server (cluster) hosting the ADFSConfigurationVx and ADFSArtifactStore databases should be a separate SQL Server (cluster) than the one(s) hosting other non-Tier0 databases.

Designing Web Application Proxy placement

Web Application Proxies should be placed on the extranet.
They should not be joined to an Active Directory domain.

For their communications to AD FS servers, Web Application Proxies only use TCP443 (https), leveraging MS-ADFSPIP with short-lived certificates that are signed and distributed by the AD FS farm. However, this communications flow into Tier 0 cannot be intercepted or inspected, as it would break MS-ADFSPIP. Instead, intercept and inspect at the edge of the network.

Designing Azure AD Connect Server placement

Azure AD Connect servers should be placed in Tier 0.

Azure AD Connect uses an ADSync database per Azure AD Connect installation. This database contains information on all objects in scope for Azure AD Connect. It also contains information on its service accounts, used to write objects in Azure AD and to perform write-back operations into Active Directory.

An attacker can use the information in the ADSync database to create and alter objects in both Azure AD and Active Directory.

As Tier 0 dictates no Internet access, Azure AD Connect should be configured to use  proxy servers to transit from Tier 0 into Tier 1 and, ideally, from Tier 1 to the Internet.

Designing Azure AD Password Protection placement

Azure AD Password Protection can be used to prevent weak passwords. It offers a hybrid model, where password changes are intercepted using a password filter driver on each Domain Controller and a proxy component to update the password filter driver.

The Azure AD Password Protection agent component is installed on each Domain Controller and therefore resides in Tier 0.

The Azure AD Password Protection proxy component should be placed in Tier 1. This component was designed to do so, as Microsoft specifically signs and encrypts each update that goes to the Domain Controllers.

 

Designing a networking infrastructure for Hybrid Identity components

Designing a networking infrastructure for Hybrid Identity components consists of three separate tasks:

  1. Designing AD FS Server networking
  2. Designing Web Application Proxy networking
  3. Designing Azure AD Connect Server networking

 

Designing AD FS Server networking

AD FS Servers should be placed as close as possible to Domain Controllers from a networking perspective. This prevents time-outs that may result in authentication failures for end-users.

AD FS servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As AD FS servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.

AD FS servers need to exchange federation metadata with federation partners, when the relying party trust (RPT) to these partners is configured through a Federation Metadata URL. AD FS servers also need to perform certificate revocation checks for the certificates of federation partners. The above traffic can be allowed through a proxy.

Designing Web Application Proxy networking

Web Application Proxies can be integrated with the networking infrastructure in two ways:

  1. Web Application Proxies can be placed on a perimeter network.
  2. Web Application Proxies can be domain-joined.

In the first scenario, the Web Application Proxy acts as an AD FS Proxy to publish the AD FS servers in the AD FS farm to the Internet. Publishing AD FS to the Internet is a requirement for federating with Azure AD and Office 365. In this scenario, the Web Application Proxy is capable of publishing application with pass-through authentication.

In the second scenario, the Web Application Proxy acts as both an AD FS Proxy and an App-publishing proxy. However, the web applications in this scenario need to be published requiring AD FS authentication to access the applications. To this purpose, the Web Application Proxy needs to be joined to the same Active Directory domain as the AD FS server(s).

The first scenario is the preferred scenario. In this scenario, Web Application Proxies only need TCP 443 access to the (load-balancer of the) internal AD FS Servers from the perimeter network. The AD FS Fam must be discoverable through HOSTS or DNS.

To the Internet, the (load-balancer of the) Web Applications Proxies need to be accessible on TCP 443. TCP 49443 may be required on Windows Server 2012 R2-based AD FS implementations and Windows Server 2016/2019-based AD FS implementation that do not have the certauth.adfsname.domain.tld DNS name registered in the AD FS Service Communications certificate.

Designing Azure AD Connect Server networking

Azure AD Connect servers should be placed as close as possible to Domain Controllers from a networking perspective. Azure AD Connect servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As Azure AD Connect servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.

The traffic from Azure AD Connect to its Azure-based endpoints cannot be inspected, as it uses mTLS. However, the traffic can be passed through a proxy server (multiple times).

In contrast to earlier versions of the Azure AD Connect Health agent, the current Azure AD Connect Health agent is capable of using a proxy server, if manual registration is performed through Windows PowerShell and the PowerShell session is configured to use a proxy.

Organizations may choose to domain-join or not to domain-join Azure AD Connect installations. non-Domain-joined Azure AD Connect installations cannot be used to manage AD FS. non-Domain-joined Azure AD Connect installations also require more administrative effort to maintain, activate, update, audit and monitor.

   

Concluding

The Active Directory administrative tier model, that dominates many of today’s Active Directory implementations, can be used to make the right design decisions for Hybrid Identity components and their networking, too.

Posted on January 10, 2020 by Sander Berkouwer in Active Directory, Active Directory Federation Services, Azure Active Directory, Security

0  

Is the Authenticator App required for free Azure MFA?

Azure Active Directory

At Microsoft Ignite 2019, Microsoft announced free Azure Multi-factor Authentication for all through the new Security Defaults feature for Azure Active Directory: Enable multi-factor authentication for free.

Now, the official documentation shares more information on this feature and it implies that Azure Multi-factor Authentication (Azure MFA) is only free when it is enabled through the Security Defaults and when users in the Azure AD tenant use an Authenticator App as their multi-factor authentication method:

Security defaults allow registration and use of Azure Multi-Factor Authentication using only the Microsoft Authenticator app using notifications.

 

About Azure Multi-factor Authentication

Azure Multi-factor Authentication (Azure MFA) is a Microsoft service that offers additional verification mechanisms for sign-ins. This service is offered from within Microsoft’s datacenters around the globe through localized points of presence (PoPs).

Azure MFA can be leveraged as an additional verification mechanism through:

Azure MFA registration can be combined with the registration for Azure AD Self-service Password Reset, to make the registration for the one complete the registration for the other.

 

About Azure AD Security Defaults

Security Defaults is a new Azure AD feature. As noted in the Release Notes for Azure Active Directory for December 2019, Security Defaults replace the Baseline Policies in Azure AD’s Conditional Access.

Per February 2020, the free Baseline Policies are going away. After this time, Conditional Access policies are available to organizations with Azure AD Premium licenses, only. The granularity of the Conditional Access Baseline Policies is sacrificed to the Security Defaults, that enable all functionality of the Baseline Policies:

Conditional Access Baseline Policies

Today, if you enable Security Defaults, the Conditional Access Baseline Policies are removed and you cannot:

  • Create any Conditional Access policies, in Azure AD tenants without Azure AD Premium licenses
  • Enable any Conditional Access policies, in Azure AD tenants with Azure AD Premium licenses

Note:
When you disable Security Defaults, the Conditional Access Baseline Policies do not reappear.

 

The Default Azure MFA Experience

In an Azure AD tenant without Azure AD Premium licenses, After successfully signing in with the initial password and changing the sign-in password, a person with a new user account is confronted with a More information required page. Your organization needs more information to keep your account secure.

When clicking Next, the person is met with the following page to register multi-factor authentication, because it is enabled through the Security Defaults:

Additional security verification, allowing Mobile app-only

Here, the person can only register Azure MFA through a mobile app as it is the only option available in the drop-down list.

 

Changing the Authentication Method

Alternatively, the person can go to the MyProfile experience and click the Skip for now (14 days until this is required) link on the More information required page.

Then, in the MyProfile experience, the person can click the ADDITIONAL SECURITY VERIFICATION link on the Security Info tile. Here, the person is greeted with the default option for Authentication phone: Winking smile

Additional security verification, allowing Authentication phone and Mobile app

Additionally, in the MySignins experience, the person can add and change verification methods.

 

Concluding

No.

An Authenticator App is not required to get free Microsoft Azure MFA. Smile

Azure AD Preview features may change at any time.

Conditional Access Baseline Policies are in public preview. Microsoft warns not to use Azure AD Preview features in production, as they might change any moment. The Conditional Access Baseline Policies will never leave public preview and are going away to make room for the Azure AD Security Defaults. We had been warned…

Microsoft Documentation may differ from actual technical possibilities.

This may be due to development timelines and overarching strategies. Today, you can technically change the authentication method when using free Azure MFA. Furthermore, as admins for Azure AD tenants without Azure AD Premium licenses do not have access to the Azure MFA admin pages, they cannot enable and/or disable specific Azure MFA authentication methods.

Premium licenses are needed to block non-Authenticator App methods

Chief Information Security Officers (CISOs) who have been dreaming of free secure Azure MFA may be rudely awoken by the information in this blogpost. Yes, Azure MFA is now free. No, without Azure AD Premium licenses you cannot control the authentication methods available to people in the Azure AD tenant. Thus, they can use an authentication method that doesn’t meet NIST’s SP800-63B guideline.

Even this may change…

Security Defaults do not have the Preview label in the Azure Portal, but the above method to change the authentication method might change in the future… Also, the line in the Microsoft Documentation can be interpreted as a licensing statement instead of a technical possibility. In that case, people in organizations without Azure AD Premium licenses may break the organization’s compliance by simply following the above route. Surprised smile

Posted on January 8, 2020 by Sander Berkouwer in Azure Active Directory, Enterprise Security, Multi-Factor Authentication

2  

What’s New in Azure Active Directory in December 2019

Azure Active Directory

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following planned, new and changed functionality for Azure Active Directory for December 2019:

 

What’s New

Integrate SAP SuccessFactors provisioning into Azure AD and on-premises AD Public Preview

Service category: App Provisioning
Product capability: Identity Lifecycle Management

Azure AD administrators can now integrate  (SAP) SuccessFactors as an authoritative identity source in Azure AD. This integration helps organizations automate the end-to-end identity lifecycle, including using HR-based events, like new hires or terminations, to control provisioning of Azure AD accounts.

 

Support for customized emails in Azure AD B2C Public Preview

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Azure AD administrators can now use Azure AD B2C to create customized emails when people sign up to use their organization’s apps. By using DisplayControls (currently in preview) and a third-party email provider (such as, SendGrid, SparkPost, or a custom REST API), they can use their own email template, From address, and subject text, as well as support localization and custom one-time password (OTP) settings.

 

What’s Changed

Replacement of baseline policies with security defaults

Service category: Other
Product capability: Identity Security and Protection

As part of a secure-by-default model for authentication, Microsoft is removing the existing baseline protection policies from all Azure AD tenants. This removal is targeted for completion at the end of February 2020.

The replacement for these baseline protection policies is security defaults. If Azure AD administrators have been using baseline protection policies, they must plan to move to the new security defaults policy or to Conditional Access.

Note:
If Azure AD administrators haven’t used these policies, there is no action for them to take.

Posted on January 7, 2020 by Sander Berkouwer in Azure Active Directory, What's New

0  

On-premises Identity updates & fixes for December 2019

Windows Server

Even though Microsoft’s Identity focus moves towards the cloud, they are not forgetting their on-premises roots. Windows Server 2016 and Windows Server 2019 still receive updates. These are the updates and fixes we saw for December 2019:

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4530689 December 10, 2019

The December 10 update for Windows Server 2016 (KB4530689), updating the OS build number to 14393.3384 is an update that combines security and quality improvements.

While this updates contains updates for several vulnerabilities, even some rated critical, none of them are identity-related.

When running Active Directory Domain Controllers as virtual machines on top of Microsoft Hyper-V, two vulnerabilities (CVE-2019-1470 and CVE-2019-1471) are fixed in this update. it is recommended to install this update on the Hyper-V hosts, as these vulnerabilities may be abused to compromise virtual Domain Controllers.

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB45530715 December 10, 2019

The December 10 update for Windows Server 2019 (KB4530715), updating the OS build number to 17763.914 is an update that combines security and quality improvements.

While this updates contains updates for several vulnerabilities, even some rated critical, none of them are identity-related.

When running Active Directory Domain Controllers as virtual machines on top of Microsoft Hyper-V, two vulnerabilities (CVE-2019-1470 and CVE-2019-1471) are fixed in this update. it is recommended to install this update on the Hyper-V hosts, as these vulnerabilities may be abused to compromise virtual Domain Controllers.

Posted on January 3, 2020 by Sander Berkouwer in Microsoft Windows Server 2016, Microsoft Windows Server 2019, Security Updates

0