| Print support |  |  |
| Multi-tab support |  |  |
| Allow/Block URL support |  <p>*\*For Microsoft Edge kiosk mode use* Windows Defender Firewall<em>. Microsoft kiosk browser has custom policy support.</em> |  |
| Allow/Block URL support |   |
| Configure Home Button |  |  |
| Set Start page(s) URL |  |  <p>*Same as Home button URL* |
| Set New Tab page URL |  |  |
@ -255,7 +255,7 @@ In the following table, we show you the features available in both Microsoft Edg
| SKU availability | Windows 10 October 2018 Update<br>Professional, Enterprise, and Education | Windows 10 April 2018 Update<br>Professional, Enterprise, and Education |
**\*Windows Defender Firewall**<p>
To prevent access to unwanted websites on your kiosk device, use Windows Defender Firewall to configure a list of allowed websites, blocked websites or both. For more details, see [Windows Defender Firewall with Advanced Security Deployment](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide).
To prevent access to unwanted websites on your kiosk device, use Windows Defender Firewall to configure a list of allowed websites, blocked websites or both, using IP addresses. For more details, see [Windows Defender Firewall with Advanced Security Deployment Guide](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security-deployment-guide).
@ -102,6 +102,7 @@ Not sure what the indicator lights on your HoloLens mean? Want to know how HoloL
| - | - | - |
| You press the Power button. | One light flashes five times, then turns off. | The HoloLens battery is critically low. Charge your HoloLens. |
| You press the Power button. | All five lights flash five times, then turn off. | HoloLens cannot start correctly and is in an error state. [Reinstall the operating system](hololens-recovery.md) to recover your device. |
| You press the Power button. | The 1st, 3rd, and 5th lights flash together continually. | HoloLens may have a hardware failure. To be sure, [reinstall the OS](hololens-recovery.md#hololens-2), and try again. After reinstalling the OS, if the light-flash pattern persists, contact [support](https://support.microsoft.com/en-us/supportforbusiness/productselection?sapid=3ec35c62-022f-466b-3a1e-dbbb7b9a55fb). |
> A log file is not created by default. In order to create a log file, you will need to append "/l*v [path]"
For more information, refer to [Command line options](https://docs.microsoft.com/windows/win32/msi/command-line-options) documentation.
> [!IMPORTANT]
> If you want to keep your Surface Dock updated using any other method, refer to [Update your Surface Dock](https://support.microsoft.com/help/4023478/surface-update-your-surface-dock) for details.
## Intune deployment
You can use Intune to distribute Surface Dock Firmware Update to your devices. First you will need to convert the MSI file to the .intunewin format, as described in the following documentation: [Intune Standalone - Win32 app management](https://docs.microsoft.com/intune/apps/apps-win32-app-management).
@ -84,8 +90,8 @@ Successful completion of Surface Dock Firmware Update results in new registry ke
| Surface Dock Firmware Update log | /l*v %windir%\logs\Applications\SurfaceDockFWI.log | Earlier versions of this tool wrote events to Applications and Services Logs\Microsoft Surface Dock Updater. |
| Windows Device Install log | %windir%\inf\setupapi.dev.log | For more information about using Device Install Log, refer [to SetupAPI Logging](https://docs.microsoft.com/windows-hardware/drivers/install/setupapi-logging--windows-vista-and-later-) documentation. |
| Surface Dock Firmware Update log | Path needs to be specified (see note) | Earlier versions of this tool wrote events to Applications and Services Logs\Microsoft Surface Dock Updater. |
| Windows Device Install log | %windir%\inf\setupapi.dev.log | For more information about using Device Install Log, refer to [SetupAPI Logging](https://docs.microsoft.com/windows-hardware/drivers/install/setupapi-logging--windows-vista-and-later-). |
**Table 2. Event log IDs for Surface Dock Firmware Update**
@ -97,6 +103,10 @@ Successful completion of Surface Dock Firmware Update results in new registry ke
| 2003 | Dock firmware update failed to get firmware version. |
@ -82,7 +82,8 @@ In organizations using only Azure AD, you can connect from an Azure AD-joined PC
- Password
- Windows Hello for Business, with or without an MDM subscription.
> [!NOTE]
> If the RDP client is running Windows Server 2016 or Windows Server 2019, to be able to connect to Azure Active Directory-joined PCs, it must [allow Public Key Cryptography Based User-to-User (PKU2U) authentication requests to use online identities](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities).
Starting in Windows 10, version 1703, you can import ADMX files (also called ADMX ingestion) and set those ADMX-backed policies for Win32 and Desktop Bridge apps by using Windows 10 Mobile Device Management (MDM) on desktop SKUs. The ADMX files that define policy information can be ingested to your device by using the Policy CSP URI, `./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall`. The ingested ADMX file is then processed into MDM policies.
NOTE: Starting from the following Windows 10 version Replace command is supported
- Windows 10, version 1903 with KB4512941 and KB4517211installed
- Windows 10, version 1809 withKB4512534and KB installed
- Windows 10, version 1803 withKB4512509and KB installed
- Windows 10, version 1709 withKB4516071and KB installed
When the ADMX policies are imported, the registry keys to which each policy is written are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the **System**, **Software\Microsoft**, and **Software\Policies\Microsoft** keys, except for the following locations:
- Software\Policies\Microsoft\Office\
@ -48,6 +54,8 @@ When the ADMX policies are imported, the registry keys to which each policy is w
- software\microsoft\exchange\
- software\policies\microsoft\vba\security\
- software\microsoft\onedrive
- software\Microsoft\Edge
- Software\Microsoft\EdgeUpdate\
> [!Warning]
> Some operating system components have built in functionality to check devices for domain membership. MDM enforces the configured policy values only if the devices are domain joined, otherwise it does not. However, you can still import ADMX files and set ADMX-backed policies regardless of whether the device is domain joined or non-domain joined.
@ -36,7 +36,7 @@ It is intended that shared PCs are joined to an Active Directory or Azure Active
When the account management service is turned on in shared PC mode, accounts are automatically deleted. Account deletion applies to Active Directory, Azure Active Directory, and local accounts that are created by the **Guest** and **Kiosk** options. Account management is performed both at sign-off time (to make sure there is enough disk space for the next user) as well as during system maintenance time periods. Shared PC mode can be configured to delete accounts immediately at sign-out or when disk space is low. In Windows 10, version 1703, an inactive option is added which deletes accounts if they haven't signed in after a specified number of days.
### Maintenance and sleep
Shared PC mode is configured to take advantage of maintenance time periods which run while the PC is not in use. Therefore, sleep is strongly recommended so that the PC can wake up when it is not is use to perform maintenance, clean up accounts, and run Windows Update. The recommended settings can be set by choosing **SetPowerPolicies** in the list of shared PC options. Additionally, on devices without Advanced Configuration and Power Interface (ACPI) wake alarms, shared PC mode will always override real-time clock (RTC) wake alarms to be allowed to wake the PC from sleep (by default, RTC wake alarms are off). This ensures that the widest variety of hardware will take advantage of maintenance periods.
Shared PC mode is configured to take advantage of maintenance time periods which run while the PC is not in use. Therefore, sleep is strongly recommended so that the PC can wake up when it is not in use to perform maintenance, clean up accounts, and run Windows Update. The recommended settings can be set by choosing **SetPowerPolicies** in the list of shared PC options. Additionally, on devices without Advanced Configuration and Power Interface (ACPI) wake alarms, shared PC mode will always override real-time clock (RTC) wake alarms to be allowed to wake the PC from sleep (by default, RTC wake alarms are off). This ensures that the widest variety of hardware will take advantage of maintenance periods.
While shared PC mode does not configure Windows Update itself, it is strongly recommended to configure Windows Update to automatically install updates and reboot (if necessary) during maintenance hours. This will help ensure the PC is always up to date and not interrupting users with updates.
! ndv: No better matching drivers found for device 'PCI\VEN_8086&DEV_8C4F&SUBSYS_05BE1028&REV_04\3&11583659&0&F8'.
! ndv: No devices were updated.
<<<Sectionend2019/09/2620:13:01.759
<<< [Exit status: FAILURE(0xC1900101)]
</pre>
<br>This analysis indicates that the Windows upgrade error can be resolved by deleting the C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\[CN] file. Note: In this example, the full, unshortened file name is C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18\be8228fb2d3cb6c6b0ccd9ad51b320b4_a43d512c-69f2-42de-aef9-7a88fabdaa3f.
@ -27,7 +27,7 @@ Before deploying a device using Windows Autopilot, the device must be registered
## OEM registration
When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers" section of the [Windows Autopilot information page](https://www.microsoft.com/windowsforbusiness/windows-autopilot).
When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers and resellers" section of the [Windows Autopilot information page](https://aka.ms/windowsautopilot).
Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#oem-authorization).
@ -398,7 +398,7 @@ The following endpoint is used to retrieve Skype configuration values. To turn o
## Windows Defender
The following endpoint is used for Windows Defender when Cloud-based Protection is enabled.
If you [turn off traffic for this endpoint](manage-connections-from-windows-operating-system-components-to-microsoft-services.md#bkmk-defender), the device will not use Cloud-based Protection.
If you [turn off traffic for this endpoint](manage-connections-from-windows-operating-system-components-to-microsoft-services.md#bkmk-defender), the device will not use Cloud-based Protection. For a detailed list of Windows Defender Antivirus cloud service connections, see [Allow connections to the Windows Defender Antivirus cloud service](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-antivirus/configure-network-connections-windows-defender-antivirus#allow-connections-to-the-windows-defender-antivirus-cloud-service).
@ -150,7 +150,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin eq
Sign-in to an **AD FS Windows Server 2016** computer with _Enterprise Admin_ equivalent credentials.
1. Open an elevated command prompt.
2. Run `certutil -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`
2. Run `certutil -dsTemplate WHFBAuthentication,msPKI-Private-Key-Flag,+CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`
> [!NOTE]
> If you gave your Windows Hello for Business Authentication certificate template a different name, then replace **WHFBAuthentication** in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on our Windows Server 2012 or later certificate authority.
> Some information relates to pre-released product that may change before it is commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Microsoft has been aligned with the [FIDO Alliance](https://fidoalliance.org/) with a mission to replace passwords with an easy to use, strong 2FA credential. We have been working with our partners to extensively test and deliver a seamless and secure authentication experience to end users.
Microsoft has been aligned with the [FIDO Alliance](https://fidoalliance.org/) with a mission to replace passwords with an easy to use, strong 2FA credential. We have been working with our partners to extensively test and deliver a seamless and secure authentication experience to end users. See [FIDO2 security keys features and providers](https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys).
The [FIDO2 CTAP specification](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html) contains a few optional features and extensions which are crucial to provide that seamless and secure experience.
@ -196,7 +196,7 @@ Typical **Primary Group** values for user accounts:
- **New UAC Value** \[Type = UnicodeString\]: specifies flags that control password, lockout, disable/enable, script, and other behavior for the user account. If the value of **userAccountControl** attribute of user object was changed, you will see the new value here.
To decode this value, you can go through the property value definitions in the “Table 7. User’s or Computer’s account UAC flags.” from largest to smallest. Compare each property value to the flags value in the event. If the flags value in the event is greater than or equal to the property value, then the property is "set" and applies to that event. Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.
To decode this value, you can go through the property value definitions in the [User’s or Computer’s account UAC flags.](https://support.microsoft.com/help/305144/how-to-use-useraccountcontrol-to-manipulate-user-account-properties) from largest to smallest. Compare each property value to the flags value in the event. If the flags value in the event is greater than or equal to the property value, then the property is "set" and applies to that event. Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.
Here's an example: Flags value from event: 0x15
@ -226,7 +226,7 @@ Decoding:
So this UAC flags value decodes to: LOCKOUT and SCRIPT
- **User Account Control** \[Type = UnicodeString\]**:** shows the list of changes in **userAccountControl** attribute. You will see a line of text for each change. See possible values in here: “Table 7. User’s or Computer’s account UAC flags.”. In the “User Account Control field text” column, you can see the text that will be displayed in the **User Account Control** field in 4738 event.
- **User Account Control** \[Type = UnicodeString\]**:** shows the list of changes in **userAccountControl** attribute. You will see a line of text for each change. See possible values in here: [User’s or Computer’s account UAC flags](https://support.microsoft.com/help/305144/how-to-use-useraccountcontrol-to-manipulate-user-account-properties). In the “User Account Control field text” column, you can see the text that will be displayed in the **User Account Control** field in 4738 event.
- **User Parameters** \[Type = UnicodeString\]: if you change any setting using Active Directory Users and Computers management console in Dial-in tab of user’s account properties, then you will see **<value changed, but not displayed>** in this field. For local accounts, this field is not applicable and always has “<value not set>“ value.
The Federal Information Processing Standard (FIPS) Publication 140-2 is a U.S. government standard that defines minimum security requirements for cryptographic modules in information technology products, as defined in Section 5131 of the Information Technology Management Reform Act of 1996.
The [Cryptographic Module Validation Program (CMVP)](https://csrc.nist.gov/Projects/cryptographic-module-validation-program), a joint effort of the U.S. National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS), validates cryptographic modules against the Security Requirements for Cryptographic Modules (part of FIPS 140-2) and related FIPS cryptography standards. The FIPS 140-2 security requirements cover eleven areas related to the design and implementation of a cryptographic module. The NIST Information Technology Laboratory operates a related program that validates the FIPS approved cryptographic algorithms in the module.
Updated: March 2018
## Microsoft’s approach to FIPS 140-2 validation
Microsoft maintains an active commitment to meeting the requirements of the FIPS 140-2 standard, having validated cryptographic modules against it since the inception of the standard in 2001. Microsoft validates its cryptographic modules under the NIST CMVP, as described above. Multiple Microsoft products, including Windows 10, Windows Server, and many cloud services, use these cryptographic modules.
## Using Windows in a FIPS 140-2 approved mode of operation
## Introduction
Windows 10 and Windows server may be configured to run in a FIPS 140-2 approved mode of operation. This is commonly referred to as “FIPS mode.” Achieving this mode of operation requires administrators to complete all four steps outlined below.
This document provides information on how Microsoft products and cryptographic modules comply with the U.S. Federal government standard, *Federal Information Processing Standard (FIPS) 140 – Security Requirements for Cryptographic Modules* \[FIPS 140\].
### Step 1: Ensure FIPS 140-2 validated cryptographic modules are installed
### Audience
Administrators must ensure that all cryptographic modules installed are FIPS 140-2 validated. This is accomplished by cross-checking the version number of the cryptographic module with the table of validated modules at the end of this topic, organized by operating system release.
This document is primarily focused on providing information for three parties:
### Step 2: Ensure all security policies for all cryptographic modules are followed
[Procurement Officer](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_product_validation) – Responsible for verifying that Microsoft products (or even third-party applications) are either FIPS 140 validated or utilize a Microsoft FIPS 140 validated cryptographic module.
Each of the cryptographic modules has a defined security policy that must be met for the module to operate in its FIPS 140-2 approved mode. The security policy may be found in each module’s published Security Policy Document (SPD). The SPDs for each module may be found by following the links in the table of validated modules at the end of this topic. Click on the module version number to view the published SPD for the module.
[System Integrator](https://technet.microsoft.com/library/cc750357.aspx#_information_for_system) – Responsible for ensuring that Microsoft Products are configured properly to use only FIPS 140 validated cryptographic modules.
### Step 3: Enable the FIPS security policy
[Software Developer](https://technet.microsoft.com/library/cc750357.aspx#_information_for_software) – Responsible for building software products that utilize Microsoft FIPS 140 validated cryptographic modules.
Windows provides the security policy setting, “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing,” which is used by some Microsoft products to determine whether to operate in a FIPS 140-2 approved mode. When this policy is enabled, the validated cryptographic modules in Windows will also operate in FIPS approved mode. The policy may be set using Local Security Policy, as part of Group Policy, or through a Modern Device Management (MDM) solution. For more information on the policy, see [System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing).
### Document Map
### Step 4: Ensure only FIPS validated cryptographic algorithms are used
This document is broken into seven major sections:
Neither the operating system nor the cryptographic modules can enforce a FIPS approved mode of operation, regardless of the FIPS security policy setting. To run in a FIPS approved mode, an application or service must check for the policy flag and enforce the security policies of the validated modules. If an application or service uses a non-approved cryptographic algorithm or does not follow the security policies of the validated modules, it is not operating in a FIPS approved mode.
[FIPS 140 Overview](https://technet.microsoft.com/library/cc750357.aspx#_fips_140_overview) – Provides an overview of the FIPS 140 standard as well as provides some historical information about the standard.
## Frequently asked questions
[Microsoft Product Validation (Information for Procurement Officers and Auditors)](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_product_validation) – Provides information on how Microsoft products are FIPS 140 validated.
### How long does it take to certify cryptographic modules?
[Information for System Integrators](https://technet.microsoft.com/library/cc750357.aspx#_information_for_system) – Describes how to configure and verify that Microsoft Products are being used in a manner consistent with the product’s FIPS 140 Security Policy.
Microsoft begins certification of cryptographic modules after each major feature release of Windows 10 and Windows Server. The duration of each evaluation varies, depending on many factors.
[Information for Software Developers](https://technet.microsoft.com/library/cc750357.aspx#_information_for_software) – Identifies how developers can leverage the Microsoft FIPS 140 validated cryptographic modules.
### When does Microsoft undertake a FIPS 140 validation?
The cadence for starting module validation aligns with the feature updates of Windows 10 and Windows Server. As the software industry evolves, operating systems release more frequently. Microsoft completes validation work on major releases but, in between releases, seeks to minimize the changes to the cryptographic modules.
[Microsoft FIPS 140 Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_fips_140) – Explains Microsoft cryptographic architecture and identifies specific modules that are FIPS 140 validated.
### What is the difference between “FIPS 140 validated” and “FIPS 140 compliant”?
[Cryptographic Algorithms](https://technet.microsoft.com/library/cc750357.aspx#_cryptographic_algorithms) – Lists the cryptographic algorithm, modes, states, key sizes, Windows versions, and corresponding cryptographic algorithm validation certificates.
“FIPS 140 validated” means that the cryptographic module, or a product that embeds the module, has been validated (“certified”) by the CMVP as meeting as meeting the FIPS 140-2 requirements. “FIPS 140 compliant” is an industry term for IT products that rely on FIPS 140 validated products for cryptographic functionality.
## FIPS 140 Overview
### I need to know if a Windows service or application is FIPS 140-2 validated.
### FIPS 140 Standard
The cryptographic modules leveraged in Windows are validated through the CMVP, not individual services, applications, hardware peripherals, or other solutions. For a solution to be considered compliant, it must call a FIPS 140-2 validated cryptographic module in the underlying OS and the OS must be configured to run in FIPS mode. Contact the vendor of the service, application, or product for information on whether it calls a validated cryptographic module.
FIPS 140 is a US government and Canadian government standard that defines a minimum set of the security requirements for products that implement cryptography. This standard is designed for cryptographic modules that are used to secure sensitive but unclassified information. Testing against the FIPS 140 standard is maintained by the Cryptographic Module Validation Program (CMVP), a joint effort between the US National Institute of Standards and Technology (NIST) and the Communications Security Establishment of Canada (CSEC).
### What does "When operated in FIPS mode" mean on a certificate?
The current standard defines four-levels of increasing security, 1 through 4. Most software products (including all Microsoft products) are tested against the Level 1 security requirements.
This caveat identifies required configuration and security rules that must be followed to use the cryptographic module in a way that is consistent with its FIPS 140-2 security policy. Each module has its own security policy—a precise specification of the security rules under which it will operate—and employs approved cryptographic algorithms, cryptographic key management, and authentication techniques. The security rules are defined in the Security Policy Document (SPD) for each module.
### Applicability of the FIPS standard
### What is the relationship between FIPS 140-2 and Common Criteria?
Within the US Federal government, the FIPS 140 standard applies to any security system (whether hardware, firmware, software, or a combination thereof) to be used by agencies for protecting sensitive but unclassified information. Some agencies have expanded its use by requiring that the modules to be procured for secret systems also meet the FIPS 140 requirements.
These are two separate security standards with different, but complementary, purposes. FIPS 140-2 is designed specifically for validating software and hardware cryptographic modules, while Common Criteria is designed to evaluate security functions in IT software and hardware products. Common Criteria evaluations often rely on FIPS 140-2 validations to provide assurance that basic cryptographic functionality is implemented properly.
The FIPS 140 standard has also been used by different standards bodies, specification groups, nations, and private institutions as a requirement or guideline for those products (e.g. – Digital Cinema Systems Specification).
### How does FIPS 140 relate to Suite B?
### History of 140-1
Suite B is a set of cryptographic algorithms defined by the U.S. National Security Agency (NSA) as part of its Cryptographic Modernization Program. The set of Suite B cryptographic algorithms are to be used for both unclassified information and most classified information. The Suite B cryptographic algorithms are a subset of the FIPS Approved cryptographic algorithms as allowed by the FIPS 140-2 standard.
FIPS 140-1 is the original working version of the standard made official on January 11, 1994. The standard remained in effect until FIPS 140-2 became mandatory for new products on May 25, 2002.
### FIPS 140-2
FIPS 140-2 is currently the active version of the standard.
### Microsoft FIPS Support Policy
Microsoft actively maintains FIPS 140 validation for its cryptographic modules.
### FIPS Mode of Operation
The common term “FIPS mode” is used in this document and Security Policy documents. When a cryptographic module contains both FIPS-approved and non-FIPS approved security methods, it must have a "FIPS mode of operation" to ensure only FIPS-approved security methods may be used. When a module is in "FIPS mode", a non-FIPS approved method cannot be used instead of a FIPS-approved method.
## Microsoft Product Validation (Information for Procurement Officers and Auditors)
This section provides information for Procurement Officers and Auditors who are responsible for ensuring that Microsoft products with FIPS 140 validated cryptographic modules are used in their organization. The goal of this section is to provide an overview of the Microsoft developed products and modules and explain how the validated cryptographic modules are used.
### Microsoft Product Relationship with CNG and CAPI libraries
Rather than validate individual components and products, Microsoft chooses to validate only the underlying cryptographic modules. Subsequently, many Windows components and Microsoft products are built to rely on the Cryptographic API: Next Generation (CNG) and legacy Cryptographic API (CAPI) FIPS 140 validated cryptographic modules. Windows components and Microsoft products use the documented application programming interfaces (APIs) for each of the modules to access various cryptographic services.
The following list contains some of the Windows components and Microsoft products that rely on FIPS 140 validated cryptographic modules:
- Schannel Security Package
- Remote Desktop Protocol (RDP) Client
- Encrypting File System (EFS)
- Some Microsoft .NET Framework Applications (.NET also provides cryptographic algorithm implementations that have not been FIPS 140 validated.)
- BitLocker® Drive Full-volume Encryption
- IPsec Settings of Windows Firewall
- Server Message Block (SMB) 3.x
## Information for System Integrators
This section provides information for System Integrators and Auditors who are responsible for deploying Microsoft products in a manner consistent with the product’s FIPS 140 Security Policy.
There are two steps to ensure that Microsoft products operate in FIPS mode:
1. Selecting/Installing FIPS 140 validated cryptographic modules
2. Setting FIPS local/group security policy flag.
### Step 1 – Selecting/Installing FIPS 140 Validated Cryptographic Modules
Systems Integrators must ensure that all cryptographic modules installed are, in fact, FIPS 140 validated. This can be accomplished by cross-checking the version number of the installed module with the list of validated binaries. The list of validated CAPI binaries is identified in the [CAPI Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_capi_validated_cryptographic) section below and the list of validated CNG binaries is identified in the [CNG Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_cng_validated_cryptographic) section below. There are similar sections for all other validated cryptographic modules.
The version number of the installed binary is found by right-clicking the module file and clicking on the Version or Details tab. Cryptographic modules are stored in the "windows\\system32" or "windows\\system32\\drivers" directory.
### Step 2 – Setting FIPS Local/Group Security Policy Flag
The Windows operating system provides a group (or local) security policy setting, “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”, which is used by many Microsoft products to determine whether to operate in a FIPS-approved mode. When this policy is set, the validated cryptographic modules in Windows will also operate in a FIPS-approved mode.
**Note** – There is no enforcement of the FIPS policy by the operating system or the validated cryptographic modules. Instead, each individual application must check this flag and enforce the Security Policy of the validated cryptographic modules.
#### Instructions on Setting the FIPS Local/Group Security Policy Flag
While there are alternative methods for setting the FIPS local/group security policy flag, the following method is included as a guide to users with Administrative privileges. This description is for the Local Security Policy, but the Group Security Policy may be set in a similar manner.
1. Open the 'Run' menu by pressing the combination 'Windows Key + R'.
2. Type 'secpol.msc' and press 'Enter' or click the 'Ok' button.
3. In the Local Security Policy management console window that opens, use the left tab to navigate to the Local Policies -\> Security Options.
4. Scroll down the right pane and double-click 'System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing'.
5. In the properties window, select the 'Enabled' option and click the 'Apply' button.
#### Microsoft Components and Products That Utilize FIPS Local/Group Security Policy
The following list details some of the Microsoft components that use the cryptographic functionality implemented by either CNG or legacy CAPI. When the FIPS Local/Group Security Policy is set, the following components will enforce the validated module Security Policy.
- Schannel Security Package
- Remote Desktop Protocol (RDP) Client
- Encrypting File System (EFS)
- Some Microsoft .NET Framework Applications (.NET also provides cryptographic algorithm implementations that have not been FIPS 140 validated.)
- BitLocker® Drive Full-volume Encryption
- IPsec Settings of Windows Firewall
#### Effects of Setting FIPS Local/Group Security Policy Flag
When setting the FIPS local/group security policy flag, the behavior of several Microsoft components and products are affected. The most noticeable difference will be that the components enforcing this setting will only use those algorithms approved or allowed in FIPS mode. The specific changes to the products listed above are:
- Schannel Security Package forced to negotiate sessions using TLS. The following supported Cipher Suites are disabled:
- - TLS\_RSA\_WITH\_RC4\_128\_SHA
- TLS\_RSA\_WITH\_RC4\_128\_MD5
- SSL\_CK\_RC4\_128\_WITH\_MD5
- SSL\_CK\_DES\_192\_EDE3\_CBC\_WITH\_MD5
- TLS\_RSA\_WITH\_NULL\_MD5
- TLS\_RSA\_WITH\_NULL\_SHA
- The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:
- - CALG\_RSA\_KEYX - RSA public key exchange algorithm
- CALG\_3DES - Triple DES encryption algorithm
- CALG\_AES\_128 - 128 bit AES
- CALG\_AES\_256 - 256 bit AES
- CALG\_SHA1 - SHA hashing algorithm
- CALG\_SHA\_256 - 256 bit SHA hashing algorithm
- CALG\_SHA\_384 - 384 bit SHA hashing algorithm
- CALG\_SHA\_512 - 512 bit SHA hashing algorithm
- Any Microsoft .NET Framework applications, such as Microsoft ASP.NET or Windows Communication Foundation (WCF), only allow algorithm implementations that are validated to FIPS 140, meaning only classes that end in "CryptoServiceProvider" or "Cng" can be used. Any attempt to create an instance of other cryptographic algorithm classes or create instances that use non-allowed algorithms will cause an InvalidOperationException exception.
- Verification of ClickOnce applications fails unless the client computer has .NET Framework 2.0 SP1 or later service pack installed or .NET Framework 3.5 or later installed.
- On Windows Vista and Windows Server 2008 and later, BitLocker Drive Encryption switches from AES-128 using the elephant diffuser to using the approved AES-256 encryption. Recovery passwords are not created or backed up. Instead, backup a recovery key on a local drive or on a network share. To use the recovery key, put the key on a USB device and plug the device into the computer.
Please be aware that selection of FIPS mode can limit product functionality (See <http://support.microsoft.com/kb/811833>).
## Information for Software Developers
This section is targeted at developers who wish to build their own applications using the FIPS 140 validated cryptographic modules.
Each of the validated cryptographic modules defines a series of rules that must be followed. The security rules for each validated cryptographic module are specified in the Security Policy document. Links to each of the Security Policy documents is provided in the [Microsoft FIPS 140 Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_fips_140) section below. Generally, the restriction in Microsoft validated cryptographic modules is limiting the use of cryptography to only FIPS Approved cryptographic algorithms, modes, and key sizes.
### Using Microsoft Cryptographic Modules in a FIPS mode of operation
No matter whether developing with native languages or using .NET, it is important to first check whether the CNG modules for the target system are FIPS validated. The list of validated CNG binaries is identified in the [CNG Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_cng_validated_cryptographic) section.
When developing using CNG directly, it is the responsibility of the developer to follow the security rules outlined in the FIPS 140 Security Policy for each module. The security policy for each module is provided on the CMVP website. Links to each of the Security Policy documents is provided in the tables below. It is important to remember that setting the FIPS local/group security policy Flag (discussed above) does not affect the behavior of the modules when used for developing custom applications.
If you are developing your application using .NET instead of using the native libraries, then setting the FIPS local policy flag will generate an exception when an improper .NET class is used for cryptography (i.e. the cryptographic classes whose names end in "Managed"). The names of these allowed classes end with "Cng", which use the CNG binaries or "CryptoServiceProvider", which use the legacy CAPI binaries.
### Key Strengths and Validity Periods
NIST Special Publication 800-131A Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, dated November 2015, \[[SP 800-131A](http://dx.doi.org/10.6028/nist.sp.800-131ar1)\], offers guidance for moving to stronger cryptographic keys and algorithms. This does not replace NIST SP 800-57, Recommendation for Key Management Part 1: General, \[[SP 800-57](http://csrc.nist.gov/publications/pubssps.html#800-57-part1)\], but gives more specific guidance. One of the most important topics discussed in these publications deals with the key strengths of FIPS Approved algorithms and their validity periods. When developing applications that use FIPS Approved algorithms, it is also extremely important to select appropriate key sizes based on the security lifetimes recommended by NIST.
## FIPS 140 FAQ
The following are answers to commonly asked questions for the FIPS 140-2 validation of Microsoft products.
1. How does FIPS 140 relate to the Common Criteria?
**Answer:** These are two separate security standards with different, but complementary, purposes. FIPS 140 is a standard designed specifically for validating product modules that implement cryptography. On the other hand, Common Criteria is designed to help evaluate security functions in IT products.
In many cases, Common Criteria evaluations will rely on FIPS 140 validations to provide assurance that cryptographic functionality is implemented properly.
2. How does FIPS 140 relate to Suite B?
**Answer:** Suite B is simply a set of cryptographic algorithms defined by the U.S. National Security Agency (NSA) as part of its Cryptographic Modernization Program. The set of Suite B cryptographic algorithms are to be used for both unclassified information and most classified information.
The Suite B cryptographic algorithms are a subset of the FIPS Approved cryptographic algorithms as allowed by the FIPS 140 standard.
3. There are so many modules listed on the NIST website for each release, how are they related and how do I tell which one applies to me?
**Answer:** Microsoft strives to validate all releases of its cryptographic modules. Each module provides a different set of cryptographic algorithms. If you are required to use only FIPS validated cryptographic modules, you simply need to verify that the version being used appears on the validation list.
Please see the [Microsoft FIPS 140 Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_fips_140)section for a complete list of Microsoft validated modules.
4. My application links against crypt32.dll, cryptsp.dll, advapi32.dll, bcrypt.dll, bcryptprimitives.dll, or ncrypt.dll. What do I need to do to assure I’m using FIPS 140 validated cryptographic modules?
**Answer:** crypt32.dll, cryptsp.dll, advapi32.dll, and ncrypt.dll are intermediary libraries that will offload all cryptographic operations to the FIPS validated cryptographic modules. Bcrypt.dll itself is a validated cryptographic module for Windows Vista and Windows Server 2008. For Windows 7 and Windows Server 2008 R2 and later, bcryptprimitives.dll is the validated module, but bcrypt.dll remains as one of the libraries to link against.
You must first verify that the underlying CNG cryptographic module is validated. Once verified, you'll need to confirm that you're using the module correctly in FIPS mode (See [Information for Software Developers](https://technet.microsoft.com/library/cc750357.aspx#_information_for_software) section for details).
5. What does "When operated in FIPS mode" mean on certificates?
**Answer:** This caveat identifies that a required configuration and security rules must be followed in order to use the cryptographic module in a manner consistent with its FIPS 140 Security Policy. The security rules are defined in the Security Policy for the module and usually revolve around using only FIPS Approved cryptographic algorithms and key sizes. Please see the Security Policy for the specific security rules for each cryptographic module (See [Microsoft FIPS 140 Validated Cryptographic Modules](https://technet.microsoft.com/library/cc750357.aspx#_microsoft_fips_140) section for links to each policy).
6. Which FIPS validated module is called when Windows 7 or Windows 8 is configured to use the FIPS setting in the wireless configuration?
**Answer:** CNG is used. This setting tells the wireless driver to call FIPS 140-2 validated cryptographic modules instead of using the driver’s own cryptography, if any.
7. Is BitLocker to Go FIPS 140-2 validated?
**Answer:** There are two separate parts for BitLocker to Go. One part is simply a native feature of BitLocker and as such, it uses FIPS 140-2 validated cryptographic modules. The other part is the BitLocker to Go Reader application for down-level support of older operating systems such as Windows XP and Windows Vista. The Reader application does not use FIPS 140-2 validated cryptographic modules.
8. Are applications FIPS 140-2 validated?
**Answer:** Microsoft only has low-level cryptographic modules in Windows FIPS 140-2 validated, not high-level applications. A better question is whether a certain application calls a FIPS 140-2 validated cryptographic module in the underlying Windows OS. That question needs to be directed to the company/product group that created the application of interest.
9. How can Systems Center Operations Manager 2012 be configured to use FIPS 140-2 validated cryptographic modules?
**Answer:** See [https://technet.microsoft.com/library/hh914094.aspx](https://technet.microsoft.com/library/hh914094.aspx)
## Microsoft FIPS 140 Validated Cryptographic Modules
### Modules By Operating System
The following tables identify the Cryptographic Modules for an operating system.
#### Windows
## Microsoft FIPS 140-2 validated cryptographic modules
The following tables identify the cryptographic modules used in an operating system, organized by release.
## Modules used by Windows
##### Windows 10 Spring 2018 Update (Version 1803)
<td>See Security Policy and Certificate page for algorithm information</td>
</tr>
</tbody>
</table>
##### Windows Server 2016
@ -7082,10 +7192,3 @@ Version 6.3.9600</p></td>
\[[SP 800-57](http://csrc.nist.gov/publications/pubssps.html#800-57-part1)\] - Recommendation for Key Management – Part 1: General (Revised)
\[[SP 800-131A](http://csrc.nist.gov/publications/nistpubs/800-131a/sp800-131a.pdf)\] - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
## Additional Microsoft References
Enabling FIPS mode - <http://support.microsoft.com/kb/811833>
Cipher Suites in Schannel - [https://msdn.microsoft.com/library/aa374757(VS.85).aspx](https://msdn.microsoft.com/library/aa374757\(vs.85\).aspx)
@ -43,6 +43,9 @@ The service supports the onboarding of the following servers:
For a practical guidance on what needs to be in place for licensing and infrastructure, see [Protecting Windows Servers with Microsoft Defender ATP](https://techcommunity.microsoft.com/t5/What-s-New/Protecting-Windows-Server-with-Windows-Defender-ATP/m-p/267114#M128).
> [!NOTE]
> An Azure Security Center Standard license is required, per node, to enroll Microsoft Defender ATP on a supported Windows Server platform, see [Supported features available in Azure Security Center](https://docs.microsoft.com/azure/security-center/security-center-services)
## Windows Server 2008 R2 SP1, Windows Server 2012 R2 and Windows Server 2016
There are two options to onboard Windows Server 2008 R2 SP1, Windows Server 2012 R2 and Windows Server 2016 to Microsoft Defender ATP:
@ -178,9 +181,6 @@ Support for Windows Server, version 1803 and Windows 2019 provides deeper insigh
## Integration with Azure Security Center
Microsoft Defender ATP integrates with Azure Security Center to provide a comprehensive server protection solution. With this integration Azure Security Center can leverage the power of Microsoft Defender ATP to provide improved threat detection for Windows Servers.
>[!NOTE]
>You'll need to have the appropriate license to enable this feature.
The following capabilities are included in this integration:
- Automated onboarding - Microsoft Defender ATP sensor is automatically enabled on Windows Servers that are onboarded to Azure Security Center. For more information on Azure Security Center onboarding, see [Onboarding to Azure Security Center Standard for enhanced security](https://docs.microsoft.com/azure/security-center/security-center-onboarding).
@ -53,6 +53,9 @@ When you have configured exploit protection to your desired state (including bot
3. At the bottom of the **Exploit protection** section, click **Export settings** and then choose the location and name of the XML file where you want the configuration to be saved.
> [!IMPORTANT]
> If you want to use Default configuration, use the settings "On by default" instead of "Use Default (On)" to get the settings exported correctly on the XML file.
@ -46,7 +46,7 @@ See [Enable cloud-delivered protection](enable-cloud-protection-windows-defender
After you've enabled the service, you may need to configure your network or firewall to allow connections between it and your endpoints.
As a cloud service, it is required that computers have access to the internet and that the ATP machine learning services are reachable. The URL: "\*.blob.core.windows.net" should not be excluded from any kind of network inspection. The table below lists the services and their associated URLs. You should ensure there are no firewall or network filtering rules denying access to these URLs, or you may need to create an allow rule specifically for them (excluding the URL: "\*.blob.core.windows.net").
As a cloud service, it is required that computers have access to the internet and that the ATP machine learning services are reachable. The URL: "\*.blob.core.windows.net" should not be excluded from any kind of network inspection. The table below lists the services and their associated URLs. You should ensure there are no firewall or network filtering rules denying access to these URLs, or you may need to create an allow rule specifically for them (excluding the URL: "\*.blob.core.windows.net"). Below mention URLs are using port 443 for communication.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Dani Halfin
GitHub