Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into heidist-dc

Author: HeidiSteen

.openpublishing.redirection.json

@@ -38441,6 +38441,26 @@
       "redirect_url": "/azure/iot-develop/quickstart-devkit-mxchip-az3166-iot-hub",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/iot-hub/quickstart-control-device-dotnet.md",
+      "redirect_url": "/azure/iot-hub/quickstart-control-device?pivots=programming-language-csharp",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/iot-hub/quickstart-control-device-node.md",
+      "redirect_url": "/azure/iot-hub/quickstart-control-device?pivots=programming-language-nodejs",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/iot-hub/quickstart-control-device-python.md",
+      "redirect_url": "/azure/iot-hub/quickstart-control-device?pivots=programming-language-python",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/iot-hub/quickstart-control-device-java.md",
+      "redirect_url": "/azure/iot-hub/quickstart-control-device?pivots=programming-language-java",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/iot-suite/iot-suite-connected-factory-publisher.md",
       "redirect_url": "https://github.com/Azure/iot-edge-opc-publisher/blob/master/README.md",

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

@@ -65,8 +65,8 @@ The following table outlines when an authentication method can be used during a
 | Windows Hello for Business     | Yes                    | MFA                       |
 | Microsoft Authenticator app    | Yes                    | MFA and SSPR              |
 | FIDO2 security key             | Yes                    | MFA                       |
-| OATH hardware tokens (preview) | No                     | MFA                       |
-| OATH software tokens           | No                     | MFA                       |
+| OATH hardware tokens (preview) | No                     | MFA and SSPR              |
+| OATH software tokens           | No                     | MFA and SSPR              |
 | SMS                            | Yes                    | MFA and SSPR              |
 | Voice call                     | No                     | MFA and SSPR              |
 | Password                       | Yes                    |                           |

articles/active-directory/authentication/concept-authentication-oath-tokens.md

@@ -30,7 +30,7 @@ Some OATH TOTP hardware tokens are programmable, meaning they don't come with a
 
 ## OATH hardware tokens (Preview)
 
-Azure AD supports the use of OATH-TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. Customers can purchase these tokens from the vendor of their choice. For a list of security token providers that are compatible with passwordless authentication, see [FIDO2 security key providers](concept-authentication-passwordless.md#fido2-security-key-providers).
+Azure AD supports the use of OATH-TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. Customers can purchase these tokens from the vendor of their choice. 
 
 OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token. These keys must be input into Azure AD as described in the following steps. Secret keys are limited to 128 characters, which may not be compatible with all tokens. The secret key can only contain the characters *a-z* or *A-Z* and digits *2-7*, and must be encoded in *Base32*.
 
@@ -61,3 +61,4 @@ Users may have a combination of up to five OATH hardware tokens or authenticator
 ## Next steps
 
 Learn more about configuring authentication methods using the [Microsoft Graph REST API](/graph/api/resources/authenticationmethods-overview).
+Learn about [FIDO2 security key providers](concept-authentication-passwordless.md#fido2-security-key-providers) that are compatible with passwordless authentication.

articles/active-directory/enterprise-users/groups-self-service-management.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: enterprise-users
 ms.workload: identity
 ms.topic: how-to
-ms.date: 06/23/2021
+ms.date: 07/27/2021
 ms.author: curtand
 ms.reviewer: krbain
 ms.custom: "it-pro;seo-update-azuread-jan"
@@ -71,6 +71,9 @@ The group settings enable to control who can create security and Microsoft 365 g
 
 ![Azure Active Directory security groups setting change.](./media/groups-self-service-management/security-groups-setting.png)
 
+> [!NOTE]
+> The behavior of these settings recently changed. Make sure these settings are configured for your organization. For more information, see [Why were the group settings changed?](#why-were-the-group-settings-changed).
+
  The following table helps you decide which values to choose.
 
 | Setting | Value | Effect on your tenant |
@@ -86,6 +89,12 @@ Here are some additional details about these group settings.
 - If you want to enable some, but not all, of your users to create groups, you can assign those users a role that can create groups, such as [Groups Administrator](../roles/permissions-reference.md#groups-administrator).
 - These settings are for users and don't impact service principals. For example, if you have a service principal with permissions to create groups, even if you set these settings to **No**, the service principal will still be able to create groups. 
 
+### Why were the group settings changed?
+
+The previous implementation of the group settings were named **Users can create security groups in Azure portals** and **Users can create Microsoft 365 groups in Azure portals**. The previous settings only controlled group creation in Azure portals and did not apply to API or PowerShell. The new settings control group creation in Azure portals, as well as, API and PowerShell. The new settings are more secure.
+
+The default values for the new settings have been set to your previous API or PowerShell values. There is a possibility that the default values for the new settings are different than your previous values that controlled only the Azure portal behavior. Starting in May 2021, there was a transition period of a few weeks where you could select your preferred default value before the new settings took effect. Now that the new settings have taken effect, you are required to verify the new settings are configured for your organization.
+
 ## Next steps
 
 These articles provide additional information on Azure Active Directory.

articles/active-directory/governance/entitlement-management-access-package-incompatible.md

@@ -22,16 +22,23 @@ ms.collection: M365-identity-device-management
 ---
 # Configure separation of duties checks for an access package in Azure AD entitlement management (Preview)
 
-In each of an access package's policies, you can specify who is able to request that access package, such as all member users in your organization, or only users who are already a member of a particular group. However, you may wish to further restrict access, in order to avoid a user from obtaining excessive access.
+In Azure AD entitlement management, you can configure multiple policies, with different settings for each user community that will need access through an access package.  For example, employees might only need manager approval to get access to certain apps, but guests coming in from other organizations may require both a sponsor and a resource team departmental manager to approve. In a policy for users already in the directory, you can specify a particular group of users for who can request access. However, you may have a requirement to avoid a user obtaining excessive access.  To meet this requirement, you will want to further restrict who can request access, based on the access the requestor already has.
 
-With the separation of duties settings on an access package, you can configure that a user cannot request an access package, if they already have an assignment to another access package, or are a member of a group.
+With the separation of duties settings on an access package, you can configure that a user who is a member of a group or who already has an assignment to one access package cannot request an additional access package.
 
-For example, you have an access package, *Marketing Campaign*, that people across your organization and other organizations can request access to, to work with your organization's marketing department on that marketing campaign. Since employees in the marketing department should already have access to that marketing campaign material, you wouldn't want employees in the marketing department to request access to that access package.  Or, you may already have a dynamic group, *Marketing department employees*, with all of the marketing employees in it. You could indicate that the access package is incompatible with the membership of that dynamic group. Then, if a marketing department employee is looking for an access package to request, they couldn't request access to the *Marketing campaign* access package.
+![myaccess experience for attempting to request incompatible access](./media/entitlement-management-access-package-incompatible/request-prevented.png)
+
+
+## Scenarios for separation of duties checks
+
+For example, you have an access package, *Marketing Campaign*, that people across your organization and other organizations can request access to, to work with your organization's marketing department while that campaign is going on. Since employees in the marketing department should already have access to that marketing campaign material, you don't want employees in the marketing department to request access to that access package.  Or, you may already have a dynamic group, *Marketing department employees*, with all of the marketing employees in it. You could indicate that the access package is incompatible with the membership of that dynamic group. Then, if a marketing department employee is looking for an access package to request, they couldn't request access to the *Marketing campaign* access package.
 
 Similarly, you may have an application with two roles - **Western Sales** and **Eastern Sales** - and want to ensure that a user can only have one sales territory at a time.  If you have two access packages, one access package **Western Territory** giving the **Western Sales** role and the other access package **Eastern Territory** giving the **Eastern Sales** role, then you can configure
  - the **Western Territory** access package has the **Eastern Territory** package as incompatible, and
  - the **Eastern Territory** access package has the **Western Territory** package as incompatible.
 
+If you’ve been using Microsoft Identity Manager or other on-premises identity management systems for automating access for on-premises apps, then you can integrate these systems with Azure AD entitlement management as well.  If you will be controlling access to Azure AD-integrated apps through entitlement management, and want to prevent users from having incompatible access, you can configure that an access package is incompatible with a group. That could be a group, which your on-premises identity management system sends into Azure AD through Azure AD Connect. This check ensures a user will be unable to request an access package, if that access package would give access that's incompatible with access the user has in on-premises apps.
+
 ## Prerequisites
 
 To use Azure AD entitlement management and assign users to access packages, you must have one of the following licenses:
@@ -55,8 +62,17 @@ Follow these steps to change the list of incompatible groups or other access pac
 
 1.  If you wish to prevent users who have another access package assignment already from requesting this access package, click on **Add access package** and select the access package that the user would already be assigned.
 
+
+    ![configuration of incompatible access packages](./media/entitlement-management-access-package-incompatible/select-incompatible-ap.png)
+
+
 1.  If you wish to prevent users who have an existing group membership from requesting this access package, then click on **Add group** and select the group that the user would already be in.
 
+### Configure incompatible access packages programmatically
+
+You can also configure the groups and other access packages that are incompatible with access package using Microsoft Graph.  A user in an appropriate role with an application that has the delegated `EntitlementManagement.ReadWrite.All` permission, or an application with that application permission, can call the API to add, remove, and list the incompatible groups and access packages [of an access package](/graph/api/resources/accesspackage?view=graph-rest-beta&preserve-view=true).
+
+
 ## View other access packages that are configured as incompatible with this one
 
 **Prerequisite role**: Global administrator, Identity Governance administrator, User administrator, Catalog owner or Access package manager
@@ -73,6 +89,21 @@ Follow these steps to view the list of other access packages that have indicated
 
 1. Click on **Incompatible With**.
 
+## Monitor and report on access assignments
+
+You can use Azure Monitor workbooks to get insights on how users have been receiving their access.
+
+1. Configure Azure AD to [send audit events to Azure Monitor](entitlement-management-logs-and-reporting.md).
+
+1. The workbook named *Access Package Activity* displays each event related to a particular access package.
+
+    ![View access package events](./media/entitlement-management-logs-and-reporting/view-events-access-package.png)
+
+1. To see if there have been changes to application role assignments for an application that were not created due to access package assignments, then you can select the workbook named *Application role assignment activity*.  If you select to omit entitlement activity, then only changes to application roles that were not made by entitlement management are shown. For example, you would see a row if a global administrator had directly assigned a user to an application role.
+
+    ![View app role assignments](./media/entitlement-management-access-package-incompatible/workbook-ara.png)
+
+
 ## Next steps
 
 - [View, add, and remove assignments for an access package](entitlement-management-access-package-assignments.md)

articles/active-directory/governance/entitlement-management-access-package-resources.md

@@ -107,7 +107,7 @@ For more information, see [Compare groups](/office365/admin/create-groups/compar
 
 ## Add an application resource role
 
-You can have Azure AD automatically assign users access to an Azure AD enterprise application, including both SaaS applications and your organization's applications federated to Azure AD, when a user is assigned an access package. For applications that integrate with Azure AD through federated single sign-on, Azure AD will issue federation tokens for users assigned to the application.
+You can have Azure AD automatically assign users access to an Azure AD enterprise application, including both SaaS applications and your organization's applications integrated with Azure AD, when a user is assigned an access package. For applications that integrate with Azure AD through federated single sign-on, Azure AD will issue federation tokens for users assigned to the application.
 
 Applications can have multiple roles. When adding an application to an access package, if that application has more than one role, you will need to specify the appropriate role for those users. If you are developing applications, you can read more about how those roles are added to your applications in [How to: Configure the role claim issued in the SAML token for enterprise applications](../develop/active-directory-enterprise-app-role-management.md).
 

articles/active-directory/governance/entitlement-management-catalog-create.md

@@ -69,7 +69,11 @@ $catalog = New-MgEntitlementManagementAccessPackageCatalog -DisplayName "Marketi
 
 ## Add resources to a catalog
 
-To include resources in an access package, the resources must exist in a catalog. The types of resources you can add are groups, applications, and SharePoint Online sites. The groups can be cloud-created Microsoft 365 Groups or cloud-created Azure AD security groups. The applications can be Azure AD enterprise applications, including both SaaS applications and your own applications federated to Azure AD. The sites can be SharePoint Online sites or SharePoint Online site collections.
+To include resources in an access package, the resources must exist in a catalog. The types of resources you can add are groups, applications, and SharePoint Online sites.
+
+* The groups can be cloud-created Microsoft 365 Groups or cloud-created Azure AD security groups.  Groups that originate in an on-premises Active Directory cannot be assigned as resources because their owner or member attributes cannot be changed in Azure AD.   Groups that originate in Exchange Online as Distribution groups cannot be modified in Azure AD either.
+* The applications can be Azure AD enterprise applications, including both SaaS applications and your own applications integrated with Azure AD. For more information on selecting appropriate resources for applications with multiple roles, see [add resource roles](entitlement-management-access-package-resources.md#add-resource-roles).
+* The sites can be SharePoint Online sites or SharePoint Online site collections.
 
 **Prerequisite role:** See [Required roles to add resources to a catalog](entitlement-management-delegate.md#required-roles-to-add-resources-to-a-catalog)