Merge branch 'main' into cost-optimization-bookmarks

Author: bwren

.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-create-self-signed-certificate.md

@@ -18,7 +18,7 @@ ms.custom: scenarios:getting-started, engagement-fy23
 
 # Create a self-signed public certificate to authenticate your application
 
-Azure Active Directory (Azure AD) supports two types of authentication for service principals: **password-based authentication** (app secret) and **certificate-based authentication**. While app secrets can easily be created in the Azure portal, they're long-lived, and not as secure as certificates. It's therefore recommended that your application uses a certificate rather than a secret.
+Azure Active Directory (Azure AD) supports two types of authentication for service principals: **password-based authentication** (app secret) and **certificate-based authentication**. While app secrets can easily be created in the Azure portal or using a Microsoft API like Microsoft Graph, they're long-lived, and not as secure as certificates. It's therefore recommended that your application uses a certificate rather than a secret.
 
 For testing, you can use a self-signed public certificate instead of a Certificate Authority (CA)-signed certificate. In this how-to, you'll use Windows PowerShell to create and export a self-signed certificate.
 
@@ -27,9 +27,9 @@ For testing, you can use a self-signed public certificate instead of a Certifica
 
 While creating the certificate using PowerShell, you can specify parameters like cryptographic and hash algorithms, certificate validity period, and domain name. The certificate can then be exported with or without its private key depending on your application needs. 
 
-The application that initiates the authentication session requires the private key while the application that confirms the authentication requires the public key. So, if you're authenticating from your PowerShell desktop app to Azure AD, you only export the public key (*.cer* file) and upload it to the Azure portal. The PowerShell app uses the private key from your local certificate store to initiate authentication and obtain access tokens for Microsoft Graph.
+The application that initiates the authentication session requires the private key while the application that confirms the authentication requires the public key. So, if you're authenticating from your PowerShell desktop app to Azure AD, you only export the public key (*.cer* file) and upload it to the Azure portal. The PowerShell app uses the private key from your local certificate store to initiate authentication and obtain access tokens for calling Microsoft APIs like Microsoft Graph.
 
-Your application may also be running from another machine, such as Azure Automation. In this scenario, you export the public and private key pair from your local certificate store, upload the public key to the Azure portal, and the private key (a *.pfx* file) to Azure Automation. Your application running in Azure Automation will use the private key to initiate authentication and obtain access tokens for Microsoft Graph.
+Your application may also be running from another machine, such as Azure Automation. In this scenario, you export the public and private key pair from your local certificate store, upload the public key to the Azure portal, and the private key (a *.pfx* file) to Azure Automation. Your application running in Azure Automation will use the private key to initiate authentication and obtain access tokens for calling Microsoft APIs like Microsoft Graph.
 
 This article uses the `New-SelfSignedCertificate` PowerShell cmdlet to create the self-signed certificate and the `Export-Certificate` cmdlet to export it to a location that is easily accessible. These cmdlets are built-in to modern versions of Windows (Windows 8.1 and greater, and Windows Server 2012R2 and greater). The self-signed certificate will have the following configuration:
 
@@ -54,7 +54,9 @@ $cert = New-SelfSignedCertificate -Subject "CN=$certname" -CertStoreLocation "Ce
 
 ```
 
-The `$cert` variable in the previous command stores your certificate in the current session and allows you to export it. The command below exports the certificate in *.cer* format. You can also export it in other formats supported on the Azure portal including *.pem* and *.crt*.
+The `$cert` variable in the previous command stores your certificate in the current session and allows you to export it.
+
+The command below exports the certificate in *.cer* format. You can also export it in other formats supported on the Azure portal including *.pem* and *.crt*.
 
 ```powershell
 

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.