Merge pull request #195041 from MicrosoftDocs/main

4/13 PM Publish

Author: huypub

articles/active-directory/managed-identities-azure-resources/how-to-use-vm-token.md

@@ -46,6 +46,7 @@ A client application can request a managed identity [app-only access token](../d
 | Link | Description |
 | -------------- | -------------------- |
 | [Get a token using HTTP](#get-a-token-using-http) | Protocol details for managed identities for Azure resources token endpoint |
+| [Get a token using Azure.Identity](#get-a-token-using-the-azure-identity-client-library) | Get a token using Azure.Identity library |
 | [Get a token using the Microsoft.Azure.Services.AppAuthentication library for .NET](#get-a-token-using-the-microsoftazureservicesappauthentication-library-for-net) | Example of using the Microsoft.Azure.Services.AppAuthentication library from a .NET client
 | [Get a token using C#](#get-a-token-using-c) | Example of using managed identities for Azure resources REST endpoint from a C# client |
 | [Get a token using Java](#get-a-token-using-java) | Example of using managed identities for Azure resources REST endpoint from a Java client |

articles/active-directory/standards/memo-22-09-authorization.md

@@ -1,6 +1,6 @@
 ---
 title: Memo 22-09 authorization requirements 
-description: Guidance on meeting authorization requirements outlined in US government OMB memorandum 22-09
+description: Get guidance on meeting authorization requirements outlined in US government OMB memorandum 22-09.
 services: active-directory 
 ms.service: active-directory
 ms.subservice: standards
@@ -15,68 +15,75 @@ ms.custom: it-pro
 ms.collection: M365-identity-device-management
 ---
 
-# Meet authorization requirements for Memorandum 22-09
+# Meet authorization requirements of memorandum 22-09
 
-This series of articles offer guidance for employing Azure Active Directory (Azure AD) as a centralized identity management system for implementing Zero Trust principles as described by the US Federal Government’s Office of Management and Budget (OMB) [Memorandum M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf). Throughout this document. We refer to it as “The memo.”
+This series of articles offers guidance for employing Azure Active Directory (Azure AD) as a centralized identity management system for implementing Zero Trust principles, as described in the US federal government's Office of Management and Budget (OMB) [memorandum 22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).
 
-[Memorandum M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf) requires specific types of enforcement within your MFA policies. Specifically, you must account for device-based, role-based, attribute-based controls, and privileged access management.
+The memo requires specific types of enforcement within your multifactor authentication (MFA) policies. Specifically, you must account for device-based controls, role-based controls, attribute-based controls, and privileged access management.
 
- 
 
 ## Device-based controls
 
-M-22-09 specifically requires the use of at least one device-based signal when making an authorization decision to access a system or application. This requirement can be enforced using Conditional Access and there are several device signals that can be applied during the authorization. The following table describes the signal and the requirements to retrieve the signal:
+Memorandum 22-09 specifically requires the use of at least one device-based signal when you're making an authorization decision to access a system or application. You can enforce this requirement by using conditional access. Several device signals can be applied during the authorization. The following table describes the signal and the requirements to retrieve the signal:
 
 | Signal| Signal retrieval |
 | - | - |
-| Device must be managed| Integration with Intune or another MDM that supports this integration are required. 
-Hybrid Azure AD joined since the device is managed by active directory also qualifies |
-| Device must be compliant| Integration with Intune or other MDM’s that support this integration are required. For more information, see [Use device compliance policies to set rules for devices you manage with Intune](/mem/intune/protect/device-compliance-get-started) |
-| Threat signals| Microsoft Defender for Endpoint and other EDR tools have integrations with Azure AD and Intune to send threat signals that can be used to deny access. Threat signals are part of the compliant status signal |
-| Cross tenant access policies| permits an organization to trust device signals from devices belonging to other organizations. (public preview) |
+| Device must be managed| Integration with Intune or another mobile device management (MDM) solution that supports this integration is required. 
+Hybrid Azure AD joined| The device is managed by Active Directory and qualifies. 
+| Device must be compliant| Integration with Intune or another MDM solution that supports this integration is required. For more information, see [Use device compliance policies to set rules for devices you manage with Intune](/mem/intune/protect/device-compliance-get-started). |
+| Threat signals| Microsoft Defender for Endpoint and other endpoint detection and response (EDR) tools have integrations with Azure AD and Intune to send threat signals that can be used to deny access. Threat signals are part of the compliant status signal. |
+| Cross-tenant access policies (public preview)| These policies permit an organization to trust device signals from devices that belong to other organizations. |
 
-##  Role-based access controls
+##  Role-based controls
 
-Role based access control (RBAC role) remains an important way to enforce basic authorizations through assignments of users to a role in a particular scope. Azure AD has tools that make RBAC assignment and lifecycle management easier. This includes assigning access using [entitlement management](../governance/entitlement-management-overview.md) features, include [Access Packages](../governance/entitlement-management-access-package-create.md) and [Access Reviews](../governance/access-reviews-overview.md). These ease the burden of managing authorizations by providing self-service requests and automated functions to managed the lifecycle, for example by automatically ending access based of specific criteria.
+Role-based access control (RBAC) is an important way to enforce basic authorizations through assignments of users to a role in a particular scope. Azure AD has tools that make RBAC assignment and lifecycle management easier. For example, you can assign access by using [entitlement management](../governance/entitlement-management-overview.md) features, including [access packages](../governance/entitlement-management-access-package-create.md) and [access reviews](../governance/access-reviews-overview.md). 
+
+These features ease the burden of managing authorizations by providing self-service requests and automated functions to manage the lifecycle. For example, you can automatically end access based on specific criteria.
 
 ## Attribute-based controls
 
-Attribute based access controls rely on metadata assigned to a user or resource as a mechanism to permit or deny access during authentication. There are several ways you can create authorizations using ABAC enforcements for data and resources through authentication. 
+Attribute-based access control (ABAC) relies on metadata assigned to a user or resource as a mechanism to permit or deny access during authentication. There are several ways to create authorizations by using ABAC enforcements for data and resources through authentication. 
 
 ### Attributes assigned to users
 
-Attributes assigned to users and stored in Azure AD can be leveraged to create authorizations for users. This is achieved through the automatic assignment of users to [Dynamic Groups](../enterprise-users/groups-create-rule.md) based on a particular ruleset defined during group creation. Rules are configured to add or remove a user from the group based on the evaluation of the rule against the user and one or more of their attributes. This feature has greater value when your attributes are maintained and not statically set on users from the day of creation.
+You can use attributes assigned to users and stored in Azure AD to create authorizations for users. Users can be automatically assigned to [dynamic groups](../enterprise-users/groups-create-rule.md) based on a particular ruleset that you define during group creation. Rules are configured to add or remove a user from the group based on the evaluation of the rule against the user and one or more of their attributes. This feature has greater value when your attributes are maintained and not statically set on users from the day of creation.
 
 ### Attributes assigned to data
 
-Azure AD allows integration of an authorization directly to the data. You can create integrate authorization in multiple ways.
+Azure AD allows integration of an authorization directly to the data. You can integrate authorization in multiple ways.
+
+You can configure [authentication context](../conditional-access/concept-conditional-access-cloud-apps.md) within conditional access policies. This allows you to, for example, restrict which actions a user can take within an application or on specific data. These authentication contexts are then mapped within the data source itself. 
+
+Data sources can be Microsoft Office files like Word and Excel, or SharePoint sites that are mapped to your authentication context. For an example of this integration, see [Manage site access based on sensitivity label](/sharepoint/authentication-context-example). 
 
-You can configure [authentication context](../conditional-access/concept-conditional-access-cloud-apps.md) within Conditional Access Policies. This allows you to, for example, restrict which actions a user can take within an application or on specific data. These authentication contexts are then mapped within the data source itself. Data sources can be office files like word and excel or SharePoint sites that use  mapped to your authentication context. An example of this integration is shown [here](/sharepoint/authentication-context-example). 
+You can also use authentication context assigned to data directly in your applications. This approach requires integration with the application code and [developers](../develop/developer-guide-conditional-access-authentication-context.md) to adopt this capability. You can use authentication context integration with Microsoft Defender for Cloud Apps to control [actions taken on data through session controls](/defender-cloud-apps/session-policy-aad). 
 
-You can also leverage authentication context assigned to data directly in your applications. This requires integration with the application code and [developers](../develop/developer-guide-conditional-access-authentication-context.md) to adopt this capability. Authentication context integration with Microsoft Defender for Cloud Apps can be used to control [actions taken on data using session controls](/defender-cloud-apps/session-policy-aad). Dynamic groups mentioned previously when combined with Authentication context allow you to control user access mappings between the data and the user attributes. 
+If you combine dynamic groups with authentication context, you can control user access mappings between the data and the user attributes. 
 
 ### Attributes assigned to resources
 
-Azure includes [ABAC for Storage](../../role-based-access-control/conditions-overview.md) which allows the assignment of metadata tags on data stored in an Azure blob storage account. This metadata can then be assigned to users using role assignments to grant access.  
+Azure includes [ABAC for Storage](../../role-based-access-control/conditions-overview.md), which allows the assignment of metadata tags on data stored in an Azure Blob Storage account. You can then assign this metadata to users by using role assignments to grant access.  
 
-## Privileged Access Management 
+## Privileged access management 
 
-The memo specifically calls out the use of privileged access management tools that leverage single factor ephemeral credentials for accessing systems as insufficient. These technologies often include password vault products that accept MFA logon for an admin and produce a generated password for an alternate account used to access the system. The system being accessed is still accessed with a single factor. Microsoft has tools for implementing [Privileged identity management](../privileged-identity-management/pim-configure.md) (PIM) for privileged systems with the central identity management system of Azure AD. Using the methods described in the MFA section you can enforce MFA for most privileged systems directly, whether these are applications, infrastructure, or devices. Azure also features PIM capabilities to step up into a specific privileged role. This requires implementation of PIM with Azure AD identities and identifying those systems that are privileged and require additional protections to prevent lateral movement. Configuration guidance is located [here](../privileged-identity-management/pim-deployment-plan.md).
+The memo specifically calls out the use of privileged access management tools that use single-factor ephemeral credentials for accessing systems as insufficient. These technologies often include password vault products that accept MFA sign-in for an admin and produce a generated password for an alternate account that's used to access the system. The system is still accessed with a single factor.
+
+Microsoft has tools for implementing [Privileged Identity Management](../privileged-identity-management/pim-configure.md) (PIM) for privileged systems with the central identity management system of Azure AD. You can enforce MFA for most privileged systems directly, whether these systems are applications, infrastructure elements, or devices. 
+
+Azure also features PIM capabilities to step up into a specific privileged role. This requires implementation of PIM with Azure AD identities, along with identifying systems that are privileged and require additional protections to prevent lateral movement. For configuration guidance, see [Plan a Privileged Identity Management deployment](../privileged-identity-management/pim-deployment-plan.md).
 
 ## Next steps
 
-The following articles are a part of this documentation set:
+The following articles are part of this documentation set:
 
-[Meet identity requirements of Memorandum 22-09](memo-22-09-meet-identity-requirements.md)
+[Meet identity requirements of memorandum 22-09](memo-22-09-meet-identity-requirements.md)
 
 [Enterprise-wide identity management system](memo-22-09-enterprise-wide-identity-management-system.md)
 
-[Multi-factor authentication](memo-22-09-multi-factor-authentication.md)
-
-[Authorization](memo-22-09-authorization.md)
+[Multifactor authentication](memo-22-09-multi-factor-authentication.md)
 
 [Other areas of Zero Trust](memo-22-09-other-areas-zero-trust.md)
 
-Additional Zero Trust Documentation
+For more information about Zero Trust, see:
 
 [Securing identity with Zero Trust](/security/zero-trust/deploy/identity)