Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into new-collectors

Author: miashapan

.openpublishing.publish.config.json

@@ -386,6 +386,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "azureml-examples-mavaisma-r-azureml",
+      "url": "https://github.com/azure/azureml-examples",
+      "branch": "mavaisma-r-azureml",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "azureml-examples-v2samplesreorg",
       "url": "https://github.com/azure/azureml-examples",

articles/active-directory-b2c/TOC.yml

@@ -66,7 +66,7 @@
     - name: Authentication library
       href: ../active-directory/develop/msal-overview.md?bc=%2fazure%2factive-directory-b2c%2fbread%2ftoc.json&toc=%2fazure%2factive-directory-b2c%2fTOC.json
       displayName: MSAL, client library, Microsoft Authentication Library
-  - name: Azure AD B2C global identitiy framework
+  - name: Azure AD B2C global identity framework
     items:
       - name: Global identity solutions
         href: azure-ad-b2c-global-identity-solutions.md

articles/active-directory/develop/TOC.yml

@@ -812,6 +812,8 @@
           href: reply-url.md
         - name: Validation differences by supported account types
           href: supported-accounts-validation.md
+        - name: Configured permissions limits troubleshooting
+          href: troubleshoot-required-resource-access-limits.md
     - name: Microsoft auth libraries by app type
       displayName: MSAL, auth client library, SDK, token validation
       href: reference-v2-libraries.md

articles/active-directory/develop/howto-restrict-your-app-to-a-set-of-users.md

@@ -8,10 +8,10 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: how-to
-ms.date: 10/18/2021
+ms.date: 12/19/2022
 ms.author: kkrishna
 ms.reviewer: jmprieur
-ms.custom: aaddev
+ms.custom: aaddev, engagement-fy23
 #Customer intent: As a tenant administrator, I want to restrict an application that I have registered in Azuren-e AD to a select set of users available in my Azure AD tenant
 ---
 
@@ -38,14 +38,14 @@ The option to restrict an app to a specific set of users or security groups in a
 
 To update an application to require user assignment, you must be owner of the application under Enterprise apps, or be assigned one of **Global administrator**, **Application administrator**, or **Cloud application administrator** directory roles.
 
-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
+1. Sign in to the [Azure portal](https://portal.azure.com/)
 1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch the tenant in which you want to register an application.
 1. Search for and select **Azure Active Directory**.
 1. Under **Manage**, select **Enterprise Applications** > **All applications**.
 1. Select the application you want to configure to require assignment. Use the filters at the top of the window to search for a specific application.
 1. On the application's **Overview** page, under **Manage**, select **Properties**.
-1. Locate the setting **User assignment required?** and set it to **Yes**. When this option is set to **Yes**, users and services attempting to access the application or services must first be assigned for this application, or they won't be able to sign-in or obtain an access token.
-1. Select **Save**.
+1. Locate the setting **Assignment required?** and set it to **Yes**. When this option is set to **Yes**, users and services attempting to access the application or services must first be assigned for this application, or they won't be able to sign-in or obtain an access token.
+1. Select **Save** on the top bar.
 
 When an application requires assignment, user consent for that application isn't allowed. This is true even if users consent for that app would have otherwise been allowed. Be sure to [grant tenant-wide admin consent](../manage-apps/grant-admin-consent.md) to apps that require assignment.
 

articles/active-directory/develop/howto-v2-keychain-objc.md

@@ -9,10 +9,10 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/28/2019
+ms.date: 12/19/2022
 ms.author: owenrichards
 ms.reviewer: oldalton
-ms.custom: aaddev, has-adal-ref
+ms.custom: aaddev, has-adal-ref, engagement-fy23
 ---
 
 # Configure keychain
@@ -25,15 +25,15 @@ This article covers how to configure app entitlements so that MSAL can write cac
 
 ### iOS
 
-MSAL on iOS uses the `com.microsoft.adalcache` access group by default. This is the shared access group used by both MSAL and Azure AD Authentication Library (ADAL) SDKs and ensures the best single sign-on (SSO) experience between multiple apps from the same publisher.
+MSAL on iOS uses the `com.microsoft.adalcache` access group by default. This ensures the best SSO experience between multiple apps from the same publisher.
 
-On iOS, add the `com.microsoft.adalcache` keychain group to your app's entitlement in XCode under **Project settings** > **Capabilities** > **Keychain sharing**
+On iOS, add the `com.microsoft.adalcache` keychain group to your app's entitlement in XCode under **Project settings** > **Capabilities** > **Keychain sharing**.
 
 ### macOS
 
 MSAL on macOS uses `com.microsoft.identity.universalstorage` access group by default.
 
-Due to macOS keychain limitations, MSAL's `access group` doesn't directly translate to the keychain access group attribute (see [kSecAttrAccessGroup](https://developer.apple.com/documentation/security/ksecattraccessgroup?language=objc)) on macOS 10.14 and earlier. However, it behaves similarly from a SSO perspective by ensuring that multiple applications distributed by the same Apple developer can have silent SSO.
+Due to macOS keychain limitations, MSAL's `access group` doesn't directly translate to the keychain access group attribute (see [kSecAttrAccessGroup](https://developer.apple.com/documentation/security/ksecattraccessgroup?language=objc)) on macOS 10.14 and earlier. However, it behaves similarly from an SSO perspective by ensuring that multiple applications distributed by the same Apple developer can have silent SSO.
 
 On macOS 10.15 onwards (macOS Catalina), MSAL uses keychain access group attribute to achieve silent SSO, similarly to iOS.
 
@@ -52,7 +52,7 @@ config.cacheConfig.keychainSharingGroup = @"custom-group";
 
 MSALPublicClientApplication *application = [[MSALPublicClientApplication alloc] initWithConfiguration:config error:nil];
 
-// Now call acquiretoken. 
+// Now call `acquiretoken`. 
 // Tokens will be saved into the "custom-group" access group
 // and only shared with other applications declaring the same access group
 ```
@@ -101,7 +101,7 @@ Error -34018 normally means that the keychain hasn't been configured correctly.
 
 ## Ensure your application is properly signed
 
-On macOS, applications can execute without being signed by developer. While most of MSAL's functionality will continue to work, SSO through keychain access requires application to be signed. If you're experiencing multiple keychain prompts, make sure your application's signature is valid.
+On macOS, applications can execute without being signed by the developer. While most of MSAL's functionality will continue to work, SSO through keychain access requires application to be signed. If you're experiencing multiple keychain prompts, make sure your application's signature is valid.
 
 ## Next steps
 

articles/active-directory/develop/msal-client-applications.md

@@ -9,10 +9,10 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/26/2021
+ms.date: 12/19/2021
 ms.author: cwerner
 ms.reviewer: saeeda
-ms.custom: aaddev, has-adal-ref
+ms.custom: aaddev, has-adal-ref, engagement-fy23
 #Customer intent: As an application developer, I want to learn about the types of client apps so I can decide if this platform meets my app development requirements.
 ---
 

articles/active-directory/develop/msal-net-initializing-client-applications.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 11/23/2019
+ms.date: 12/19/2022
 ms.author: dmwendia
 ms.reviewer: saeeda
 ms.custom: "devx-track-csharp, aaddev, engagement-fy23"
@@ -22,19 +22,17 @@ This article describes initializing public client and confidential client applic
 
 With MSAL.NET 3.x, the recommended way to instantiate an application is by using the application builders: `PublicClientApplicationBuilder` and `ConfidentialClientApplicationBuilder`. They offer a powerful mechanism to configure the application from the code, a configuration file, or even by mixing both approaches.
 
-[API reference documentation](/dotnet/api/microsoft.identity.client) | [Package on NuGet](https://www.nuget.org/packages/Microsoft.Identity.Client/) | [Library source code](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet) | [Code samples](sample-v2-code.md)
-
 ## Prerequisites
 
-Before initializing an application, you first need to [register it](quickstart-register-app.md) so that your app can be integrated with the Microsoft identity platform. After registration, you may need the following information (which can be found in the Azure portal):
+Before initializing an application, you first need to register it so that your app can be integrated with the Microsoft identity platform. Refer to the [Quickstart: Register an application with the Microsoft identity platform](quickstart-register-app.md) for more information. After registration, you may need the following information (which can be found in the Azure portal):
 
 - **Application (client) ID** - This is a string representing a GUID.
 - **Directory (tenant) ID** - Provides identity and access management (IAM) capabilities to applications and resources used by your organization. It can specify if you're writing a line of business application solely for your organization (also named single-tenant application).
 - The identity provider URL (named the **instance**) and the sign-in audience for your application. These two parameters are collectively known as the authority.
-- **Client credentials** - which can take the form of an application secret (client secret string) or certificate (of type X509Certificate2) if it's a confidential client app.
+- **Client credentials** - which can take the form of an application secret (client secret string) or certificate (of type `X509Certificate2`) if it's a confidential client app.
 - For web apps, and sometimes for public client apps (in particular when your app needs to use a broker), you'll have also set the **Redirect URI** where the identity provider will contact back your application with the security tokens.
 
-## Ways to initialize applications
+## Initializing applications
 
 There are many different ways to instantiate client applications.
 
@@ -122,7 +120,7 @@ app = PublicClientApplicationBuilder.Create(clientId)
         .Build();
 ```
 
-Where it becomes interesting is that programming for national clouds has simplified. If you want your application to be a multi-tenant application in a national cloud, you could write, for instance:
+Programming for national clouds has simplified, so if you want your application to be a multi-tenant application in a national cloud, you could write, for instance:
 
 ```csharp
 IPublicClientApplication app;
@@ -131,7 +129,7 @@ app = PublicClientApplicationBuilder.Create(clientId)
         .Build();
 ```
 
-There's also an override for ADFS (ADFS 2019 is currently not supported):
+There's also an override for ADFS (MSAL.NET will only support ADFS 2019 or later):
 
 ```csharp
 IPublicClientApplication app;
@@ -149,6 +147,16 @@ app = PublicClientApplicationBuilder.Create(clientId)
         .Build();
 ```
 
+## See also
+
+[API reference documentation](/dotnet/api/microsoft.identity.client) 
+
+[Package on NuGet](https://www.nuget.org/packages/Microsoft.Identity.Client/)
+
+[Library source code](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet) 
+
+[Code samples](sample-v2-code.md)
+
 ## Next steps
 
 After you've initialized the client application, your next task is to add support for user sign-in, authorized API access, or both.

articles/active-directory/develop/scenario-daemon-overview.md

@@ -9,46 +9,44 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/14/2021
+ms.date: 12/19/2022
 ms.author: jmprieur
-ms.custom: aaddev, identityplatformtop40
+ms.custom: aaddev, identityplatformtop40, engagement-fy23
 #Customer intent: As an application developer, I want to know how to write a daemon app that can call web APIs by using the Microsoft identity platform.
 ---
 
 # Scenario: Daemon application that calls web APIs
 
-Learn all you need to build a daemon application that calls web APIs.
+This scenario will guide you to build a daemon application that calls web APIs.
 
 ## Overview
 
 Your application can acquire a token to call a web API on behalf of itself (not on behalf of a user). This scenario is useful for daemon applications. It uses the standard OAuth 2.0 [client credentials](v2-oauth2-client-creds-grant-flow.md) grant.
 
 ![Daemon apps](./media/scenario-daemon-app/daemon-app.svg)
 
-Here are some examples of use cases for daemon apps:
+Some examples of use cases for daemon apps include;
 
 - Web applications that are used to provision or administer users or do batch processes in a directory
 - Desktop applications (like Windows services on Windows or daemon processes on Linux) that perform batch jobs, or an operating system service that runs in the background
 - Web APIs that need to manipulate directories, not specific users
 
-There's another common case where non-daemon applications use client credentials: even when they act on behalf of users, they need to access a web API or a resource under their own identity for technical reasons. An example is access to secrets in Azure Key Vault or Azure SQL Database for a cache.
+There's another common case where non-daemon applications use client credentials, even when they act on behalf of users. This occurs when they need to access a web API or a resource under their own identity for technical reasons. An example is access to secrets in Azure Key Vault or Azure SQL Database for a cache.
 
-> [!NOTE]
-> You can't deploy a daemon application to a regular user's device, and a regular user can't access a daemon application. Only a limited set of IT administrators can access devices that have daemon applications running, so a bad actor can't access a client secret or token from device traffic and act on behalf of the daemon application. The daemon application scenario doesn't replace device authentication.
->
-> Examples of non-daemon applications:
-> - A mobile application that accesses a web service on behalf of an application, but not on behalf of a user.
-> - An IoT device that accesses a web service on behalf of a device, but not on behalf of a user.
->
+You can't deploy a daemon application to a regular user's device, and a regular user can't access a daemon application. Only a limited set of IT administrators can access devices that have daemon applications running. This is so that a bad actor can't access a client secret or token from device traffic and act on behalf of the daemon application. The daemon application scenario doesn't replace device authentication.
+
+Examples of non-daemon applications:
+- A mobile application that accesses a web service on behalf of an application, but not on behalf of a user.
+- An IoT device that accesses a web service on behalf of a device, but not on behalf of a user.
 
 Applications that acquire a token for their own identities:
 
-- Are confidential client applications. These apps, given that they access resources independently of users, need to prove their identity. They're also rather sensitive apps. They need to be approved by the Azure Active Directory (Azure AD) tenant admins.
+- Confidential client applications, given that they access resources independently of users, need to prove their identity. As they're rather sensitive apps, they need to be approved by the Azure Active Directory (Azure AD) tenant admins.
 - Have registered a secret (application password or certificate) with Azure AD. This secret is passed in during the call to Azure AD to get a token.
 
 ## Specifics
 
-Users can't interact with a daemon application. A daemon application requires its own identity. This type of application requests an access token by using its application identity and presenting its application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token (and a refresh token) from the Microsoft identity platform. This token is then used to call the web API (and is refreshed as needed).
+Users can't interact with a daemon application because it requires its own identity. This type of application requests an access token by using its application identity and presenting its application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token (and a refresh token) from the Microsoft identity platform. This token is then used to call the web API (and is refreshed as needed).
 
 Because users can't interact with daemon applications, incremental consent isn't possible. All the required API permissions need to be configured at application registration. The code of the application just requests statically defined permissions. This also means that daemon applications won't support incremental consent.
 

articles/active-directory/develop/scenario-protected-web-api-overview.md

@@ -9,26 +9,26 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/26/2021
+ms.date: 12/19/2022
 ms.author: jmprieur
-ms.custom: aaddev, identityplatformtop40
+ms.custom: aaddev, identityplatformtop40, engagement-fy23
 #Customer intent: As an application developer, I want to know how to write a protected web API using the Microsoft identity platform for developers.
 ---
 
 # Scenario: Protected web API
 
-In this scenario, you learn how to expose a web API. You also learn how to protect the web API so that only authenticated users can access it.
+In this scenario, you'll learn how to expose a web API and how to protect it so that only authenticated users can access it.
 
 To use your web API, you either enable authenticated users with both work and school accounts or enable Microsoft personal accounts.
 
 ## Specifics
 
-Here is specific information you need to know to protect web APIs:
+The specific information you need to know to protect web APIs are:
 
 - Your app registration must expose at least one _scope_ or one _application role_.
   - Scopes are exposed by web APIs that are called on behalf of a user.
-  - Application roles are exposed by web APIs called by daemon applications (that calls your web API on their own behalf).
-- If you create a new web API app registration, choose the [access token version](reference-app-manifest.md#accesstokenacceptedversion-attribute) accepted by your web API to `2`. For legacy web APIs, the accepted token version can be `null`, but this value restricts the sign-in audience to organizations only, and personal Microsoft accounts (MSA) won't be supported.
+  - Application roles are exposed by web APIs called by daemon applications (apps that call your web API on their own behalf).
+- If you create a new web API app registration, choose the [access token version](reference-app-manifest.md#accesstokenacceptedversion-attribute) accepted by your web API to the value of `2`. For legacy web APIs, the accepted token version can be `null`, but this value restricts the sign-in audience to organizations only, and personal Microsoft accounts (MSA) won't be supported.
 - The code configuration for the web API must validate the token used when the web API is called.
 - The code in the controller actions must validate the roles or scopes in the token.