Merge pull request #190849 from MicrosoftDocs/main

3/07 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -683,6 +683,11 @@
       "redirect_url": "/azure/frontdoor/troubleshoot-issues",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/frontdoor/concept-rules-set-action.md",
+      "redirect_url": "/azure/frontdoor/front-door-rules-engine-actions",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/app-service-web/web-sites-dotnet-deploy-aspnet-mvc-app-membership-oauth-sql-database.md",
       "redirect_url": "/aspnet/core/security/authorization/secure-data",

articles/active-directory-b2c/partner-bindid.md

@@ -20,7 +20,7 @@ zone_pivot_groups: b2c-policy-type
 [!INCLUDE [active-directory-b2c-choose-user-flow-or-custom-policy](../../includes/active-directory-b2c-choose-user-flow-or-custom-policy.md)]
 
 
-In this sample tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [Transmit Security](https://www.transmitsecurity.com/bindid) passwordless authentication solution **BindID**. BindID is a passwordless authentication service that uses strong Fast Identity Online (FIDO2) biometric authentication for a reliable omni-channel authentication experience. The solution ensures a smooth login experience for all customers across every device and channel eliminating fraud, phishing, and credential reuse.
+In this sample tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with [Transmit Security](https://www.transmitsecurity.com/bindid) passwordless authentication solution **BindID**. BindID is a passwordless authentication service that uses strong Fast Identity Online (FIDO2) biometric authentication for a reliable omni-channel authentication experience. The solution ensures a smooth login experience for all customers across every device and channel eliminating fraud, phishing, and credential reuse.
 
 ## Scenario description
 
@@ -30,8 +30,8 @@ The following architecture diagram shows the implementation.
 
 |Step | Description |
 |:-----| :-----------|
-| 1. | User arrives at a login page. Users select sign-in/sign-up and enter username into the page.
-| 2. | Azure AD B2C redirects the user to BindID using an OpenID Connect (OIDC) request.
+| 1. | User attempts to log in to an Azure AD B2C application and is forwarded to Azure AD B2C’s combined sign-in and sign-up policy.
+| 2. | Azure AD B2C redirects the user to BindID using the OpenID Connect (OIDC) authorization code flow.
 | 3. | BindID authenticates the user using appless FIDO2 biometrics, such as fingerprint.
 | 4. | A decentralized authentication response is returned to BindID.  
 | 5. | The OIDC response is passed on to Azure AD B2C.
@@ -62,7 +62,7 @@ To get started, you'll need:
 
 ### Step 1 - Create an application registration in BindID
 
-From [Applications](https://admin.bindid-sandbox.io/console/#/applications) to configure your tenant application in BindID, the following information is needed
+For [Applications](https://admin.bindid-sandbox.io/console/#/applications) to configure your tenant application in BindID, the following information is needed
 
 | Property | Description |
 |:---------|:---------------------|
@@ -318,7 +318,7 @@ The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azur
 
 1. Open the Azure AD B2C tenant and under Policies select **Identity Experience Framework**.
 
-2. Click on your previously created **CustomSignUpSignIn** and select the settings:
+2. Select your previously created **CustomSignUpSignIn** and select the settings:
 
    a. **Application**: select the registered app (sample is JWT)
 

articles/active-directory/devices/howto-vm-sign-in-azure-ad-windows.md

@@ -20,7 +20,7 @@ ms.collection: M365-identity-device-management
 Organizations can now improve the security of Windows virtual machines (VMs) in Azure by integrating with Azure Active Directory (AD) authentication. You can now use Azure AD as a core authentication platform to RDP into a **Windows Server 2019 Datacenter edition** and later or **Windows 10 1809** and later. Additionally, you will be able to centrally control and enforce Azure RBAC and Conditional Access policies that allow or deny access to the VMs. This article shows you how to create and configure a Windows VM and login with Azure AD based authentication.
 
 There are many security benefits of using Azure AD based authentication to login to Windows VMs in Azure, including:
-- Use your corporate AD credentials to login to Windows VMs in Azure.
+- Use your corporate Azure AD credentials to login to Windows VMs in Azure.
 - Reduce your reliance on local administrator accounts, you do not need to worry about credential loss/theft, users configuring weak credentials etc.
 - Password complexity and password lifetime policies configured for your Azure AD directory help secure Windows VMs as well.
 - With Azure role-based access control (Azure RBAC), specify who can login to a VM as a regular user or with administrator privileges. When users join or leave your team, you can update the Azure RBAC policy for the VM to grant access as appropriate. When employees leave your organization and their user account is disabled or removed from Azure AD, they no longer have access to your resources.

articles/active-directory/hybrid/plan-connect-topologies.md

@@ -149,8 +149,8 @@ This topology implements the following use cases:
 *	Only one Azure AD tenant sync can be configured to write back to Active Directory for the same object. This includes device and group writeback as well as Hybrid Exchange configurations – these features can only be configured in one tenant. The only exception here is Password Writeback – see below.
 *	It is supported to configure Password Hash Sync from Active Directory to multiple Azure AD tenants for the same user object. If Password Hash Sync is enabled for a tenant, then Password Writeback may be enabled as well, and this can be done on multiple tenants: if the password is changed on one tenant, then password writeback will update it in Active Directory, and Password Hash Sync will update the password in the other tenants.
 *	It is not supported to add and verify the same custom domain name in more than one Azure AD tenant, even if these tenants are in different Azure environments.
-*	It is not supported to configure hybrid experiences such as Seamless SSO and Hybrid Azure AD Join on more than one tenant. Doing so would overwrite the configuration of the other tenant and would make it unusable. 
-*	You can synchronize device objects to more than one tenant but only one tenant can be configured to trust a device.
+*	It is not supported to configure hybrid experiences that utilize forest level configuration in AD, such as Seamless SSO and Hybrid Azure AD Join (non-targeted approach), with more than one tenant.  Doing so would overwrite the configuration of the other tenant, making it no longer usable.  You can find additional information in [Plan your hybrid Azure Active Directory join deployment](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan#hybrid-azure-ad-join-for-single-forest-multiple-azure-ad-tenants). 
+*	You can synchronize device objects to more than one tenant but a device can be Hybrid Azure AD Joined to only one tenant.
 * Each Azure AD Connect instance should be running on a domain-joined machine.
 
 >[!NOTE]

articles/aks/limit-egress-traffic.md

@@ -4,7 +4,7 @@ description: Learn what ports and addresses are required to control egress traff
 services: container-service
 ms.topic: article
 ms.author: jpalma
-ms.date: 01/12/2021
+ms.date: 03/7/2022
 author: palma21
 
 #Customer intent: As an cluster operator, I want to restrict egress traffic for nodes to only access defined ports and addresses and improve cluster security.
@@ -393,6 +393,10 @@ See [virtual network route table documentation](../virtual-network/virtual-netwo
 
 ### Adding firewall rules
 
+> [!NOTE]
+> For applications outside of the kube-system or gatekeeper-system namespaces that needs to talk to the API server, an additional network rule to allow TCP communication to port 443 for the API server IP in addition to adding application rule for fqdn-tag AzureKubernetesService is required.
+
+
 Below are three network rules you can use to configure on your firewall, you may need to adapt these rules based on your deployment. The first rule allows access to port 9000 via TCP. The second rule allows access to port 1194 and 123 via UDP (if you're deploying to Azure China 21Vianet, you might require [more](#azure-china-21vianet-required-network-rules)). Both these rules will only allow traffic destined to the Azure Region CIDR that we're using, in this case East US. 
 Finally, we'll add a third network rule opening port 123 to `ntp.ubuntu.com` FQDN via UDP (adding an FQDN as a network rule is one of the specific features of Azure Firewall, and you'll need to adapt it when using your own options).