Merge pull request #210284 from eringreenlee/master

freshness updates

Author: v-stsavell

articles/active-directory/manage-apps/application-properties.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 09/22/2021
+ms.date: 09/06/2022
 ms.author: ergreenl
 #Customer intent: As an administrator of an Azure AD tenant, I want to learn more about the properties of an enterprise application that I can configure.
 ---

articles/active-directory/manage-apps/application-sign-in-problem-application-error.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 07/11/2017
+ms.date: 09/06/2022
 ms.author: ergreenl
 ms.collection: M365-identity-device-management
 ---
@@ -17,7 +17,14 @@ ms.collection: M365-identity-device-management
 
 In this scenario, Azure Active Directory (Azure AD) signs the user in. But the application displays an error message and doesn't let the user finish the sign-in flow. The problem is that the app didn't accept the response that Azure AD issued.
 
-There are several possible reasons why the app didn't accept the response from Azure AD. If the error message doesn't clearly identify what's missing from the response, try the following:
+There are several possible reasons why the app didn't accept the response from Azure AD. If there is an error message or code displayed, use the following resources to diagnose the error:
+
+* [Azure AD Authentication and authorization error codes](../develop/reference-aadsts-error-codes.md)
+
+* [Troubleshooting consent prompt errors](application-sign-in-unexpected-user-consent-error.md)
+
+
+If the error message doesn't clearly identify what's missing from the response, try the following:
 
 - If the app is the Azure AD gallery, verify that you followed the steps in [How to debug SAML-based single sign-on to applications in Azure AD](./debug-saml-sso-issues.md).
 
@@ -58,13 +65,13 @@ To add an attribute in the Azure AD configuration that will be sent in the Azure
 
    The next time that the user signs in to the app, Azure AD will send the new attribute in the SAML response.
 
-## The app doesn't identify the user
+## The app cannot identify the user
 
 Signing in to the app fails because the SAML response is missing an attribute such as a role. Or it fails because the app expects a different format or value for the **NameID** (User Identifier) attribute.
 
 If you're using [Azure AD automated user provisioning](../app-provisioning/user-provisioning.md) to create, maintain, and remove users in the app, verify that the user has been provisioned to the SaaS app. For more information, see [No users are being provisioned to an Azure AD Gallery application](../app-provisioning/application-provisioning-config-problem-no-users-provisioned.md).
 
-## Add an attribute to the Azure AD app configuration
+### Add an attribute to the Azure AD app configuration
 
 To change the User Identifier value, follow these steps:
 
@@ -87,7 +94,7 @@ To change the User Identifier value, follow these steps:
 
 8. Under **User attributes**, select the unique identifier for the user from the **User Identifier** drop-down list.
 
-## Change the NameID format
+### Change the NameID format
 
 If the application expects another format for the **NameID** (User Identifier) attribute, see [Editing nameID](../develop/active-directory-saml-claims-customization.md#editing-nameid) to change the NameID format.
 
@@ -155,4 +162,8 @@ To change the signing algorithm, follow these steps:
 
 ## Next steps
 
-[How to debug SAML-based single sign-on to applications in Azure AD](./debug-saml-sso-issues.md).
+* [How to debug SAML-based single sign-on to applications in Azure AD](./debug-saml-sso-issues.md).
+
+* [Azure AD Authentication and authorization error codes](../develop/reference-aadsts-error-codes.md)
+
+* [Troubleshooting consent prompt errors](application-sign-in-unexpected-user-consent-error.md)

articles/active-directory/manage-apps/application-sign-in-unexpected-user-consent-error.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 07/11/2017
+ms.date: 09/06/2022
 ms.author: ergreenl
 ms.reviewer: phsignor, yuhko
 ms.collection: M365-identity-device-management
@@ -31,31 +31,27 @@ This error occurs when a user who is not a Global Administrator attempts to use
 
 This error can also occur when a user is prevented from consenting to an application due to Microsoft detecting that the permissions request is risky. In this case, an audit event will also be logged with a Category of "ApplicationManagement", Activity Type of "Consent to application" and Status Reason of "Risky application detected".
 
-Another scenario in which this error might occur is when the user assignment is required for the application, but no administrator consent was provided. In this case, the administrator must first provide administrator consent.
+Another scenario in which this error might occur is when the user assignment is required for the application, but no administrator consent was provided. In this case, the administrator must first provide tenant-wide admin consent for the application.
 
 ## Policy prevents granting permissions error
 
 * **AADSTS90093:** An administrator of <tenantDisplayName> has set a policy that prevents you from granting <name of app> the permissions it is requesting. Contact an administrator of <tenantDisplayName>, who can grant permissions to this app on your behalf.
 
-This error occurs when a Global Administrator turns off the ability for users to consent to applications, then a non-administrator user attempts to use an application that requires consent. This error can be resolved by an administrator granting access to the application on behalf of their organization.
+This error can occur when a Global Administrator turns off the ability for users to consent to applications, then a non-administrator user attempts to use an application that requires consent. This error can be resolved by an administrator granting access to the application on behalf of their organization.
 
 ## Intermittent problem error
 
 * **AADSTS90090:** It looks like the sign-in process encountered an intermittent problem recording the permissions you attempted to grant to <clientAppDisplayName>. try again later.
 
 This error indicates that an intermittent service side issue has occurred. It can be resolved by attempting to consent to the application again.
 
-## Resource not available error
 
-* **AADSTS65005:** The app <clientAppDisplayName> requested permissions to access a resource <resourceAppDisplayName> that is not available.
-
-Contact the application developer.
 
 ## Resource not available in tenant error
 
 * **AADSTS65005:** <clientAppDisplayName> is requesting access to a resource <resourceAppDisplayName> that is not available in your organization <tenantDisplayName>.
 
-Ensure that this resource is available or contact an administrator of <tenantDisplayName>.
+Ensure that these resources that provide the permissions requested are available in your tenant or contact an administrator of <tenantDisplayName>. Otherwise, there is a misconfiguration in how the application requests resources, and you should contact the application developer.
 
 ## Permissions mismatch error
 
@@ -91,3 +87,5 @@ End-users will not be able to grant consent to apps that have been detected as r
 [Apps, permissions, and consent in Azure Active Directory (v1 endpoint)](../develop/quickstart-register-app.md)<br>
 
 [Scopes, permissions, and consent in the Azure Active Directory (v2.0 endpoint)](../develop/v2-permissions-and-consent.md)
+
+[Unexpected consent prompt when signing in to an application](application-sign-in-unexpected-user-consent-prompt.md)

articles/active-directory/manage-apps/application-sign-in-unexpected-user-consent-prompt.md

@@ -8,43 +8,79 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 07/11/2017
+ms.date: 09/07/2022
 ms.author: ergreenl
 ms.reviewer: phsignor, yuhko
 ms.collection: M365-identity-device-management
 ---
 
 # Unexpected consent prompt when signing in to an application
 
-Many applications that integrate with Azure Active Directory require permissions to various resources in order to run. When these resources are also integrated with Azure Active Directory, permissions to access them is requested using the Azure AD consent framework.
+Many applications that integrate with Azure Active Directory require permissions to various resources in order to run. When these resources are also integrated with Azure Active Directory, permissions to access them is requested using the Azure AD consent framework. These requests result in a consent prompt being shown the first time an application is used, which is often a one-time operation.
 
-This results in a consent prompt being shown the first time an application is used, which is often a one-time operation.
+In certain scenarios, additional consent prompts can appear when a user attempts to sign-in. In this article, we will diagnose the reason for the unexpected consent prompts showing, and how to troubleshoot.
 
 > [!VIDEO https://www.youtube.com/embed/a1AjdvNDda4]
 
 ## Scenarios in which users see consent prompts
 
-Additional prompts can be expected in various scenarios:
+Further prompts can be expected in various scenarios:
 
-* The application has been configured to require assignment. User consent is not currently supported for apps which require assignment. If you configure an application to require assignment, be sure to also grant tenant-wide admin consent so that assigned user can sign in.
+* The application has been configured to require assignment. Individual user consent is not currently supported for apps which require assignment; thus the permissions must be granted by an admin for the whole directory. If you configure an application to require assignment, be sure to also grant tenant-wide admin consent so that assigned user can sign-in.
 
-* The set of permissions required by the application has changed.
+* The set of permissions required by the application has changed by the developer and needs to be granted again.
 
 * The user who originally consented to the application was not an administrator, and now a different (non-admin) user is using the application for the first time.
 
-* The user who originally consented to the application was an administrator, but they did not consent on-behalf of the entire organization.
+* The user who originally consented to the application was an administrator, but they didn't consent on-behalf of the entire organization.
 
-* The application is using [incremental and dynamic consent](../azuread-dev/azure-ad-endpoint-comparison.md#incremental-and-dynamic-consent) to request additional permissions after consent was initially granted. This is often used when optional features of an application additional require permissions beyond those required for baseline functionality.
+* The application is using [incremental and dynamic consent](../azuread-dev/azure-ad-endpoint-comparison.md#incremental-and-dynamic-consent) to request further permissions after consent was initially granted. Incremental and dynamic consent is often used when optional features of an application require permissions beyond those required for baseline functionality.
 
 * Consent was revoked after being granted initially.
 
-* The developer has configured the application to require a consent prompt every time it is used (note: this is not best practice).
+* The developer has configured the application to require a consent prompt every time it is used (note: this behavior isn't best practice).
 
    > [!NOTE]
    > Following Microsoft's recommendations and best practices, many organizations have disabled or limited users' permission to grant consent to apps. If an application forces users to grant consent every time they sign in, most users will be blocked from using these applications even if an administrator grants tenant-wide admin consent. If you encounter an application which is requiring user consent even after admin consent has been granted, check with the app publisher to see if they have a setting or option to stop forcing user consent on every sign in.
 
+## Troubleshooting steps
+
+### Compare permissions requested and granted for the applications
+
+To ensure the permissions granted for the application are up-to-date, you can compare the permissions that are being requested by the application with the permissions already granted in the tenant. 
+
+1. Sign-in to the Azure portal with an administrator account.
+2. Navigate to **Enterprise applications**.
+3. Select the application in question from the list.
+4. Under Security in the left-hand navigation, choose **Permissions**
+5. View the list of already granted permissions from the table on the Permissions page
+6. To view the requested permissions, click on the **Grant admin consent** button. (NOTE: This will open a consent prompt listing all of the requested permissions. Don't click accept on the consent prompt unless you are sure you want to grant tenant-wide admin consent.)
+7. Within the consent prompt, expand the listed permissions and compare with the table on the permissions page. If any are present in the consent prompt but not the permissions page, that permission has yet to be consented to. Unconsented permissions may be the cause for unexpected consent prompts showing for the application.
+
+### View user assignment settings
+
+If the application requires assignment, individual users can't consent for themselves. To check if assignment is required for the application, do the following:
+
+1. Sign-in to the Azure portal with an administrator account.
+2. Navigate to **Enterprise applications**.
+3. Select the application in question from the list.
+4. Under Manage in the left-hand navigation, choose **Properties**.
+5. Check to see if **Assignment required?** is set to **Yes**.
+6. If set to yes, then an admin must consent to the permissions on behalf of the entire organization. 
+
+### Review tenant-wide user consent settings
+
+Determining whether an individual user can consent to an application can be configured by every organization, and may differ from directory to directory. Even if every permission doesn't require admin consent by default, your organization may have disabled user consent entirely, preventing an individual user to consent for themselves for an application. To view your organization's user consent settings, do the following:
+
+1. Sign-in to the Azure portal with an administrator account.
+2. Navigate to **Enterprise applications**.
+3. Under Security in the left-hand navigation, choose **Consent and permissions**.
+4. View the user consent settings. If set to *Do not allow user consent*, users will never be able to consent on behalf of themselves for an application.
+
 ## Next steps
 
 * [Apps, permissions, and consent in Azure Active Directory (v1.0 endpoint)](../develop/quickstart-register-app.md)
 
 * [Scopes, permissions, and consent in the Azure Active Directory (v2.0 endpoint)](../develop/v2-permissions-and-consent.md)
+
+* [Unexpected error when performing consent to an application](application-sign-in-unexpected-user-consent-error.md)

articles/active-directory/manage-apps/configure-user-consent-groups.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/31/2021
+ms.date: 09/06/2022
 ms.author: ergreenl
 ms.reviewer: phsignor, yuhko
 ms.custom: contperf-fy21q2