Merge pull request #216484 from MicrosoftDocs/main

Publish to live, Sunday 4 PM PST, 10/30

Author: LJSpiller

.openpublishing.redirection.defender-for-cloud.json

@@ -734,6 +734,16 @@
             "source_path_from_root": "/articles/defender-for-cloud/defender-for-containers-cicd.md",
             "redirect_url": "/azure/defender-for-cloud/defender-for-devops-introduction",
             "redirect_document_id": true
+        },
+        {
+            "source_path_from_root": "/articles/defender-for-cloud/tutorial-enable-pull-request-annotations.md",
+            "redirect_url": "/azure/defender-for-cloud/enable-pull-request-annotations",
+            "redirect_document_id": true
+        },
+        {
+            "source_path_from_root": "/articles/defender-for-cloud/detect-credential-leaks.md",
+            "redirect_url": "/azure/defender-for-cloud/detect-exposed-secrets",
+            "redirect_document_id": true
         }
 
       ]

articles/active-directory/authentication/howto-mfaserver-adfs-2.md

@@ -1,12 +1,12 @@
 ---
 title: Use Azure MFA Server with AD FS 2.0 - Azure Active Directory
-description: This is the Azure Multi-Factor authentication page that describes how to get started with Azure MFA and AD FS 2.0.
+description: Describes how to get started with Azure MFA and AD FS 2.0.
 
 services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 08/27/2021
+ms.date: 10/29/2022
 
 ms.author: justinha
 author: justinha
@@ -22,11 +22,11 @@ This article is for organizations that are federated with Azure Active Directory
 This documentation covers using the Azure Multi-Factor Authentication Server with AD FS 2.0. For information about AD FS, see [Securing cloud and on-premises resources using Azure Multi-Factor Authentication Server with Windows Server](howto-mfaserver-adfs-windows-server.md).
 
 > [!IMPORTANT]
-> As of July 1, 2019, Microsoft no longer offers MFA Server for new deployments. New customers that want to require multi-factor authentication (MFA) during sign-in events should use cloud-based Azure AD Multi-Factor Authentication.
+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication (MFA) requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their users’ authentication data](how-to-migrate-mfa-server-to-azure-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).
 >
-> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication](tutorial-enable-azure-mfa.md).
+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure Multi-Factor Authentication](tutorial-enable-azure-mfa.md).
 >
-> If you use cloud-based MFA, see [Securing cloud resources with Azure AD Multi-Factor Authentication and AD FS](howto-mfa-adfs.md).
+> If you use cloud-based MFA, see [Securing cloud resources with Azure Multi-Factor Authentication and AD FS](howto-mfa-adfs.md).
 >
 > Existing customers that activated MFA Server before July 1, 2019 can download the latest version, future updates, and generate activation credentials as usual.
 
@@ -43,12 +43,12 @@ To secure AD FS 2.0 with a proxy, install the Azure Multi-Factor Authentication
    ![MFA Server IIS Authentication window](./media/howto-mfaserver-adfs-2/setup1.png)
 
 4. To detect username, password, and domain variables automatically, enter the login URL (like `https://sso.contoso.com/adfs/ls`) within the Auto-Configure Form-Based Website dialog box and click **OK**.
-5. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users have not yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
-6. If the page variables cannot be detected automatically, click the **Specify Manually…** button in the Auto-Configure Form-Based Website dialog box.
+5. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
+6. If the page variables can't be detected automatically, click the **Specify Manually…** button in the Auto-Configure Form-Based Website dialog box.
 7. In the Add Form-Based Website dialog box, enter the URL to the AD FS login page in the Submit URL field (like `https://sso.contoso.com/adfs/ls`) and enter an Application name (optional). The Application name appears in Azure Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication messages.
 8. Set the Request format to **POST or GET**.
 9. Enter the Username variable (ctl00$ContentPlaceHolder1$UsernameTextBox) and Password variable (ctl00$ContentPlaceHolder1$PasswordTextBox). If your form-based login page displays a domain textbox, enter the Domain variable as well. To find the names of the input boxes on the login page, go to the login page in a web browser, right-click on the page and select **View Source**.
-10. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users have not yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
+10. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
 
     ![Add form-based website to MFA Server](./media/howto-mfaserver-adfs-2/manual.png)
 
@@ -58,7 +58,7 @@ To secure AD FS 2.0 with a proxy, install the Azure Multi-Factor Authentication
     - Cache successful authentications to the website using cookies
     - Select how to authenticate the primary credentials
 
-12. Since the AD FS proxy server is not likely to be joined to the domain, you can use LDAP to connect to your domain controller for user import and pre-authentication. In the Advanced Form-Based Website dialog box, click the **Primary Authentication** tab and select **LDAP Bind** for the Pre-authentication Authentication type.
+12. Since the AD FS proxy server isn't likely to be joined to the domain, you can use LDAP to connect to your domain controller for user import and pre-authentication. In the Advanced Form-Based Website dialog box, click the **Primary Authentication** tab and select **LDAP Bind** for the Pre-authentication Authentication type.
 13. When complete, click **OK** to return to the Add Form-Based Website dialog box.
 14. Click **OK** to close the dialog box.
 15. Once the URL and page variables have been detected or entered, the website data displays in the Form-Based panel.
@@ -88,23 +88,23 @@ You enabled IIS authentication, but to perform the pre-authentication to your Ac
 
 1. Next, click the **Company Settings** icon and select the **Username Resolution** tab.
 2. Select the **Use LDAP unique identifier attribute for matching usernames** radio button.
-3. If users enter their username in "domain\username" format, the Server needs to be able to strip the domain off the username when it creates the LDAP query. That can be done through a registry setting.
+3. If users enter their username in "domain\username" format, the Server needs to be able to strip the domain off the username when it creates the LDAP query, which can be done through a registry setting.
 4. Open the registry editor and go to HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Positive Networks/PhoneFactor on a 64-bit server. If on a 32-bit server, take the "Wow6432Node" out of the path. Create a DWORD registry key called "UsernameCxz_stripPrefixDomain" and set the value to 1. Azure Multi-Factor Authentication is now securing the AD FS proxy.
 
-Ensure that users have been imported from Active Directory into the Server. See the [Trusted IPs section](#trusted-ips) if you would like to allow internal IP addresses so that two-step verification is not required when signing in to the website from those locations.
+Make sure users are imported from Active Directory into the Server. To allow users to skip two-step verification from internal IP addresses, see the [Trusted IPs](#trusted-ips).
 
 ![Registry editor to configure company settings](./media/howto-mfaserver-adfs-2/reg.png)
 
 ## AD FS 2.0 Direct without a proxy
 
-You can secure AD FS when the AD FS proxy is not used. Install the Azure Multi-Factor Authentication Server on the AD FS server and configure the Server per the following steps:
+You can secure AD FS when the AD FS proxy isn't used. Install the Azure Multi-Factor Authentication Server on the AD FS server and configure the Server per the following steps:
 
 1. Within the Azure Multi-Factor Authentication Server, click the **IIS Authentication** icon in the left menu.
 2. Click the **HTTP** tab.
 3. Click **Add**.
 4. In the Add Base URL dialogue box, enter the URL for the AD FS website where HTTP authentication is performed (like `https://sso.domain.com/adfs/ls/auth/integrated`) into the Base URL field. Then, enter an Application name (optional). The Application name appears in Azure Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication messages.
 5. If desired, adjust the Idle timeout and Maximum session times.
-6. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users have not yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
+6. Check the **Require Azure Multi-Factor Authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
 7. Check the cookie cache box if desired.
 
    ![AD FS 2.0 Direct without a proxy](./media/howto-mfaserver-adfs-2/noproxy.png)
@@ -115,7 +115,7 @@ You can secure AD FS when the AD FS proxy is not used. Install the Azure Multi-F
 
 Azure Multi-Factor Authentication is now securing AD FS.
 
-Ensure that users have been imported from Active Directory into the Server. See the Trusted IPs section if you would like to allow internal IP addresses so that two-step verification is not required when signing in to the website from those locations.
+Ensure that users have been imported from Active Directory into the Server. See the Trusted IPs section if you would like to allow internal IP addresses so that two-step verification isn't required when signing in to the website from those locations.
 
 ## Trusted IPs
 

articles/active-directory/authentication/howto-mfaserver-deploy-ha.md

@@ -6,7 +6,7 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 11/21/2019
+ms.date: 10/29/2022
 
 ms.author: justinha
 author: justinha
@@ -17,14 +17,13 @@ ms.collection: M365-identity-device-management
 ---
 # Configure Azure Multi-Factor Authentication Server for high availability
 
-To achieve high-availability with your Azure Server MFA deployment, you need to deploy multiple MFA servers. This section provides information on a load-balanced design to achieve your high availability targets in you Azure MFS Server deployment.
+To achieve high-availability with your Azure Server MFA deployment, you need to deploy multiple MFA servers. This section provides information on a load-balanced design to achieve your high availability targets in your Azure MFS Server deployment.
 
 > [!IMPORTANT]
-> As of July 1, 2019, Microsoft no longer offers MFA Server for new deployments. New customers that want to require multi-factor authentication (MFA) during sign-in events should use cloud-based Azure AD Multi-Factor Authentication.
+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication (MFA) requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their users’ authentication data](how-to-migrate-mfa-server-to-azure-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).
 >
 > To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication](tutorial-enable-azure-mfa.md).
 >
-> Existing customers that activated MFA Server before July 1, 2019 can download the latest version, future updates, and generate activation credentials as usual.
 
 ## MFA Server overview
 
@@ -40,14 +39,14 @@ Both MFA primary and subordinate MFA Servers communicate with the MFA Service wh
 
 After successful authentication with AD, the MFA Server will communicate with the MFA Service. The MFA Server waits for notification from the MFA Service to allow or deny the user access to the application.
 
-If the MFA primary server goes offline, authentications can still be processed, but operations that require changes to the MFA database cannot be processed. (Examples include: the addition of users, self-service PIN changes, changing user information, or access to the user portal)
+If the MFA primary server goes offline, authentications can still be processed, but operations that require changes to the MFA database can't be processed. (Examples include: the addition of users, self-service PIN changes, changing user information, or access to the user portal)
 
 ## Deployment
 
 Consider the following important points for load balancing Azure MFA Server and its related components.
 
 * **Using RADIUS standard to achieve high availability**. If you are using Azure MFA Servers as RADIUS servers, you can potentially configure one MFA Server as a primary RADIUS authentication target and other Azure MFA Servers as secondary authentication targets. However, this method to achieve high availability may not be practical because you must wait for a time-out period to occur when authentication fails on the primary authentication target before you can be authenticated against the secondary authentication target. It is more efficient to load balance the RADIUS traffic between the RADIUS client and the RADIUS Servers (in this case, the Azure MFA Servers acting as RADIUS servers) so that you can configure the RADIUS clients with a single URL that they can point to.
-* **Need to manually promote MFA subordinates**. If the primary Azure MFA server goes offline, the secondary Azure MFA Servers continue to process MFA requests. However, until a primary MFA server is available, admins can not add users or modify MFA settings, and users can not make changes using the user portal. Promoting an MFA subordinate to the primary role is always a manual process.
+* **Need to manually promote MFA subordinates**. If the primary Azure MFA server goes offline, the secondary Azure MFA Servers continue to process MFA requests. However, until a primary MFA server is available, admins can't add users or modify MFA settings, and users can't make changes using the user portal. Promoting an MFA subordinate to the primary role is always a manual process.
 * **Separability of components**. The Azure MFA Server comprises several components that can be installed on the same Windows Server instance or on different instances. These components include the User Portal, Mobile App Web Service, and the ADFS adapter (agent). This separability makes it possible to use the Web Application Proxy to publish the User Portal and Mobile App Web Server from the perimeter network. Such a configuration adds to the overall security of your design, as shown in the following diagram. The MFA User Portal and Mobile App Web Server may also be deployed in HA load-balanced configurations.
 
    ![MFA Server with a Perimeter Network](./media/howto-mfaserver-deploy-ha/mfasecurity.png)
@@ -67,7 +66,7 @@ Note the following items for the correspondingly numbered area of the preceding
    ![Azure MFA Server - App server HA](./media/howto-mfaserver-deploy-ha/mfaapp.png)
 
    > [!NOTE]
-   > Because RPC uses dynamic ports, it is not recommended to open firewalls up to the range of dynamic ports that RPC can potentially use. If you have a firewall **between** your MFA application servers, you should configure the MFA Server to communicate on a static port for the replication traffic between subordinate and primary servers and open that port on your firewall. You can force the static port by creating a DWORD registry value at ```HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactor``` called ```Pfsvc_ncan_ip_tcp_port``` and setting the value to an available static port. Connections are always initiated by the subordinate MFA Servers to the primary, the static port is only required on the primary, but since you can promote a subordinate to be the primary at any time, you should set the static port on all MFA Servers.
+   > Because RPC uses dynamic ports, it isn't recommended to open firewalls up to the range of dynamic ports that RPC can potentially use. If you have a firewall **between** your MFA application servers, you should configure the MFA Server to communicate on a static port for the replication traffic between subordinate and primary servers and open that port on your firewall. You can force the static port by creating a DWORD registry value at ```HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactor``` called ```Pfsvc_ncan_ip_tcp_port``` and setting the value to an available static port. Connections are always initiated by the subordinate MFA Servers to the primary, the static port is only required on the primary, but since you can promote a subordinate to be the primary at any time, you should set the static port on all MFA Servers.
 
 2. The two User Portal/MFA Mobile App servers (MFA-UP-MAS1 and MFA-UP-MAS2) are load balanced in a **stateful** configuration (mfa.contoso.com). Recall that sticky sessions are a requirement for load balancing the MFA User Portal and Mobile App Service.
    ![Azure MFA Server - User Portal and Mobile App Service HA](./media/howto-mfaserver-deploy-ha/mfaportal.png)