Merge pull request #210474 from jlichwa/patch-23

Update active-directory-msi-cross-tenant-cmk-overview.md

Author: liljack17

includes/active-directory-msi-cross-tenant-cmk-create-identities-authorize-key-vault.md

@@ -360,7 +360,7 @@ subscriptionId="<replace-your-subscriptionId>"
 location="westcentralus"
 
 az group create --location $location --name $rgName
-export currentUserObjectId=$(az ad signed-in-user show --query objectId --out tsv)
+export currentUserObjectId=$(az ad signed-in-user show --query id --out tsv)
 
 az role assignment create --role "Key Vault Contributor" --scope /subscriptions/$subscriptionId/resourceGroups/$rgName/providers/Microsoft.KeyVault/vaults/$vaultName --assignee-object-id $currentUserObjectId
 

includes/active-directory-msi-cross-tenant-cmk-overview.md

@@ -16,9 +16,13 @@ Many service providers building Software as a Service (SaaS) offerings on Azure
 
 Azure platform services and resources that are owned by the service provider and that reside in the service provider's tenant require access to the key from the customer's tenant to perform the encryption/decryption operations.
 
-For the purposes of this how-to article, assume there are two Azure AD tenants: an independent service provider's tenant (*Tenant1*), and a customer's tenant (*Tenant2*). *Tenant1* hosts Azure platform services and *Tenant2* hosts the customer's key vault.
+The image below shows a data encryption at rest with federated identity in a cross-tenant CMK workflow spanning a service provider and its customer.
 
-The service provider first creates a multi-tenant application registration in *Tenant1*. The service provider configures a [federated identity credential](../articles/active-directory/develop/workload-identity-federation-create-trust.md) on this application using a user-assigned managed identity. The service provider then shares the name and application ID of the app with the customer.
+:::image type="content" source="media/active-directory-msi-cross-tenant-cmk-overview/cross-tenant-cmk.png" alt-text="Screenshot showing a cross-tenant CMK with a federated identity." lightbox="media/active-directory-msi-cross-tenant-cmk-overview/cross-tenant-cmk.png" border="true":::
+
+In the example above, there are two Azure AD tenants: an independent service provider's tenant (*Tenant1*), and a customer's tenant (*Tenant2*). *Tenant1* hosts Azure platform services and *Tenant2* hosts the customer's key vault.
+
+A multi-tenant application registration is created by the service provider in *Tenant1*. A [federated identity credential](/azure/active-directory/develop/workload-identity-federation-create-trust-managed-identity-as-credential) is created on this application using a user-assigned managed identity. Then, the name and application ID of the app is shared with the customer.
 
 A user with the appropriate permissions installs the service provider's application in the customer tenant, *Tenant2*. A user then grants the service principal associated with the installed application access to the customer's key vault. The customer also stores the encryption key, or customer-managed key, in the key vault. The customer shares the key location (the URL of the key) with the service provider.
 
@@ -58,7 +62,7 @@ Operations in Phase 1 would be a one-time setup for most service provider applic
 | Step | Description | Least privileged Azure RBAC roles | Least privileged Azure AD roles |
 | -- | ----------------------------------- | -------------- | --------------|
 | 1. | <li><i>Recommended</i>: Send the user to [sign in](/azure/active-directory/develop/scenario-web-app-sign-user-overview?tabs=aspnetcore) to your app. If the user can sign in, then a service principal for your app exists in their tenant. </li><li>Use [Microsoft Graph](/graph/api/serviceprincipal-post-serviceprincipals), [Microsoft Graph PowerShell](/powershell/module/microsoft.graph.applications/new-mgserviceprincipal?view=graph-powershell-beta&preserve-view=true), [Azure PowerShell](/powershell/module/az.resources/new-azadserviceprincipal), or [Azure CLI](/cli/azure/ad/sp#az-ad-sp-create) to create the service principal. </li><li>Construct [an admin-consent URL](../articles/active-directory/manage-apps/grant-admin-consent.md#construct-the-url-for-granting-tenant-wide-admin-consent) and grant tenant-wide consent to create the service principal using the application ID. | None | Users with permissions to install applications |
-| 2. | Create an Azure Key Vault and a key used as the customer-managed key. | A user must must be assigned the [Key Vault Contributor](../articles/role-based-access-control/built-in-roles.md#key-vault-contributor) role to create the key vault<br /><br /> A user must be assigned the [Key Vault Crypto Officer](../articles/role-based-access-control/built-in-roles.md#key-vault-crypto-officer) role to add a key to the key vault | None |
+| 2. | Create an Azure Key Vault and a key used as the customer-managed key. | A user must be assigned the [Key Vault Contributor](../articles/role-based-access-control/built-in-roles.md#key-vault-contributor) role to create the key vault<br /><br /> A user must be assigned the [Key Vault Crypto Officer](../articles/role-based-access-control/built-in-roles.md#key-vault-crypto-officer) role to add a key to the key vault | None |
 | 3. | Grant the consented application identity access to the Azure key vault by assigning the role [Key Vault Crypto Service Encryption User](/azure/key-vault/general/rbac-guide?tabs=azure-cli#azure-built-in-roles-for-key-vault-data-plane-operations&preserve-view=true) | To assign the **Key Vault Crypto Service Encryption User** role to the application, you must have been assigned the [User Access Administrator](../articles/role-based-access-control/built-in-roles.md#user-access-administrator) role. | None |
 | 4. | Copy the key vault URL and key name into the customer-managed keys configuration of the SaaS offering.| None| None|