Merge pull request #190476 from MicrosoftDocs/main

3/03 AM Publish

Author: huypub

articles/active-directory-b2c/tokens-overview.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 02/11/2022
+ms.date: 03/03/2022
 ms.author: kengaderdus
 ms.subservice: B2C
 ms.custom: b2c-support
@@ -26,9 +26,11 @@ Azure AD B2C supports the [OAuth 2.0 and OpenID Connect protocols](protocols-ove
 
 The following tokens are used in communication with Azure AD B2C:
 
-- **ID token** - A JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They are commonly used to display account information or to make access control decisions in an application. ID tokens are signed, but they are not encrypted. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Your application or API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
-- **Access token** -  A JWT that contains claims that you can use to identify the granted permissions to your APIs. Access tokens are signed, but they aren't encrypted. Access tokens are used to provide access to APIs and resource servers.  When your API receives an access token, it must validate the signature to prove that the token is authentic. Your API must also validate a few claims in the token to prove that it is valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
-- **Refresh token** - Refresh tokens are used to acquire new ID tokens and access tokens in an OAuth 2.0 flow. They provide your application with long-term access to resources on behalf of users without requiring interaction with those users. Refresh tokens are opaque to your application. They are issued by Azure AD B2C and can be inspected and interpreted only by Azure AD B2C. They are long-lived, but your application shouldn't be written with the expectation that a refresh token will last for a specific period of time. Refresh tokens can be invalidated at any moment for a variety of reasons. The only way for your application to know if a refresh token is valid is to attempt to redeem it by making a token request to Azure AD B2C. When you redeem a refresh token for a new token, you receive a new refresh token in the token response. Save the new refresh token. It replaces the refresh token that you previously used in the request. This action helps guarantee that your refresh tokens remain valid for as long as possible. Note that single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser).
+- **ID token** - A JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They're commonly used to display account information or to make access control decisions in an application. ID tokens are signed, but the're not encrypted. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Your application or API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
+
+- **Access token** -  A JWT that contains claims that you can use to identify the granted permissions to your APIs. Access tokens are signed, but they aren't encrypted. Access tokens are used to provide access to APIs and resource servers.  When your API receives an access token, it must validate the signature to prove that the token is authentic. Your API must also validate a few claims in the token to prove that it's valid. Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
+
+- **Refresh token** - Refresh tokens are used to acquire new ID tokens and access tokens in an OAuth 2.0 flow. They provide your application with long-term access to resources on behalf of users without requiring interaction with those users. Refresh tokens are opaque to your application. They're issued by Azure AD B2C and can be inspected and interpreted only by Azure AD B2C. They're long-lived, but your application shouldn't be written with the expectation that a refresh token will last for a specific period of time. Refresh tokens can be invalidated at any moment for a variety of reasons. The only way for your application to know if a refresh token is valid is to attempt to redeem it by making a token request to Azure AD B2C. When you redeem a refresh token for a new token, you receive a new refresh token in the token response. Save the new refresh token. It replaces the refresh token that you previously used in the request. This action helps guarantee that your refresh tokens remain valid for as long as possible. Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser). 
 
 ## Endpoints
 
@@ -133,7 +135,7 @@ The metadata document for the `B2C_1_signupsignin1` policy in the `contoso.onmic
 https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration
 ```
 
-To determine which policy was used to sign a token (and where to go to request the metadata), you have two options. First, the policy name is included in the `tfp` (default) or `acr` claim (as configured) in the token. You can parse claims out of the body of the JWT by base-64 decoding the body and deserializing the JSON string that results. The `tfp` or `acr` claim is the name of the policy that was used to issue the token. The other option is to encode the policy in the value of the `state` parameter when you issue the request, and then decode it to determine which policy was used. Either method is valid.
+To determine which policy was used to sign a token (and where to go to request the metadata), you've two options. First, the policy name is included in the `tfp` (default) or `acr` claim (as configured) in the token. You can parse claims out of the body of the JWT by base-64 decoding the body and deserializing the JSON string that results. The `tfp` or `acr` claim is the name of the policy that was used to issue the token. The other option is to encode the policy in the value of the `state` parameter when you issue the request, and then decode it to determine which policy was used. Either method is valid.
 
 Azure AD B2C uses the RS256 algorithm, which is based on the [RFC 3447](https://www.rfc-editor.org/rfc/rfc3447#section-3.1) specification. The public key consists of two components: the RSA modulus (`n`) and the RSA public exponent (`e`). You can programmatically convert `n` and `e` values to a certificate format for token validation.
 

articles/active-directory/devices/assign-local-admin.md

@@ -21,7 +21,7 @@ ms.collection: M365-identity-device-management
 
 To manage a Windows device, you need to be a member of the local administrators group. As part of the Azure Active Directory (Azure AD) join process, Azure AD updates the membership of this group on a device. You can customize the membership update to satisfy your business requirements. A membership update is, for example, helpful if you want to enable your helpdesk staff to do tasks requiring administrator rights on a device.
 
-This article explains how the local administrators membership update works and how you can customize it during an Azure AD Join. The content of this article doesn't apply to a **hybrid Azure AD joined** devices.
+This article explains how the local administrators membership update works and how you can customize it during an Azure AD Join. The content of this article doesn't apply to **hybrid Azure AD joined** devices.
 
 ## How it works
 

articles/aks/custom-node-configuration.md

@@ -129,6 +129,8 @@ The settings below can be used to tune the operation of the virtual memory (VM)
 | `transparentHugePageEnabled` | `always`, `madvise`, `never` | `always` | [Transparent Hugepages](https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html#admin-guide-transhuge) is a Linux kernel feature intended to improve performance by making more efficient use of your processor’s memory-mapping hardware. When enabled the kernel attempts to allocate `hugepages` whenever possible and any Linux process will receive 2-MB pages if the `mmap` region is 2 MB naturally aligned. In certain cases when `hugepages` are enabled system wide, applications may end up allocating more memory resources. An application may `mmap` a large region but only touch 1 byte of it, in that case a 2-MB page might be allocated instead of a 4k page for no good reason. This scenario is why it's possible to disable `hugepages` system-wide or to only have them inside `MADV_HUGEPAGE madvise` regions. | 
 | `transparentHugePageDefrag` | `always`, `defer`, `defer+madvise`, `madvise`, `never` | `madvise` | This value controls whether the kernel should make aggressive use of memory compaction to make more `hugepages` available. | 
 
+
+
 > [!IMPORTANT]
 > For ease of search and readability the OS settings are displayed in this document by their name but should be added to the configuration json file or AKS API using [camelCase capitalization convention](/dotnet/standard/design-guidelines/capitalization-conventions).
 
@@ -182,6 +184,28 @@ Add a new node pool specifying the Kubelet parameters using the JSON file you cr
 az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --kubelet-config ./kubeletconfig.json
 ```
 
+
+## Other configuration
+
+The settings below can be used to modify other Operating System settings.
+
+### Message of the Day
+
+Pass the ```--message-of-the-day``` flag with the location of the file to replace the Message of the Day on Linux nodes at cluster  creation or node pool creation.
+
+
+#### Cluster creation
+```azurecli
+az aks create --cluster-name myAKSCluster --resource-group myResourceGroup --message-of-the-day ./newMOTD.txt
+```
+
+#### Nodepool creation
+```azurecli
+az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --message-of-the-day ./newMOTD.txt
+```
+
+
+
 ## Next steps
 
 - Learn [how to configure your AKS cluster](cluster-configuration.md).

articles/aks/open-service-mesh-deploy-addon-az-cli.md

@@ -1,15 +1,15 @@
 ---
-title: Install the Open Service Mesh (OSM) add-on using Azure CLI
-description: Install Open Service Mesh (OSM) Azure Kubernetes Service (AKS) add-on using Azure CLI
+title: Install the Open Service Mesh add-on by using the Azure CLI
+description: Use Azure CLI commands to install the Open Service Mesh (OSM) add-on on an Azure Kubernetes Service (AKS) cluster.
 services: container-service
 ms.topic: article
 ms.date: 11/10/2021
 ms.author: pgibson
 ---
 
-# Install the Open Service Mesh (OSM) Azure Kubernetes Service (AKS) add-on using Azure CLI
+# Install the Open Service Mesh add-on by using the Azure CLI
 
-This article shows you how to install the OSM add-on on an AKS cluster and verify it is installed and running.
+This article shows you how to install the Open Service Mesh (OSM) add-on on an Azure Kubernetes Service (AKS) cluster and verify that it's installed and running.
 
 > [!IMPORTANT]
 > The OSM add-on installs version *1.0.0* of OSM on your cluster.
@@ -19,11 +19,11 @@ This article shows you how to install the OSM add-on on an AKS cluster and verif
 * An Azure subscription. If you don't have an Azure subscription, you can create a [free account](https://azure.microsoft.com/free).
 * [Azure CLI installed](/cli/azure/install-azure-cli).
 
-## Install the OSM AKS add-on on your cluster
+## Install the OSM add-on on your cluster
 
-To install the OSM AKS add-on, use `--enable-addons open-service-mesh` when creating or updating a cluster.
+To install the OSM add-on, use `--enable-addons open-service-mesh` when creating or updating a cluster.
 
-The following example creates a *myResourceGroup* resource group. Then creates a *myAKSCluster* cluster with a three nodes and the OSM add-on.
+The following example creates a *myResourceGroup* resource group. Then it creates a *myAKSCluster* cluster with three nodes and the OSM add-on.
 
 ```azurecli-interactive
 az group create --name myResourceGroup --location eastus
@@ -34,7 +34,7 @@ az aks create \
   --enable-addons open-service-mesh
 ```
 
-For existing clusters, use `az aks enable-addons`. For example:
+For existing clusters, use `az aks enable-addons`. The following code shows an example.
 
 > [!IMPORTANT]
 > You can't enable the OSM add-on on an existing cluster if an OSM mesh is already on your cluster. Uninstall any existing OSM meshes on your cluster before enabling the OSM add-on.
@@ -48,25 +48,23 @@ az aks enable-addons \
 
 ## Get the credentials for your cluster
 
-Get the credentials for your AKS cluster using the `az aks get-credentials` command. The following example command gets the credentials for the *myAKSCluster* in the *myResourceGroup* resource group.
+Get the credentials for your AKS cluster by using the `az aks get-credentials` command. The following example command gets the credentials for *myAKSCluster* in the *myResourceGroup* resource group:
 
 ```azurecli-interactive
 az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
 ```
 
-## Verify the OSM add-on is installed on your cluster
+## Verify that the OSM add-on is installed on your cluster
 
-To see if the OSM add-on is enabled on your cluster, verify the *enabled* value shows a *true* for *openServiceMesh* under *addonProfiles*. The following example shows the status of the OSM add-on for the *myAKSCluster* in *myResourceGroup*.
+To see if the OSM add-on is installed on your cluster, verify that the `enabled` value is `true` for `openServiceMesh` under `addonProfiles`. The following example shows the status of the OSM add-on for *myAKSCluster* in *myResourceGroup*:
 
 ```azurecli-interactive
 az aks show --resource-group myResourceGroup --name myAKSCluster  --query 'addonProfiles.openServiceMesh.enabled'
 ```
 
-## Verify the OSM mesh is running on your cluster
+## Verify that the OSM mesh is running on your cluster
 
-In addition to verifying the OSM add-on has been enabled on your cluster, you can also verify the version, status, and configuration of the OSM mesh running on your cluster.
-
-To verify the version of the OSM mesh running on your cluster, use `kubectl` to display the image version of the *osm-controller* deployment. For example:
+You can verify the version, status, and configuration of the OSM mesh that's running on your cluster. Use `kubectl` to display the image version of the *osm-controller* deployment. For example:
 
 ```azurecli-interactive
 kubectl get deployment -n kube-system osm-controller -o=jsonpath='{$.spec.template.spec.containers[:1].image}'
@@ -79,7 +77,7 @@ $ kubectl get deployment -n kube-system osm-controller -o=jsonpath='{$.spec.temp
 mcr.microsoft.com/oss/openservicemesh/osm-controller:v0.11.1
 ```
 
-To verify the status of the OSM components running on your cluster, use `kubectl` to show the status of the *app.kubernetes.io/name=openservicemesh.io* deployments, pods, and services. For example:
+To verify the status of the OSM components running on your cluster, use `kubectl` to show the status of the `app.kubernetes.io/name=openservicemesh.io` deployments, pods, and services. For example:
 
 ```azurecli-interactive
 kubectl get deployments -n kube-system --selector app.kubernetes.io/name=openservicemesh.io
@@ -88,15 +86,15 @@ kubectl get services -n kube-system --selector app.kubernetes.io/name=openservic
 ```
 
 > [!IMPORTANT]
-> If any pods have a status other than *Running*, such as *Pending*, your cluster may not have enough resources to run OSM. Review the sizing for your cluster, such as the number of nodes and the VM SKU, before continuing to use OSM on your cluster.
+> If any pods have a status other than `Running`, such as `Pending`, your cluster might not have enough resources to run OSM. Review the sizing for your cluster, such as the number of nodes and the virtual machine's SKU, before continuing to use OSM on your cluster.
 
 To verify the configuration of your OSM mesh, use `kubectl get meshconfig`. For example:
 
 ```azurecli-interactive
 kubectl get meshconfig osm-mesh-config -n kube-system -o yaml
 ```
 
-The following sample output shows the configuration of an OSM mesh:
+The following example output shows the configuration of an OSM mesh:
 
 ```yaml
 apiVersion: config.openservicemesh.io/v1alpha1
@@ -142,27 +140,25 @@ spec:
     useHTTPSIngress: false
 ```
 
-The above example output shows `enablePermissiveTrafficPolicyMode: true`, which means OSM has a permissive traffic policy mode enabled. With permissive traffic mode enabled in your OSM mesh:
+The preceding example shows `enablePermissiveTrafficPolicyMode: true`, which means OSM has permissive traffic policy mode enabled. With this mode enabled in your OSM mesh:
 
 * The [SMI][smi] traffic policy enforcement is bypassed.
 * OSM automatically discovers services that are a part of the service mesh.
 * OSM creates traffic policy rules on each Envoy proxy sidecar to be able to communicate with these services.
 
-
-
 ## Delete your cluster
 
-When the cluster is no longer needed, use the `az group delete` command to remove the resource group, cluster, and all related resources.
+When you no longer need the cluster, use the `az group delete` command to remove the resource group, the cluster, and all related resources:
 
 ```azurecli-interactive
 az group delete --name myResourceGroup --yes --no-wait
 ```
 
-Alternatively, you can uninstall the OSM add-on and the related resources from your cluster. For more information, see [Uninstall the Open Service Mesh (OSM) add-on from your AKS cluster][osm-uninstall].
+Alternatively, you can uninstall the OSM add-on and the related resources from your cluster. For more information, see [Uninstall the Open Service Mesh add-on from your AKS cluster][osm-uninstall].
 
 ## Next steps
 
-This article showed you how to install the OSM add-on on an AKS cluster and verify it is installed and running. With the OSM add-on on your cluster you can [Deploy a sample application][osm-deploy-sample-app] or [Onboard an existing application][osm-onboard-app] to work with your OSM mesh.
+This article showed you how to install the OSM add-on on an AKS cluster, and then verify that it's installed and running. With the OSM add-on installed on your cluster, you can [deploy a sample application][osm-deploy-sample-app] or [onboard an existing application][osm-onboard-app] to work with your OSM mesh.
 
 [aks-ephemeral]: cluster-configuration.md#ephemeral-os
 [osm-sample]: open-service-mesh-deploy-new-application.md