Merge pull request #7949 from MicrosoftDocs/main

Auto push to live 2024-12-30 02:00:02

Author: Deland-Han

support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png

@@ -0,0 +1,112 @@
+---
+title: Troubleshoot Authorization_RequestDenied error with Microsoft Graph
+description: Guides to troubleshoot Authorization_RequestDenied error with Microsoft Graph in Postman.
+ms.author: anukala
+ms.date: 12/24/2024
+ms.service: entra-id
+ms.custom: sap:Microsoft Graph Users, Groups, and Entra APIs
+---
+
+# Troubleshoot Authorization_RequestDenied error with Microsoft Graph
+
+When you use Microsoft Graph API to manage users, you might receive the following error message:
+
+> `Authorization_RequestDenied. Insufficient privileges to complete the operation.`
+
+This article demonstrates how to troubleshoot the `Authorization_RequestDenied` error in Microsoft Graph API by using Postman, through a "disable user" scenario.
+
+## Cause of the Authorization_RequestDenied error
+
+This error typically occurs because the user or app doesn't have sufficient permissions. To call Graph APIs, your app registration must have the following permissions:
+
+- The appropriate Microsoft Entra RBAC role for the required access level. For more information, see [Microsoft Entra built-in roles](/entra/identity/role-based-access-control/permissions-reference).
+- The necessary API permissions to access Microsoft Graph.
+
+
+## Troubleshooting Microsoft Graph API by using Postman
+
+
+### Step 1: Assign Microsoft Entra RBAC role to the app registration (Service Principal)
+
+1. Log in to the [Azure portal](https://portal.azure.com), and go to **Microsoft Entra ID**.
+1. In the **Manage** section, select **Roles and administrators**.
+1. Select the appropriate role based on the required level of access. In this article, the app will manage the users. Therefore, **User Administrator** is selected.
+1. Select **Add assignments**, select your app registration, and then select **Add**.
+
+### Step 2: Locate the application ID, client secret, and token endpoints of your app
+
+1. In the [Azure portal](https://portal.azure.com), go to **App registrations**, and then select your app registration.  
+1. On the **Overview** page, record the **Application (client) ID**.
+1. Select **Endpoints**. This selection provides information, such as token endpoints, that will be used in the Postman configuration. This article uses OAuth 2.0 and token-based authentication together with Entra ID. In this case, you should record the **OAuth 2.0 token endpoint (v2)**.
+
+    :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png" alt-text="Screenshot that shows checking the endpoints of the app registration." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png":::
+1. In the **Manage** section, select **Certificates & secrets**. Create a client secret or use an existing client secret for testing.
+
+    In the Postman configuration, ensure you use the Client secret value, not the Secret ID. The client secret value cannot be viewed, except immediately after it's created.
+
+### Step 3: Configure Postman
+
+1. In Postman, select a request or collection, and then select **Authorization**.
+1. Set Auth type to **OAuth 2.0**.
+1. In the **Configure New Token** section, specify the following configuration:
+
+   - Grant type: Client Credentials
+   - Access Token URL: \<OAuth 2.0 token endpoint\>.
+   - Client ID: \<Application (client) ID\>
+   - Client secret: \<Client secret value\>
+   - Scope: `https://graph.microsoft.com/.default`
+   - Client Authentication: Send as Basic Auth header
+
+    :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png" alt-text="Screenshot of Postman configurations." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png":::
+
+1. Select **Get New Access Token**. If the configuration is correct, you should receive a token that will be used to run the Microsoft Graph API call.
+1. Select **Proceed**, and then select **Use token**.
+
+### Step 4: Test and troubleshoot the Microsoft Graph API
+
+1. Send the following PATCH request to disable a user. `1f953789-0000-0000-0000-6f21508fd4e2` is the object ID of a user in the Entra ID.
+
+    ``` HTTP
+    Patch https://graph.microsoft.com/v1.0/users/1f953789-0000-0000-0000-6f21508fd4e2
+    ```
+
+    ```JSON
+    {
+    "accountEnabled": false
+    }
+    ```
+
+1. The `Authorization_RequestDenied` error message is received in the response:
+
+    ```Output
+    {
+        "error": {
+            "code": "Authorization_RequestDenied",
+            "message": "Insufficient privileges to complete the operation.",
+            "innerError": {
+                "date": "2024-12-24T03:25:32",
+                "request-id": "096361b2-75be-479b-b421-078610030949",
+                "client-request-id": "096361b2-75be-479b-b421-078610030949"
+            }
+        }
+    }
+    ```
+        
+1. Check the [Update user scenario in Microsoft Graph REST API v1.0 endpoint reference](/graph/api/user-update?view=graph-rest-1.0&tabs=http#permissions&preserve-view=true). The following permission is required to enable and disable a user, as described in the Microsoft Graph REST API v1.0 endpoint reference.
+
+    | Property        | Type    | Description |
+    |:----------------|:--------|:------------|
+    | accountEnabled  | Boolean | `true` if the account is enabled; otherwise, `false`. This property is required when a user is created. <br/> - *User.EnableDisableAccount.All* + *User.Read.All* is the least privileged combination of permissions required to update this property. <br/> - In delegated scenarios, *Privileged Authentication Administrator* is the least privileged role that's allowed to update this property for all administrators in the tenant. |
+
+1. Check whether the app registration has the required permissions:
+    1. Locate your app registration in the Azure portal.
+    2. In the **Manage** section, select **API permissions**
+    3. Check the configured API permissions. In this case, the app registration doesn't have the **User.EnableDisableAccount.All** permission that is the root cause of the issue.
+
+        :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png" alt-text="Screenshot that shows checking API permissions." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png":::
+
+1. Select **Add a permission** to add **User.EnableDisableAccount.All** to the app registration.
+1. You must also select **Grant admin consent for default directory** for the permissions. Select **Yes** to confirm that you want to grant admin consent.
+1. Send the PATCH request to disable a user. If the request is successful, you should receive a `204 No Content` response.
+
+[!INCLUDE [third-party-disclaimer](../../../includes/third-party-disclaimer.md)]

support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png

@@ -230,7 +230,10 @@
       href: mfa/unexpected-error-reset-pwd.md
     - name: Verify account error when resetting password
       href: mfa/cannot-verify-account-reset-pwd.md
-
+- name: Microsoft Graph Users, Groups, and Entra APIs
+  items: 
+   - name: Troubleshoot Authorization_RequestDenied error
+     href: app-integration/troubleshoot-authorization-requestdenied-graph-api.md
 - name: Microsoft Entra User Provisioning and Synchronization
   items:
   - name: User Sign-in or password Problems

support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png

@@ -2,94 +2,93 @@
 title: Http server returned Forbidden exception
 description: Provides a solution to an error that occurs when you select the Test & Enable Mailbox button on a mailbox record in Dynamics 365.
 ms.reviewer: 
-ms.topic: troubleshooting
-ms.date: 11/19/2024
+ms.date: 12/30/2024
 ms.custom: sap:Email and Exchange Synchronization
 ---
-# "Http server returned Forbidden exception" error appears in Microsoft Dynamics 365 mailbox
+# "Http server returned Forbidden exception" error when testing a Dynamics 365 mailbox
 
-This article provides a solution to an error that occurs when you select the **Test & Enable Mailbox** button on a mailbox record in Dynamics 365.
+This article provides a solution to an error that occurs when you select the **Test & Enable Mailbox** button on a mailbox record in Microsoft Dynamics 365.
 
 _Applies to:_   Microsoft Dynamics 365  
 _Original KB number:_   4483440
 
 ## Symptoms
 
-When you select the **Test & Enable Mailbox** button on a mailbox record in Dynamics 365, the test results section shows Failure and the following alert is logged:
+When you select the **Test & Enable Mailbox** button on a mailbox record in Dynamics 365, the test results section shows **Failure** and the following alert is logged:
 
-> "The email message "Your mailbox is now connected to Dynamics 365" cannot be sent because an error occurred while establishing a secure connection to the email server. Mailbox [Mailbox Name] didn't synchronize. The owner of the email server profile Microsoft Exchange Online has been notified.  
-Email Server Error Code: Http server returned Forbidden exception."
+> The email message "Your mailbox is now connected to Dynamics 365" cannot be sent because an error occurred while establishing a secure connection to the email server. Mailbox [Mailbox Name] didn't synchronize. The owner of the email server profile Microsoft Exchange Online has been notified.  
+> **Email Server Error Code**: Http server returned Forbidden exception.
 
-If you select **Details**, the following other details are shown:
+If you select **Details**, the following details are shown:
 
-> "Error : System.Net.WebException: The request failed with HTTP status 403: Forbidden.  
-   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)  
-   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)  
-   at Microsoft.Crm.Asynchronous.EmailConnector.ExchangeServiceBinding.EndCreateItem(IAsyncResult asyncResult)  
-   at Microsoft.Crm.Asynchronous.EmailConnector.ExchangeOutgoingEmailProvider.EndCreateItem()"
+> Error : System.Net.WebException: The request failed with HTTP status 403: Forbidden.  
+> at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)  
+> at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)  
+> at Microsoft.Crm.Asynchronous.EmailConnector.ExchangeServiceBinding.EndCreateItem(IAsyncResult asyncResult)  
+> at Microsoft.Crm.Asynchronous.EmailConnector.ExchangeOutgoingEmailProvider.EndCreateItem()
 
 ## Cause
 
-Dynamics 365 communicates with Microsoft Exchange using Exchange Web Services (EWS) requests. If EWS is disabled, this error will occur. The following contents are some potential ways that EWS may be disabled or restricted in Exchange:
+Dynamics 365 communicates with Microsoft Exchange using Exchange Web Services (EWS) requests. If EWS is disabled, this error occurs. Here are some potential ways that EWS might be disabled or restricted in Exchange:
 
-1. EWS is disabled for the mailbox
-2. EWS is disabled for the entire organization
-3. The `EwsApplicationAccessPolicy` is set to **EnforceAllowList** and `the EwsAllowList` doesn't allow access from Dynamics 365 (CRM).
-4. The `EwsApplicationAccessPolicy` is set to **EnforceBlockList** and `the EwsBlockList` includes Dynamics 365 (CRM).
+1. EWS is disabled for the mailbox.
+2. EWS is disabled for the entire organization.
+3. The `EwsApplicationAccessPolicy` is set to **EnforceAllowList** and the `EwsAllowList` doesn't allow access from Dynamics 365.
+4. The `EwsApplicationAccessPolicy` is set to **EnforceBlockList** and the `EwsBlockList` includes Dynamics 365.
 
 ## Resolution
 
-**If the issue only occurs for some mailboxes, check if EWS is disabled for the mailbox:**
+### Check if EWS is disabled for the mailbox if the issue only occurs for some mailboxes
 
-1. First check to see if EWS has been disabled for the mailbox. Use the following PowerShell command:
+1. First, check if EWS is disabled for a specific mailbox using this PowerShell command:
 
     ```powershell
     Get-CASMailbox <mailbox-alias> | ft EwsEnabled
     ```
 
-2. If **EwsEnabled** is set to **False**, use the following PowerShell command to enable Exchange Web Services (EWS) for the mailbox:
+2. If **EwsEnabled** is set to **False**, enable it using this command:
 
     ```powershell
     Set-CASMailbox <mailbox-alias> -EwsEnabled $True
     ```
 
     > [!IMPORTANT]
-    > After running this command, it may take up to 120 minutes before the setting change takes effect.
+    > After running this command, it might take up to 120 minutes before the setting change takes effect.
 
- **If the issue occurs for all mailboxes, check if EWS is disabled at the organization level, or if the EwsAllowList is being used to limit what EWS traffic is allowed.**
+## Check if EWS is disabled at the organization level or if the EwsAllowList limits the EWS traffic
 
-1. Use the following PowerShell command to see if any of the EWS settings are configured:
+1. Use this PowerShell command to check organization-level settings:
 
     ```powershell
     Get-OrganizationConfig |ft Name, EwsEnabled,EwsApplicationAccessPolicy,EwsBlockList,EwsAllowList
     ```
 
-2. Verify that **EwsEnabled** isn't set to **False**. The following command can be used to set **EwsEnabled** to **True** if it's currently set to **False**:
+2. Ensure that `EwsEnabled` isn't set to **False**. If it is, enable it using:
 
     ```powershell
     Set-OrganizationConfig -EwsEnabled $True
     ```
 
     > [!IMPORTANT]
-    > After running this command, it may take up to 120 minutes before the setting change takes effect.
+    > After running this command, it might take up to 120 minutes before the setting change takes effect.
 
-3. If `EwsApplicationAccessPolicy` is set to **EnforceAllowList** and the `EwsAllowList` doesn't contain a value for CRM (Example: CRM/\*), which would prevent Dynamics 365 (CRM) from being able to communicate with Exchange. Use the following command to update the list to include CRM/* and whatever other applications you want to allow (\<PreviousAllowList> in the following example):
+3. If `EwsApplicationAccessPolicy` is set to **EnforceAllowList**, check if the `EwsAllowList` contains a value for CRM (for example, CRM/\*) to allow Dynamics 365 (CRM) to communicate with Exchange. If it does not, use the following command to update the list to include CRM/* and any other applications you want to allow. In this example \<PreviousAllowedList> is the list of applications that were previously in the allowlist:
 
     ```powershell
     Set-OrganizationConfig -EwsApplicationAccessPolicy:EnforceAllowList -EwsAllowList:CRM/*,<PreviousAllowedList>
     ```
 
     > [!IMPORTANT]
-    > After running this command, it may take up to 120 minutes before the setting change takes effect.
+    > After running this command, it might take up to 120 minutes before the setting change takes effect.
 
-4. If `EwsApplicationAccessPolicy` is set to **EnforceBlockList** and the **EwsAllowList** contains a value for CRM (Example: CRM/*), which would prevent Dynamics 365 (CRM) from being able to communicate with Exchange. Use the following command to update the list to no longer include CRM:
+4. If `EwsApplicationAccessPolicy` is set to **EnforceBlockList**, check if the `EwsBlockList` contains a value for CRM (for example, CRM/*), which prevents Dynamics 365 (CRM) from communicating with Exchange. If it does, use the following command to update the list to no longer include CRM. In this example \<PreviousBlockList WITH CRM REMOVED> is the list of applications that were previously in the blocklist except for CRM:
 
     ```powershell
     Set-OrganizationConfig -EwsApplicationAccessPolicy:EnforceBlockList -EwsBlockList:<PreviousBlockList WITH CRM REMOVED>
     ```
 
     > [!IMPORTANT]
-    > After running this command, it may take up to 120 minutes before the setting change takes effect.
+    > After running this command, it might take up to 120 minutes before the setting change takes effect.
 
 ## More information
 

support/entra/entra-id/app-integration/troubleshoot-authorization-requestdenied-graph-api.md

@@ -14,7 +14,7 @@ searchScope:
 ---
 # Some SIDs don't resolve into friendly names
 
-This article provides some information about the issue where some security identifiers (SIDS) don't resolve into friendly names.
+This article provides some information about the issue where some security identifiers (SIDs) don't resolve into friendly names.
 
 _Original KB number:_   4502539
 
@@ -43,7 +43,7 @@ Windows 10, version 1809 uses more than 300 Capability SIDs.
 ## More information
 
 > [!Important]
-> Don't delete Capability SIDS from either the registry or file system permissions. Removing a Capability SID from file system permissions or registry permissions might cause a feature or application to function incorrectly. After you remove a Capability SID, you cannot use the UI to add it back.
+> Don't delete Capability SIDs from either the registry or file system permissions. Removing a Capability SID from file system permissions or registry permissions might cause a feature or application to function incorrectly. After you remove a Capability SID, you cannot use the UI to add it back.
 
 When you're troubleshooting an unresolved SID, make sure that it isn't a Capability SID. To get a list of all of the Capability SIDs, follow these steps: