Merge remote-tracking branch 'upstream/master' into alexbuckgit/docutune-autopr-20211025-193844-2965520

Author: alexbuckgit

articles/active-directory/conditional-access/concept-conditional-access-conditions.md

@@ -6,12 +6,12 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 09/13/2021
+ms.date: 10/22/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
 manager: karenhoran
-ms.reviewer: calebb
+ms.reviewer: calebb, sandeo-MSFT
 
 ms.collection: M365-identity-device-management
 ---
@@ -189,7 +189,7 @@ By selecting **Other clients**, you can specify a condition that affects apps th
 
 ## Device state (preview)
 > [!CAUTION]
-> **This preview feature is being deprecated.** Customers should use **Filter for devices** condition in Conditional Access to satisfy scenarios, previously achieved using Device state (preview) condition.
+> **This preview feature is being deprecated.** Customers should use **Filter for devices** condition in Conditional Access to satisfy scenarios, previously achieved using device state (preview) condition.
 
 The device state condition can be used to exclude devices that are hybrid Azure AD joined and/or devices marked as compliant with a Microsoft Intune compliance policy from an organization's Conditional Access policies.
 

articles/active-directory/conditional-access/concept-conditional-access-session.md

@@ -71,7 +71,7 @@ For more information, see the article [Configure authentication session manageme
 
 ## Customize continuous access evaluation
 
-For organizations who wish to disable or strictly enforce [continuous access evaluation](concept-continuous-access-evaluation.md), this configuration is now an option in Conditional Access. 
+[Continuous access evaluation](concept-continuous-access-evaluation.md) is auto enabled as part of an organization's Conditional Access policies. For organizations who wish to disable or strictly enforce continuous access evaluation, this configuration is now an option within the session control within Conditional Access. Admins can make this selection while creating a new policy or while editing an existing Conditional Access policy. 
 
 **Disable** works when **All cloud apps** are selected, and no conditions are selected.
 

articles/active-directory/develop/active-directory-saml-claims-customization.md

@@ -45,7 +45,7 @@ To edit the NameID (name identifier value):
 
 If the SAML request contains the element NameIDPolicy with a specific format, then the Microsoft identity platform will honor the format in the request.
 
-If the SAML request doesn't contain an element for NameIDPolicy, then the Microsoft identity platform will issue the NameID with the  format you specify. If no format is specified, the Microsoft identity platform will use the default source format associated with the claim source selected. If a transformation results in a null or illegal value, Azure AD will send a persisistent pairwise identifier in the nameIdentifier. 
+If the SAML request doesn't contain an element for NameIDPolicy, then the Microsoft identity platform will issue the NameID with the  format you specify. If no format is specified, the Microsoft identity platform will use the default source format associated with the claim source selected. If a transformation results in a null or illegal value, Azure AD will send a persistent pairwise identifier in the nameIdentifier. 
 
 From the **Choose name identifier format** dropdown, you can select one of the following options.
 

articles/active-directory/develop/msal-net-token-cache-serialization.md

@@ -36,7 +36,7 @@ The [Microsoft.Identity.Web](https://github.com/AzureAD/microsoft-identity-web)
 
 | Extension Method | Description  |
 | ---------------- | ------------ |
-| `AddInMemoryTokenCaches` | In memory token cache serialization. This implementation is great in samples. It's also good in production applications provided you don't mind if the token cache is lost when the web app is restarted. `AddInMemoryTokenCaches` takes an optional parameter of type `MsalMemoryTokenCacheOptions` that enables you to specify the duration after which the cache entry will expire unless it's used.
+| `AddInMemoryTokenCaches` | In memory token cache serialization. This implementation is great in samples and for daemon applications (app to app tokens / `AcquireTokenForClient`). It's also good in production applications provided you don't mind if the token cache is lost when the web app is restarted. Starting with Microsoft.Identity.Web 1.19.0, this configures MSAL to utilize a static (shared) cache across all app instances and it is significantly faster than other caching mechanisms.
 | `AddSessionTokenCaches` | The token cache is bound to the user session. This option isn't ideal if the ID token contains many claims as the cookie would become too large.
 | `AddDistributedTokenCaches` | The token cache is an adapter against the ASP.NET Core `IDistributedCache` implementation, therefore enabling you to choose between a distributed memory cache, a Redis cache, a distributed NCache, or a SQL Server cache. For details about the `IDistributedCache` implementations, see [Distributed memory cache](/aspnet/core/performance/caching/distributed).
 

articles/active-directory/develop/reference-breaking-changes.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: reference
-ms.date: 6/4/2021
+ms.date: 10/22/2021
 ms.author: ryanwi
 ms.reviewer: hirsin
 ms.custom: aaddev, has-adal-ref
@@ -31,43 +31,49 @@ The authentication system alters and adds features on an ongoing basis to improv
 
 ## Upcoming changes
 
+No upcoming changes to be aware of. 
+
 ## October 2021
 
-### AppId URI in single tenant applications will require use of default scheme or verified domains
+### Error 50105 has been fixed to not return `interaction_required` during interactive authentication
 
 **Effective date**: October 2021
 
 **Endpoints impacted**: v2.0 and v1.0
 
-**Protocol impacted**: All flows
+**Protocol impacted**: All user flows for apps [requiring user assignment](../manage-apps/what-is-access-management.md#requiring-user-assignment-for-an-app)
 
 **Change**
 
-For single tenant applications, a request to add/update AppId URI (identifierUris) will validate that domain in the value of URI is part of the verified domain list in the customer tenant or the value uses the default scheme (`api://{appId}`) provided by AAD.
-This could prevent applications from adding an AppId URI if the domain isn't in the verified domain list or value does not use the default scheme.
-To find more information on verified domains, refer to the [custom domains documentation](../../active-directory/fundamentals/add-custom-domain.md).
-
-The change does not affect existing applications using unverified domains in their AppID URI. It validates only new applications or when an existing application updates an identifier URIs or adds a new one to the identifierUri collection. The new restrictions apply only to URIs added to an app's identifierUris collection after 10/15/2021. AppId URIs already in an application's identifierUris collection when the restriction takes affect on 10/15/2021 will continue to function even if you add new URIs to that collection.
+Error 50105 (the current designation) is emitted when an unassigned user attempts to sign into an app that an admin has marked as requiring user assignment.  This is a common access control pattern, and users must often find an admin to request assignment to unblock access.  The error had a bug that would cause infinite loops in well-coded applications that correctly handled the `interaction_required` error response. `interaction_required` tells an app to perform interactive authentication, but even after doing so Azure AD would still return an `interaction_required` error response.  
 
-If a request fails the validation check, the application API for create/update will return a `400 badrequest` to the client indicating HostNameNotOnVerifiedDomain.
+The error scenario has been updated, so that during non-interactive authentication (where `prompt=none` is used to hide UX), the app will be instructed to perform interactive authentication using an `interaction_required` error response. In the subsequent interactive authentication, Azure AD will now hold the user and show an error message directly, preventing a loop from occuring. 
 
-[!INCLUDE [active-directory-identifierUri](../../../includes/active-directory-identifier-uri-patterns.md)]
+As a reminder, Azure AD does not support applications detecting individual error codes, such as checking strings for `AADSTS50105`. Instead, [Azure AD guidance](reference-aadsts-error-codes.md#handling-error-codes-in-your-application) is to follow the standards and use the [standardized authentication responses](https://openid.net/specs/openid-connect-core-1_0.html#AuthError) such as `interaction_required` and `login_required`. These are found in the standard `error` field in the response - the other fields are for human consumption during troubleshooting. 
 
-## June 2021
+You can review the current text of the 50105 error and more on the error lookup service: https://login.microsoftonline.com/error?code=50105 . 
 
-### The device code flow UX will now include an app confirmation prompt
+### AppId Uri in single tenant applications will require use of default scheme or verified domains
 
-**Effective date**: June 2021.
+**Effective date**: October 2021
 
 **Endpoints impacted**: v2.0 and v1.0
 
-**Protocol impacted**: The [device code flow](v2-oauth2-device-code.md)
+**Protocol impacted**: All flows
 
-As a security improvement, the device code flow has been updated to add an additional prompt, which validates that the user is signing into the app they expect. This is added to help prevent phishing attacks.
+**Change**
 
-The prompt that appears looks like this:
+For single tenant applications, a request to add/update AppId URI (identifierUris) will validate that domain in the value of URI is part of the verified domain list in the customer tenant or the value uses the default scheme (`api://{appId}`) provided by AAD.
+This could prevent applications from adding an AppId URI if the domain isn't in the verified domain list or value does not use the default scheme.
+To find more information on verified domains, refer to the [custom domains documentation](../../active-directory/fundamentals/add-custom-domain.md).
 
-:::image type="content" source="media/breaking-changes/device-code-flow-prompt.png" alt-text="New prompt, reading 'Are you trying to sign into the Azure CLI?'":::
+The change does not affect existing applications using unverified domains in their AppID URI. It validates only new applications or when an existing application updates an identifier URIs or adds a new one to the identifierUri collection. The new restrictions apply only to URIs added to an app's identifierUris collection after 10/15/2021. AppId URIs already in an application's identifierUris collection when the restriction takes affect on 10/15/2021 will continue to function even if you add new URIs to that collection.
+
+If a request fails the validation check, the application API for create/update will return a `400 badrequest` to the client indicating HostNameNotOnVerifiedDomain.
+
+[!INCLUDE [active-directory-identifierUri](../../../includes/active-directory-identifier-uri-patterns.md)]
+
+## August 2021
 
 ### Conditional Access will only trigger for explicitly requested scopes
 
@@ -93,6 +99,23 @@ If the app then requests `scope=files.readwrite`, the Conditional Access require
 
 If the app then makes one last request for any of the three scopes (say, `scope=tasks.read`), Azure AD will see that the user has already completed the Conditional access policies needed for `files.readwrite`, and again issue a token with all three permissions in it. 
 
+
+## June 2021
+
+### The device code flow UX will now include an app confirmation prompt
+
+**Effective date**: June 2021.
+
+**Endpoints impacted**: v2.0 and v1.0
+
+**Protocol impacted**: The [device code flow](v2-oauth2-device-code.md)
+
+As a security improvement, the device code flow has been updated to add an additional prompt, which validates that the user is signing into the app they expect. This is added to help prevent phishing attacks.
+
+The prompt that appears looks like this:
+
+:::image type="content" source="media/breaking-changes/device-code-flow-prompt.png" alt-text="New prompt, reading 'Are you trying to sign into the Azure CLI?'":::
+
 ## May 2020
 
 ### Bug fix: Azure AD will no longer URL-encode the state parameter twice

articles/active-directory/develop/v2-oauth2-auth-code-flow.md

@@ -18,11 +18,11 @@ ms.custom: aaddev, identityplatformtop40
 
 # Microsoft identity platform and OAuth 2.0 authorization code flow
 
-The OAuth 2.0 authorization code grant can be used in apps that are installed on a device to gain access to protected resources, such as web APIs. Using the Microsoft identity platform implementation of OAuth 2.0, you can add sign in and API access to your mobile and desktop apps.
+The OAuth 2.0 authorization code grant can be used in apps that are installed on a device to gain access to protected resources, such as web APIs. Using the Microsoft identity platform implementation of OAuth 2.0 and Open ID Connect (OIDC), you can add sign in and API access to your mobile and desktop apps.
 
 This article describes how to program directly against the protocol in your application using any language.  When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows).  Also take a look at the [sample apps that use MSAL](sample-v2-code.md).
 
-The OAuth 2.0 authorization code flow is described in [section 4.1 of the OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749). It's used to perform authentication and authorization in the majority of app types, including [single page apps](v2-app-types.md#single-page-apps-javascript), [web apps](v2-app-types.md#web-apps), and [natively installed apps](v2-app-types.md#mobile-and-native-apps). The flow enables apps to securely acquire access_tokens that can be used to access resources secured by the Microsoft identity platform, as well as refresh tokens to get additional access_tokens, and ID tokens for the signed in user.
+The OAuth 2.0 authorization code flow is described in [section 4.1 of the OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749). With OIDC, it's used to perform authentication and authorization in the majority of app types, including [single page apps](v2-app-types.md#single-page-apps-javascript), [web apps](v2-app-types.md#web-apps), and [natively installed apps](v2-app-types.md#mobile-and-native-apps). The flow enables apps to securely acquire access_tokens that can be used to access resources secured by the Microsoft identity platform, as well as refresh tokens to get additional access_tokens, and ID tokens for the signed in user.
 
 [!INCLUDE [try-in-postman-link](includes/try-in-postman-link.md)]
 

articles/active-directory/devices/hybrid-azuread-join-managed-domains.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: devices
 ms.topic: tutorial
-ms.date: 10/22/2021
+ms.date: 10/25/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -71,10 +71,9 @@ Hybrid Azure AD join requires devices to have access to the following Microsoft
 - `https://login.microsoftonline.com`
 - `https://device.login.microsoftonline.com`
 - `https://autologon.microsoftazuread-sso.com` (If you use or plan to use seamless SSO)
-- `https://enterpriseregistration.windows.net`
 
 > [!WARNING]
-> If your organization uses proxy servers that intercept SSL traffic for scenarios like data loss prevention or Azure AD tenant restrictions, ensure that traffic to 'https://device.login.microsoftonline.com' is excluded from TLS break-and-inspect. Failure to exclude 'https://device.login.microsoftonline.com' may cause interference with client certificate authentication, causing issues with device registration and device-based Conditional Access.
+> If your organization uses proxy servers that intercept SSL traffic for scenarios like data loss prevention or Azure AD tenant restrictions, ensure that traffic to `https://device.login.microsoftonline.com` and `https://enterpriseregistration.windows.net`is excluded from TLS break-and-inspect. Failure to exclude these URLs may cause interference with client certificate authentication, cause issues with device registration, and device-based Conditional Access.
 
 If your organization requires access to the internet via an outbound proxy, you can use [implementing Web Proxy Auto-Discovery (WPAD)](/previous-versions/tn-archive/cc995261(v=technet.10)) to enable Windows 10 computers for device registration with Azure AD. To address issues configuring and managing WPAD, see [Troubleshooting Automatic Detection](/previous-versions/tn-archive/cc302643(v=technet.10)). In Windows 10 devices prior to 1709 update, WPAD is the only available option to configure a proxy to work with Hybrid Azure AD join. 
 

articles/active-directory/manage-apps/manage-consent-requests.md

@@ -122,7 +122,7 @@ When a user grants consent on behalf of themselves, the following happens:
 
 1. A service principal for the client application is created, if does not already exist. A service principal is the instance of an application or a service, in your Azure AD tenant. Access granted to the app or service is associated with this service principal object.
 1. For each API to which the application requires access, a delegated permission grant is created for the permissions needed by the application to that API, for access on behalf of the user. A delegated permission grant authorizes an application to access an API on behalf of a user, when that user has signed in.
-1. The user is assigned the client application. Assigning the application to the user ensures the application is listed in the My Apps page for that user, allowing them to review and revoke the access granted an their behalf.
+1. The user is assigned the client application. Assigning the application to the user ensures the application is listed in the [My Apps](my-apps-deployment-plan.md) portal for that user, allowing them to review and revoke the access granted an their behalf.
 
 To manually perform the steps which are equivalent to granting consent to an application on behalf of one user, you will need the following details:
 

articles/app-service/app-service-asp-net-migration.md

@@ -54,3 +54,5 @@ Using App Service Migration Assistant, you can [migrate your standalone on-premi
 Some .NET Framework web applications may have dependencies to libraries and other capabilities not available in Azure App Service. These apps may rely on other components in the Global Assembly Cache. Previously, you could only run these applications on virtual machines. However, now you can run them in Azure App Service Windows Containers.
 
 The [app containerization tool](https://azure.microsoft.com/blog/accelerate-application-modernization-with-azure-migrate-app-containerization/) can repackage applications as containers with minimal changes. The tool currently supports containerizing ASP.NET applications and Apache Tomcat Java applications. For more information about containerization and migration, see the [how-to](../migrate/tutorial-app-containerization-aspnet-app-service.md).
+
+Next step:  [Migrate an on-premise web application to Azure App Service](https://docs.microsoft.com/learn/modules/migrate-app-service-migration-assistant/)