You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: Secure access control using groups in Azure AD - Microsoft identity platform
3
+
description: Learn about how groups are used to securely control access to resources in Azure AD.
4
+
services: active-directory
5
+
author: chrischiedo
6
+
manager: CelesteDG
7
+
8
+
ms.service: active-directory
9
+
ms.subservice: develop
10
+
ms.topic: conceptual
11
+
ms.workload: identity
12
+
ms.date: 2/21/2022
13
+
ms.custom: template-concept
14
+
ms.author: cchiedo
15
+
ms.reviewer: jodah, marsma
16
+
17
+
# Customer intent: As a developer, I want to learn how to most securely use Azure AD groups to control access to resources.
18
+
---
19
+
20
+
# Secure access control using groups in Azure AD
21
+
22
+
Azure Active Directory (Azure AD) allows the use of groups to manage access to resources in an organization. You should use groups for access control when you want to manage and minimize access to applications. When groups are used, only members of those groups can access the resource. Using groups also allows you to benefit from several Azure AD group management features, such as attribute-based dynamic groups, external groups synced from on-premises Active Directory, and Administrator managed or self-service managed groups. To learn more about the benefits of groups for access control, see [manage access to an application](../manage-apps/what-is-access-management.md).
23
+
24
+
While developing an application, you can authorize access with the [groups claim](/graph/api/resources/application?view=graph-rest-1.0#properties&preserve-view=true). To learn more, see how to [configure group claims for applications with Azure AD](../hybrid/how-to-connect-fed-group-claims.md).
25
+
26
+
Today, many applications select a subset of groups with the *securityEnabled* flag set to *true* to avoid scale challenges, that is, to reduce the number of groups returned in the token. Setting the *securityEnabled* flag to be true for a group doesn't guarantee that the group is securely managed. Therefore, we suggest following the best practices described below:
27
+
28
+
29
+
## Best practices to mitigate risk
30
+
31
+
This table presents several security best practices for security groups and the potential security risks each practice mitigates.
32
+
33
+
|Security best practice |Security risk mitigated |
|**Ensure resource owner and group owner are the same principal**. Applications should build their own group management experience and create new groups to manage access. For example, an application can create groups with *Group. Create* permission and add itself as the owner of the group. This way the application has control over its groups without being over privileged to modify other groups in the tenant.|When group owners and resource owners are different users or entities, group owners can add users to the group who aren't supposed to get access to the resource and thus give access to the resource unintentionally.|
36
+
|**Build an implicit contract between resource owner(s) and group owner(s)**. The resource owner and the group owner should align on the group purpose, policies, and members that can be added to the group to get access to the resource. This level of trust is non-technical and relies on human or business contract.|When group owners and resource owners have different intentions, the group owner may add users to the group the resource owner didn't intend on giving access to. This can result in unnecessary and potentially risky access.|
37
+
|**Use private groups for access control**. Microsoft 365 groups are managed by the [visibility concept](/graph/api/resources/group?view=graph-rest-1.0#group-visibility-options&preserve-view=true). This property controls the join policy of the group and visibility of group resources. Security groups have join policies that either allow anyone to join or require owner approval. On-premises-synced groups can also be public or private. When they're used to give access to a resource in the cloud, users joining this group on-premises can get access to the cloud resource as well.|When you use a *Public* group for access control, any member can join the group and get access to the resource. When a *Public* group is used to give access to an external resource, the risk of elevation of privilege exists.|
38
+
|**Group nesting**. When you use a group for access control and it has other groups as its members, members of the subgroups can get access to the resource. In this case, there are multiple group owners - owners of the parent group and the subgroups.|Aligning with multiple group owners on the purpose of each group and how to add the right members to these groups is more complex and more prone to accidental grant of access. Therefore, you should limit the number of nested groups or don't use them at all if possible.|
39
+
40
+
## Next steps
41
+
42
+
For more information about groups in Azure AD, see the following:
43
+
44
+
-[Manage app and resource access using Azure Active Directory groups](../fundamentals/active-directory-manage-groups.md)
45
+
-[Access with Azure Active Directory groups](/azure/devops/organizations/accounts/manage-azure-active-directory-groups)
46
+
-[Restrict your Azure AD app to a set of users in an Azure AD tenant](./howto-restrict-your-app-to-a-set-of-users.md)
Copy file name to clipboardExpand all lines: articles/active-directory/hybrid/concept-azure-ad-connect-sync-architecture.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -170,6 +170,8 @@ When sync engine finds a staging object that matches by distinguished name but n
170
170
* If the object located in the connector space has no anchor, then sync engine removes this object from the connector space and marks the metaverse object it is linked to as **retry provisioning on next synchronization run**. Then it creates the new import object.
171
171
* If the object located in the connector space has an anchor, then sync engine assumes that this object has either been renamed or deleted in the connected directory. It assigns a temporary, new distinguished name for the connector space object so that it can stage the incoming object. The old object then becomes **transient**, waiting for the Connector to import the rename or deletion to resolve the situation.
172
172
173
+
Transient objects are not always a problem, and you might see them even in a healthy environment. With [Azure AD Connect sync V2 endpoint API](how-to-connect-sync-endpoint-api-v2.md), transient objects should auto-resolve in subsequent delta synchronization cycles. A common example where you might find transient objects being generated occurs on Azure AD Connect servers installed in staging mode, when an admin permanently deletes an object directly in Azure AD using PowerShell and later synchronizes the object again.
174
+
173
175
If sync engine locates a staging object that corresponds to the object specified in the Connector, it determines what kind of changes to apply. For example, sync engine might rename or delete the object in the connected data source, or it might only update the object’s attribute values.
174
176
175
177
Staging objects with updated data are marked as pending import. Different types of pending imports are available. Depending on the result of the import process, a staging object in the connector space has one of the following pending import types:
| Azure Batch |[Configure customer-managed keys for your Azure Batch account with Azure Key Vault and Managed Identity](../../batch/batch-customer-managed-key.md) </BR> [Configure managed identities in Batch pools](../../batch/managed-identity-pools.md)|
36
36
| Azure Blueprints |[Stages of a blueprint deployment](../../governance/blueprints/concepts/deployment-stages.md)|
37
+
| Azure Cache for Redis |[Managed identity for storage accounts with Azure Cache for Redis](../../azure-cache-for-redis/cache-managed-identity.md)|
37
38
| Azure Container Instance |[How to use managed identities with Azure Container Instances](../../container-instances/container-instances-managed-identity.md)|
38
39
| Azure Container Registry |[Use an Azure-managed identity in ACR Tasks](../../container-registry/container-registry-tasks-authentication-managed-identity.md)|
39
40
| Azure Cognitive Services |[Configure customer-managed keys with Azure Key Vault for Cognitive Services](../../cognitive-services/encryption/cognitive-services-encryption-keys-portal.md)|
0 commit comments