Merge branch 'main' into release-ga-managed-grafana

Author: v-alje

articles/active-directory-b2c/TOC.yml

@@ -355,7 +355,7 @@
       items:
       - name: Multi-factor authentication
         href: multi-factor-authentication.md
-        displayName: TOTP, time-based-one-time password, time-based one-time password, authenticator app, Microsoft authenticator app, mfa, 2fa
+        displayName: TOTP, multi-factor, multifactor, time-based-one-time password, time-based one-time password, authenticator app, Microsoft authenticator app, mfa, 2fa
       - name: Partner integration
         items:
         - name: Asignio

articles/active-directory-b2c/json-transformations.md

@@ -152,7 +152,7 @@ The following example generates a JSON string based on the claim value of "email
   <InputClaims>
     <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="personalizations.0.to.0.email" />
     <InputClaim ClaimTypeReferenceId="otp" TransformationClaimType="personalizations.0.dynamic_template_data.otp" />
-    <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="personalizations.0.dynamic_template_data.verify-email" />
+    <InputClaim ClaimTypeReferenceId="copiedEmail" TransformationClaimType="personalizations.0.dynamic_template_data.verify-email" />
   </InputClaims>
   <InputParameters>
     <InputParameter Id="template_id" DataType="string" Value="d-4c56ffb40fa648b1aa6822283df94f60"/>
@@ -169,6 +169,7 @@ The following claims transformation outputs a JSON string claim that will be the
 
 - Input claims:
   - **email**,  transformation claim type  **personalizations.0.to.0.email**: "[email protected]"
+  - **copiedEmail**,  transformation claim type  **personalizations.0.dynamic_template_data.verify-email**: "[email protected]"
   - **otp**, transformation claim type **personalizations.0.dynamic_template_data.otp** "346349"
 - Input parameter:
   - **template_id**: "d-4c56ffb40fa648b1aa6822283df94f60"

articles/active-directory-b2c/openid-connect.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 04/12/2022
+ms.date: 08/12/2022
 ms.author: kengaderdus
 ms.subservice: B2C
 ms.custom: fasttrack-edit
@@ -43,7 +43,7 @@ client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
 &response_type=code+id_token
 &redirect_uri=https%3A%2F%2Fjwt.ms%2F
 &response_mode=fragment
-&scope=&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
+&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
 &state=arbitrary_data_you_can_receive_in_the_response
 &nonce=12345
 ```

articles/active-directory-b2c/user-flow-custom-attributes.md

@@ -143,9 +143,12 @@ You can create these attributes by using the portal UI before or after you use t
 
 |Name     |Used in |
 |---------|---------|
-|`extension_loyaltyId`  | Custom policy|
+|`extension_loyaltyId` | Custom policy|
 |`extension_<b2c-extensions-app-guid>_loyaltyId`  | [Microsoft Graph API](microsoft-graph-operations.md#application-extension-directory-extension-properties)|
 
+> [!NOTE] 
+> When using a custom attribute in custom policies, you must prefix the claim type ID with `extension_` to allow the correct data mapping to take place within the Azure AD B2C directory.
+
 The following example demonstrates the use of custom attributes in an Azure AD B2C custom policy claim definition.
 
 ```xml

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

@@ -98,7 +98,7 @@ Here are examples of possible distributed caches:
 services.Configure<MsalDistributedTokenCacheAdapterOptions>(options => 
   {
     // Optional: Disable the L1 cache in apps that don't use session affinity
-    //                 by setting DisableL1Cache to 'false'.
+    //                 by setting DisableL1Cache to 'true'.
     options.DisableL1Cache = false;
 
     // Or limit the memory (by default, this is 500 MB)

articles/active-directory/hybrid/reference-connect-faq.yml

@@ -143,7 +143,7 @@ sections:
       - question: |
           Are single label domains (SLDs) supported?  
         answer: |
-          While we strongly recommend against this network configuration ([see article](https://support.microsoft.com/help/2269810/microsoft-support-for-single-label-domains)), using Azure AD Connect sync with a single label domain is supported, as long as the network configuration for the single level domain is functioning correctly.
+          While we strongly recommend against this network configuration ([see article](https://support.microsoft.com/help/2269810/microsoft-support-for-single-label-domains)), using Azure AD Connect sync with a single label domain is supported, as long as the network configuration for the single level domain is functioning correctly. In SLD scenarios where the Active Directory NetBIOS domain name differs from the FQDN domain name, it's unsupported to install Azure AD Connect.
           
       - question: |
           Are Forests with disjoint AD domains supported?  

articles/active-directory/manage-apps/datawiza-azure-ad-sso-oracle-jde.md

@@ -98,7 +98,7 @@ To integrate Oracle JDE with Azure AD:
    |:-----|:-------|
    | Platform | Web |
    | App Name | Enter a unique application name.|
-   | Public Domain | For example: https:/jde-external.example.com. <br>For testing, you can use localhost DNS. If you aren't deploying DAB behind a load balancer, use the **Public Domain** port. |
+   | Public Domain | For example: `https://jde-external.example.com`. <br>For testing, you can use localhost DNS. If you aren't deploying DAB behind a load balancer, use the **Public Domain** port. |
    | Listen Port | The port that DAB listens on.|
    | Upstream Servers | The Oracle JDE implementation URL and port to be protected.|
 

articles/active-directory/saas-apps/tickitlms-learn-tutorial.md

@@ -73,7 +73,7 @@ Follow these steps to enable Azure AD SSO in the Azure portal.
 1. Click **Set additional URLs** and perform the following step if you wish to configure the application in **SP** initiated mode:
 
    In the **Sign-on URL** text box, type the URL:
-   `https:/learn.tickitlms.com/sso/login`
+   `https://learn.tickitlms.com/sso/login`
 
 1. Click **Save**.
 

articles/active-directory/verifiable-credentials/admin-api.md

@@ -1048,17 +1048,17 @@ Don't supply a request body for this method.
 
 example message:
 
-```
+```json
 {
-    value:
+    "value":
     [
         {
             "id": "ZjViZjJmYzYtNzEzNS00ZDk0LWE2ZmUtYzI2ZTQ1NDNiYzVhPHNjcmlwdD5hbGVydCgneWF5IScpOzwvc2NyaXB0Pg",
             "name": "test1",
             "authorityId": "ffea7eb3-0000-1111-2222-000000000000",
             "status": "Enabled",
             "issueNotificationEnabled": false,
-            "manifestUrl" : "https:/...",
+            "manifestUrl" : "https://...",
             "rules": "<rules JSON>",
             "displays": [{<display JSON}]
         },
@@ -1068,7 +1068,7 @@ example message:
             "authorityId": "cc55ba22-0000-1111-2222-000000000000",
             "status": "Enabled",
             "issueNotificationEnabled": false,
-            "manifestUrl" : "https:/...",
+            "manifestUrl" : "https://...",
             "rules": "<rules JSON>",
             "displays": [{<display JSON}]
         }

articles/aks/certificate-rotation.md

@@ -11,7 +11,7 @@ ms.date: 5/10/2022
 Azure Kubernetes Service (AKS) uses certificates for authentication with many of its components. If you have a RBAC-enabled cluster built after March 2022 it is enabled with certificate auto-rotation. Periodically, you may need to rotate those certificates for security or policy reasons. For example, you may have a policy to rotate all your certificates every 90 days.
 
 > [!NOTE]
-> Certificate auto-rotation will not be enabled by default for non-RBAC enabled AKS clusters.
+> Certificate auto-rotation will *only* be enabled by default for RBAC enabled AKS clusters. 
 
 This article shows you how certificate rotation works in your AKS cluster.
 
@@ -55,10 +55,11 @@ az vmss run-command invoke -g MC_rg_myAKSCluster_region -n vmss-name --instance-
 
 ## Certificate Auto Rotation
 
-For AKS to automatically rotate non-CA certificates, the cluster must have [TLS Bootstrapping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) which has been enabled by default in all Azure regions.
+For AKS to automatically rotate non-CA certificates, the cluster must have [TLS Bootstrapping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) which has been enabled by default in all Azure regions. 
 
 > [!Note]
 > If you have an existing cluster you have to upgrade that cluster to enable Certificate Auto-Rotation.
+> Do not disable bootstrap to keep your auto-rotation enabled. 
 
 For any AKS clusters created or upgraded after March 2022 Azure Kubernetes Service will automatically rotate non-CA certificates on both the control plane and agent nodes within 80% of the client certificate valid time, before they expire with no downtime for the cluster.
 
@@ -82,7 +83,7 @@ az aks upgrade -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
 
 ### Limitation
 
-Auto certificate rotation won't be enabled on a non-RBAC cluster.
+Certificate auto-rotation will only be enabled by default for RBAC enabled AKS clusters.
 
 ## Manually rotate your cluster certificates