Merge pull request #161929 from MicrosoftDocs/master

6/10 PM Publish

Author: huypub

.openpublishing.publish.config.json

@@ -231,6 +231,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "azure-functions-python-worker-extension",
+      "url": "https://github.com/Azure-Samples/python-worker-extension-timer",
+      "branch": "master",
+      "branch_mapping": {}
+    },    
     {
       "path_to_root": "functions-openapi-turbine-repair",
       "url": "https://github.com/Azure-Samples/functions-openapi-turbine-repair",

.openpublishing.redirection.json

@@ -67089,16 +67089,6 @@
       "source_path_from_root": "/articles/iot-develop/quickstart-device-development.md",
       "redirect_url": "/azure/iot-develop/",
       "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/machine-learning/team-data-science-process/move-data-to-azure-blob-using-azure-storage-explorer.md",
-      "redirect_url": "/azure/vs-azure-tools-storage-manage-with-storage-explorer",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/machine-learning/team-data-science-process/move-data-to-azure-blob-using-ssis.md",
-      "redirect_url": "/sql/integration-services/azure-feature-pack-for-integration-services-ssis",
-      "redirect_document_id": false
     }
   ]
 }

articles/active-directory-b2c/identity-provider-azure-ad-multi-tenant.md

@@ -145,7 +145,7 @@ You can define Azure AD as a claims provider by adding Azure AD to the **ClaimsP
     ```
 
 1. Under the **ClaimsProvider** element, update the value for **Domain** to a unique value that can be used to distinguish it from other identity providers.
-1. Under the **TechnicalProfile** element, update the value for **DisplayName**, for example, `Contoso Employee`. This value is displayed on the sign-in button on your sign-in page.
+1. Under the **TechnicalProfile** element, update the value for **DisplayName**, for example, `Multi-Tenant AAD`. This value is displayed on the sign-in button on your sign-in page.
 1. Set **client_id** to the application ID of the Azure AD multi-tenant application that you registered earlier.
 1. Under **CryptographicKeys**, update the value of **StorageReferenceId** to the name of the policy key that created earlier. For example, `B2C_1A_AADAppSecret`.
 

articles/active-directory/authentication/concept-authentication-passwordless.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 05/07/2021
+ms.date: 06/10/2021
 
 ms.author: justinha
 author: justinha
@@ -107,14 +107,21 @@ The following process is used when a user signs in with a FIDO2 security key:
 
 While there are many keys that are FIDO2 certified by the FIDO Alliance, Microsoft requires some optional extensions of the FIDO2 Client-to-Authenticator Protocol (CTAP) specification to be implemented by the vendor to ensure maximum security and the best experience.
 
-A security key **MUST** implement the following features and extensions from the FIDO2 CTAP protocol to be Microsoft-compatible:
+A security key **must** implement the following features and extensions from the FIDO2 CTAP protocol to be Microsoft-compatible. For more information, see the [Client to Authenticator Protocol](https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html).
 
 | # | Feature / Extension trust | Why is this feature or extension required? |
 | --- | --- | --- |
-| 1 | Resident key | This feature enables the security key to be portable, where your credential is stored on the security key. |
-| 2 | Client pin | This feature enables you to protect your credentials with a second factor and applies to security keys that do not have a user interface. |
+| 1 | Resident/Discoverable key | This feature enables the security key to be portable, where your credential is stored on the security key and is discoverable which makes usernameless flows possible. |
+| 2 | Client pin | This feature enables you to protect your credentials with a second factor and applies to security keys that do not have a user interface.<br>Both [PIN protocol 1](https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#pinProto1) and [PIN protocol 2](https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#pinProto2) **must** be implemented. |
 | 3 | hmac-secret | This extension ensures you can sign in to your device when it's off-line or in airplane mode. |
 | 4 | Multiple accounts per RP | This feature ensures you can use the same security key across multiple services like Microsoft Account and Azure Active Directory. |
+| 5 | Credential Management    | This feature allows users to manage their credentials on security keys on platforms and applies to security keys that do not have this capability built-in.  |
+| 6 | Bio Enrollment           | This feature allows users to enroll their biometrics on their authenticators and applies to security keys that do not have this capability built in.<br> Authenticator **must** implement [authenicatorBioEnrollment](https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#authenticatorBioEnrollment) command for this feature. Authenticator vendors are highly encouraged to implement [userVerificationMgmtPreview](https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#prototypeAuthenticatorBioEnrollment) command also so that users can enroll bio templates it on all previous OS versions. |
+| 7 | pinUvAuthToken           | This feature allows platform to have auth tokens using PIN or BIO match which helps in better user experience when multiple credentials are present on the authenticator.  |
+| 8 | forcePinChange           | This feature allows enterprises to ask users to change their PIN in remote deployments.  |
+| 9 | setMinPINLength          | This feature allows enterprises to have custom minimum PIN length for their users. Authenticator MUST implement minPinLength extension also.  |
+| 10 | alwaysUV                | This feature allows enterprises or users to always require user verification to use this security key. Authenticator MUST implement toggleAlwaysUv subcommand.  |
+| 11 | credBlob                | This extension allows websites to store small information along with the security key.  |
 
 ### FIDO2 security key providers
 

articles/active-directory/authentication/howto-authentication-sms-signin.md

@@ -35,14 +35,15 @@ To complete this article, you need the following resources and privileges:
     * [Enterprise Mobility + Security (EMS) E3 or E5][ems-licensing] or [Microsoft 365 (M365) E3 or E5][m365-licensing]
     * [Office 365 F3][o365-f3]
 
-## Limitations
+## Known issues
 
-The following limitations apply to SMS-based authentication:
+Here are some known issues:
 
 * SMS-based authentication isn't currently compatible with Azure AD Multi-Factor Authentication.
 * Except for Teams, SMS-based authentication isn't compatible with native Office applications.
 * SMS-based authentication isn't recommended for B2B accounts.
 * Federated users won't authenticate in the home tenant. They only authenticate in the cloud.
+* If a user's default sign-in method is a text or call to your phone number, then the SMS code or voice call is sent automatically during multifactor authentication. As of June 2021, some apps will ask users to choose **Text** or **Call** first. This option prevents sending too many security codes for different apps. If the default sign-in method is the Microsoft Authenticator app ([which we highly recommend](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752)), then the app notification is sent automatically.
 
 ## Enable the SMS-based authentication method
 

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -83,6 +83,7 @@ This setting applies to the following iOS and Android apps:
 - Microsoft Invoicing
 - Microsoft Kaizala
 - Microsoft Launcher
+- Microsoft Lists
 - Microsoft Office
 - Microsoft OneDrive
 - Microsoft OneNote

articles/active-directory/develop/active-directory-claims-mapping.md

@@ -1,7 +1,7 @@
 ---
 title: Customize Azure AD tenant app claims (PowerShell)
 titleSuffix: Microsoft identity platform
-description: This page describes Azure Active Directory claims mapping.
+description: Learn how to customize claims emitted in tokens for an application in a specific Azure Active Directory tenant.
 services: active-directory
 author: rwike77
 manager: CelesteDG
@@ -10,32 +10,34 @@ ms.subservice: develop
 ms.custom: aaddev
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/25/2020
+ms.date: 06/10/2021
 ms.author: ryanwi
 ms.reviewer: paulgarn, hirsin, jeedes, luleon
 ---
 
-# How to: Customize claims emitted in tokens for a specific app in a tenant (Preview)
+# Customize claims emitted in tokens for a specific app in a tenant
 
-> [!NOTE]
-> This feature replaces and supersedes the [claims customization](active-directory-saml-claims-customization.md) offered through the portal today. On the same application, if you customize claims using the portal in addition to the Graph/PowerShell method detailed in this document, tokens issued for that application will ignore the configuration in the portal. Configurations made through the methods detailed in this document will not be reflected in the portal.
+Claims customization is used by tenant admins to customize the claims emitted in tokens for a specific application in their tenant. You can use claims-mapping policies to:
 
-> [!NOTE]
-> This capability currently is in public preview. Be prepared to revert or remove any changes. The feature is available in any Azure Active Directory (Azure AD) subscription during public preview. However, when the feature becomes generally available, some aspects of the feature might require an Azure AD premium subscription. This feature supports configuring claim mapping policies for WS-Fed, SAML, OAuth, and OpenID Connect protocols.
+- select which claims are included in tokens.
+- create claim types that do not already exist.
+- choose or change the source of data emitted in specific claims.
 
-This feature is used by tenant admins to customize the claims emitted in tokens for a specific application in their tenant. You can use claims-mapping policies to:
+Claims customization supports configuring claim-mapping policies for the WS-Fed, SAML, OAuth, and OpenID Connect protocols.
 
-- Select which claims are included in tokens.
-- Create claim types that do not already exist.
-- Choose or change the source of data emitted in specific claims.
+> [!NOTE]
+> This feature replaces and supersedes the [claims customization](active-directory-saml-claims-customization.md) offered through the Azure portal. On the same application, if you customize claims using the portal in addition to the Microsoft Graph/PowerShell method detailed in this document, tokens issued for that application will ignore the configuration in the portal. Configurations made through the methods detailed in this document will not be reflected in the portal.
 
-In this article, we walk through a few common scenarios that can help you grasp how to use the [claims mapping policy type](reference-claims-mapping-policy-type.md).
+In this article, we walk through a few common scenarios that can help you grasp how to use the [claims-mapping policy type](reference-claims-mapping-policy-type.md).
 
-When creating a claims mapping policy, you can also emit a claim from a directory schema extension attribute in tokens. Use *ExtensionID* for the extension attribute instead of *ID* in the `ClaimsSchema` element.  For more info on extension attributes, see [Using directory schema extension attributes](active-directory-schema-extensions.md).
+When creating a claims-mapping policy, you can also emit a claim from a directory schema extension attribute in tokens. Use *ExtensionID* for the extension attribute instead of *ID* in the `ClaimsSchema` element.  For more info on extension attributes, see [Using directory schema extension attributes](active-directory-schema-extensions.md).
 
 ## Prerequisites
 
-In the following examples, you create, update, link, and delete policies for service principals. Claims mapping policies can only be assigned to service principal objects. If you are new to Azure AD, we recommend that you [learn about how to get an Azure AD tenant](quickstart-create-new-tenant.md) before you proceed with these examples.
+In the following examples, you create, update, link, and delete policies for service principals. claims-mapping policies can only be assigned to service principal objects. If you are new to Azure AD, we recommend that you [learn about how to get an Azure AD tenant](quickstart-create-new-tenant.md) before you proceed with these examples.
+
+> [!NOTE]
+> The [Azure AD PowerShell Module public preview release](https://www.powershellgallery.com/packages/AzureADPreview) is required to configure claims-mapping policies. The PowerShell module is in preview, be prepared to revert or remove any changes. 
 
 To get started, do the following steps:
 
@@ -55,7 +57,7 @@ To get started, do the following steps:
 
 In this example, you create a policy that removes the [basic claim set](reference-claims-mapping-policy-type.md#claim-sets) from tokens issued to linked service principals.
 
-1. Create a claims mapping policy. This policy, linked to specific service principals, removes the basic claim set from tokens.
+1. Create a claims-mapping policy. This policy, linked to specific service principals, removes the basic claim set from tokens.
    1. To create the policy, run this command:
 
       ``` powershell
@@ -78,7 +80,7 @@ In this example, you create a policy that removes the [basic claim set](referenc
 
 In this example, you create a policy that adds the EmployeeID and TenantCountry to tokens issued to linked service principals. The EmployeeID is emitted as the name claim type in both SAML tokens and JWTs. The TenantCountry is emitted as the country/region claim type in both SAML tokens and JWTs. In this example, we continue to include the basic claims set in the tokens.
 
-1. Create a claims mapping policy. This policy, linked to specific service principals, adds the EmployeeID and TenantCountry claims to tokens.
+1. Create a claims-mapping policy. This policy, linked to specific service principals, adds the EmployeeID and TenantCountry claims to tokens.
    1. To create the policy, run the following command:
 
       ``` powershell
@@ -102,7 +104,7 @@ In this example, you create a policy that adds the EmployeeID and TenantCountry
 
 In this example, you create a policy that emits a custom claim "JoinedData" to JWTs issued to linked service principals. This claim contains a value created by joining the data stored in the extensionattribute1 attribute on the user object with ".sandbox". In this example, we exclude the basic claims set in the tokens.
 
-1. Create a claims mapping policy. This policy, linked to specific service principals, adds the EmployeeID and TenantCountry claims to tokens.
+1. Create a claims-mapping policy. This policy, linked to specific service principals, adds the EmployeeID and TenantCountry claims to tokens.
    1. To create the policy, run the following command:
 
       ``` powershell
@@ -124,7 +126,7 @@ In this example, you create a policy that emits a custom claim "JoinedData" to J
 
 ## Security considerations
 
-Applications that receive tokens rely on the fact that the claim values are authoritatively issued by Azure AD and cannot be tampered with. However, when you modify the token contents via claims mapping policies, these assumptions may no longer be correct. Applications must explicitly acknowledge that tokens have been modified by the creator of the claims mapping policy to protect themselves from claims mapping policies created by malicious actors. This can be done in the following ways:
+Applications that receive tokens rely on the fact that the claim values are authoritatively issued by Azure AD and cannot be tampered with. However, when you modify the token contents through claims-mapping policies, these assumptions may no longer be correct. Applications must explicitly acknowledge that tokens have been modified by the creator of the claims-mapping policy to protect themselves from claims-mapping policies created by malicious actors. This can be done in the following ways:
 
 - Configure a custom signing key
 - Update the application manifest to accept mapped claims.
@@ -151,6 +153,6 @@ If you're not using a verified domain, Azure AD will return an `AADSTS501461` er
 
 ## Next steps
 
-- Read the [claims mapping policy type](reference-claims-mapping-policy-type.md) reference article to learn more.
+- Read the [claims-mapping policy type](reference-claims-mapping-policy-type.md) reference article to learn more.
 - To learn how to customize claims issued in the SAML token through the Azure portal, see [How to: Customize claims issued in the SAML token for enterprise applications](active-directory-saml-claims-customization.md)
 - To learn more about extension attributes, see [Using directory schema extension attributes in claims](active-directory-schema-extensions.md).

articles/active-directory/enterprise-users/groups-dynamic-membership.md

@@ -361,7 +361,9 @@ An example of a rule that uses a custom extension property is:
 user.extension_c272a57b722d4eb29bfe327874ae79cb_OfficeNumber -eq "123"
 ```
 
-The custom property name can be found in the directory by querying a user's property using Graph Explorer and searching for the property name. Also, you can now select **Get custom extension properties** link in the dynamic user group rule builder to enter a unique app ID and receive the full list of custom extension properties to use when creating a dynamic membership rule. This list can also be refreshed to get any new custom extension properties for that app.
+The custom property name can be found in the directory by querying a user's property using Graph Explorer and searching for the property name. Also, you can now select **Get custom extension properties** link in the dynamic user group rule builder to enter a unique app ID and receive the full list of custom extension properties to use when creating a dynamic membership rule. This list can also be refreshed to get any new custom extension properties for that app. 
+
+For more information, see [Use the attributes in dynamic groups](../hybrid/how-to-connect-sync-feature-directory-extensions.md#use-the-attributes-in-dynamic-groups) in the article [Azure AD Connect sync: Directory extensions](../hybrid/how-to-connect-sync-feature-directory-extensions.md).
 
 ## Rules for devices
 

articles/active-directory/hybrid/reference-connect-version-history.md

@@ -87,12 +87,13 @@ Please follow this link to read more about [auto upgrade](how-to-connect-install
    - Added member attribute to the 'Out to AD - Group SOAInAAD - Exchange' rule to limit members in written back groups to 50k
  - Updated Sync Rules to support Group Writeback v2
    -If the “In from AAD - Group SOAInAAD” rule is cloned and AADConnect is upgraded.
-     -The updated rule will be disabled by default and so the targetWritebackType will be null.
+     - The updated rule will be disabled by default and so the targetWritebackType will be null.
      - AADConnect will writeback all Cloud Groups (including Azure Active Directory Security Groups enabled for writeback) as Distribution Groups.
    -If the “Out to AD - Group SOAInAAD” rule is cloned and AADConnect is upgraded.
      - The updated rule will be disabled by default. However, a new sync rule “Out to AD - Group SOAInAAD - Exchange” which is added will be enabled.
      - Depending on the Cloned Custom Sync Rule's precedence, AADConnect will flow the Mail and Exchange attributes.
      - If the Cloned Custom Sync Rule does not flow some Mail and Exchange attributes, then new Exchange Sync Rule will add those attributes.
+     - Note that Group Writeback V2 is in private preview at this moment and not publicly available.
  - Added support for [Selective Password hash Synchronization](./how-to-connect-selective-password-hash-synchronization.md)
  - Added the new [Single Object Sync cmdlet](./how-to-connect-single-object-sync.md). Use this cmdlet to troubleshoot your Azure AD Connect sync configuration. 
  -  Azure AD Connect now supports the Hybrid Identity Administrator role for configuring the service.