update headers, acrolinx fixes

Author: Dan Crank

articles/operator-nexus/howto-baremetal-bmc-ssh.md

@@ -1,11 +1,11 @@
 ---
 title: Manage emergency access to a bare metal machine using the `az networkcloud cluster bmckeyset` command for Azure Operator Nexus
 description: Step by step guide on using the `az networkcloud cluster bmckeyset` command to manage emergency access to a bare metal machine.
-author: eak13
-ms.author: ekarandjeff
+author: DanCrank
+ms.author: danielcrank
 ms.service: azure-operator-nexus
 ms.topic: how-to
-ms.date: 05/05/2023
+ms.date: 06/12/2024
 ms.custom: template-how-to, devx-track-azurecli
 ---
 
@@ -16,17 +16,17 @@ ms.custom: template-how-to, devx-track-azurecli
 
 There are rare situations where a user needs to investigate & resolve issues with a bare metal machine and all other ways using Azure are exhausted. Operator Nexus provides the `az networkcloud cluster bmckeyset` command so users can manage SSH access to the baseboard management controller (BMC) on these bare metal machines. On keyset creation, users are validated against Microsoft Entra ID for proper authorization by cross referencing the User Principal Name provided for a user against the supplied Azure Group ID `--azure-group-id <Entra Group ID>`.
 
-Users in a keyset are validated every four hours, and also when any changes are made to any keyset. Each user's status is then set to "Active" or "Invalid". Invalid users remain in the keyset but their keys are removed from all hosts and they are not allowed to log in. Reasons for a user being invalid are:
-- The user's User Principal Name is not a member of the given Entra group (if specified)
-- The given Entra group (if specified) does not exist (in which case all users in the keyset are invalid)
-- The keyset has expired (in which case all users in the keyset are invalid)
+Users in a keyset are validated every four hours, and also when any changes are made to any keyset. Each user's status is then set to "Active" or "Invalid." Invalid users remain in the keyset but their keys are removed from all hosts and they aren't allowed access. Reasons for a user being invalid are:
+- The user's User Principal Name isn't a member of the given Entra group (if specified)
+- The given Entra group (if specified) doesn't exist (in which case all users in the keyset are invalid)
+- The keyset is expired (in which case all users in the keyset are invalid)
 
 > [!NOTE]
 > There is currently a transitional period where specifying User Principal Names is optional. In a future release, it will become mandatory and Microsoft Entra ID validation will be enforced for all users. Users are encouraged to add User Principal Names to their keysets before the transitional period ends (planned for July 2024) to avoid keysets being invalidated. Note that if any User Principal Names are added to a keyset, even if they are not added for all users, Microsoft Entra ID validation will be enabled, and this will result in the entire keyset being invalidated if the Group ID specified is not valid.
 
 The keyset and each individual user also have detailed status messages communicating other information:
 - The keyset's detailedStatusMessage tells you whether the keyset is expired, and other information about problems encountered while updating the keyset across the cluster.
-- The user's statusMessage tells you whether the user is active or invalid (with the reason why, if invalid), and a list of baremetal machines which have not yet updated to the user's latest active/invalid state (with the reasons why).
+- The user's statusMessage tells you whether the user is active or invalid, and a list of machines that aren't yet updated to the user's latest active/invalid state. In each case, causes of problems are included if known.
 
 When the command runs, it executes on each bare metal machine in the Cluster with an active Kubernetes node. There's a reconciliation process that runs periodically that retries the command on any bare metal machine that wasn't available at the time of the original command. Also, any bare metal machine that returns to the cluster via an `az networkcloud baremetalmachine actionreimage` or `az networkcloud baremetalmachine actionreplace` command (see [BareMetal functions](./howto-baremetal-functions.md)) sends a signal causing any active keysets to be sent to the machine as soon as it returns to the cluster. Multiple commands execute in the order received.
 

articles/operator-nexus/howto-baremetal-bmm-ssh.md

@@ -1,11 +1,11 @@
 ---
 title: Manage emergency access to a bare metal machine using the `az networkcloud cluster baremetalmachinekeyset` command for Azure Operator Nexus
 description: Step by step guide on using the `az networkcloud cluster baremetalmachinekeyset` command to manage emergency access to a bare metal machine.
-author: eak13
-ms.author: ekarandjeff
+author: DanCrank
+ms.author: danielcrank
 ms.service: azure-operator-nexus
 ms.topic: how-to
-ms.date: 04/18/2023
+ms.date: 06/12/2024
 ms.custom: template-how-to, devx-track-azurecli
 ---
 
@@ -16,17 +16,17 @@ ms.custom: template-how-to, devx-track-azurecli
 
 There are rare situations where a user needs to investigate & resolve issues with a bare metal machine and all other ways via Azure are exhausted. Azure Operator Nexus provides the `az networkcloud cluster baremetalmachinekeyset` command so users can manage SSH access to these bare metal machines. On keyset creation, users are validated against Microsoft Entra ID for proper authorization by cross referencing the User Principal Name provided for a user against the supplied Microsoft Entra Group ID `--azure-group-id <Entra Group ID>`.
 
-Users in a keyset are validated every four hours, and also when any changes are made to any keyset. Each user's status is then set to "Active" or "Invalid". Invalid users remain in the keyset but their keys are removed from all hosts and they are not allowed to log in. Reasons for a user being invalid are:
-- The user's User Principal Name is not a member of the given Entra group (if specified)
-- The given Entra group (if specified) does not exist (in which case all users in the keyset are invalid)
-- The keyset has expired (in which case all users in the keyset are invalid)
+Users in a keyset are validated every four hours, and also when any changes are made to any keyset. Each user's status is then set to "Active" or "Invalid." Invalid users remain in the keyset but their keys are removed from all hosts and they aren't allowed access. Reasons for a user being invalid are:
+- The user's User Principal Name isn't a member of the given Entra group (if specified)
+- The given Entra group (if specified) doesn't exist (in which case all users in the keyset are invalid)
+- The keyset is expired (in which case all users in the keyset are invalid)
 
 > [!NOTE]
 > There is currently a transitional period where specifying User Principal Names is optional. In a future release, it will become mandatory and Microsoft Entra ID validation will be enforced for all users. Users are encouraged to add User Principal Names to their keysets before the transitional period ends (planned for July 2024) to avoid keysets being invalidated. Note that if any User Principal Names are added to a keyset, even if they are not added for all users, Microsoft Entra ID validation will be enabled, and this will result in the entire keyset being invalidated if the Group ID specified is not valid.
 
 The keyset and each individual user also have detailed status messages communicating other information:
 - The keyset's detailedStatusMessage tells you whether the keyset is expired, and other information about problems encountered while updating the keyset across the cluster.
-- The user's statusMessage tells you whether the user is active or invalid (with the reason why, if invalid), and a list of baremetal machines which have not yet updated to the user's latest active/invalid state (with the reasons why).
+- The user's statusMessage tells you whether the user is active or invalid, and a list of machines that aren't yet updated to the user's latest active/invalid state. In each case, causes of problems are included if known.
 
 When the command runs, it executes on each bare metal machine in the Cluster with an active Kubernetes node. There's a reconciliation process that runs periodically that retries the command on any bare metal machine that wasn't available at the time of the original command. Also, any bare metal machine that returns to the cluster via an `az networkcloud baremetalmachine reimage` or `az networkcloud baremetalmachine replace` command (see [BareMetal functions](./howto-baremetal-functions.md)) sends a signal causing any active keysets to be sent to the machine as soon as it returns to the cluster. Multiple commands execute in the order received.
 
@@ -37,8 +37,8 @@ There's no limit to the number of users in a group.
 
 - The keyset create/update process adds the jump host IP addresses to the IP tables for each machine in the Cluster. The IP tables update restricts SSH access to be allowed only from those jump hosts.
 - It's important to specify the Cluster facing IP addresses for the jump hosts. These IP addresses might be different than the public facing IP address used to access the jump host.
-- While at least one baremetal machine keyset is defined, ssh access is allowed from any jump host in any keyset. For example, if keyset A specifies jump host A and keyset B specifies jump host B, users in either keyset can use either jump host A or B.
-- While no baremetal machine keysets are defined, the restriction is lifted and ssh access is allowed from any jump host that has network connectivity to the baremetal machines.
+- While at least one keyset is defined, ssh access is allowed from any jump host in any keyset. For example, if keyset A specifies jump host A and keyset B specifies jump host B, users in either keyset can use either jump host A or B.
+- While no keysets are defined, ssh access is allowed from any jump host that has network connectivity to the machines.
 
 ## Prerequisites