Merge pull request #188990 from MicrosoftGuyJFlo/ExportDataScreenshotUpdate

[Azure AD] Identity Protection - Workload identity risk update

Author: hmacgregor1

articles/active-directory/conditional-access/workload-identity.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: how-to
-ms.date: 01/10/2022
+ms.date: 02/23/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -19,31 +19,25 @@ ms.collection: M365-identity-device-management
 
 Previously, Conditional Access policies applied only to users when they access apps and services like SharePoint online or the Azure portal. This preview adds support for Conditional Access policies applied to service principals owned by the organization. We call this capability  Conditional Access for workload identities. 
 
-A workload identity is an identity that allows an application or service principal access to resources, sometimes in the context of a user. These workload identities differ from traditional user accounts as:
+A [workload identity](../develop/workload-identities-overview.md) is an identity that allows an application or service principal access to resources, sometimes in the context of a user. These workload identities differ from traditional user accounts as they:
 
-- They usually have no formal lifecycle process.
+- Can’t perform multi-factor authentication.
+- Often have no formal lifecycle process.
 - Need to store their credentials or secrets somewhere.
-- Applications may use multiple identities. 
- 
-These differences make workload identities difficult to manage, puts them at higher risk for leaks, and reduces the potential for securing access.
+
+These differences make workload identities harder to manage and put them at higher risk for compromise.
 
 > [!IMPORTANT]
 > In public preview, you can scope Conditional Access policies to service principals in Azure AD with an Azure Active Directory Premium P2 edition active in your tenant. After general availability, additional licenses might be required.
 
 > [!NOTE]
 > Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy. 
 
-This preview enables blocking service principals from outside of trusted IP ranges, such as a corporate network public IP ranges. 
+This preview enables blocking service principals from outside of trusted public IP ranges, or based on risk detected by Azure AD Identity Protection.
 
 ## Implementation
 
-### Step 1: Set up a sample application
-
-If you already have a test application that makes use of a service principal, you can skip this step.
-
-Set up a sample application that, demonstrates how a job or a Windows service can run with an application identity, instead of a user's identity. Follow the instructions in the article [Quickstart: Get a token and call the Microsoft Graph API by using a console app's identity](../develop/quickstart-v2-netcore-daemon.md) to create this application.
-
-### Step 2: Create a Conditional Access policy
+### Create a location-based Conditional Access policy
 
 Create a location based Conditional Access policy that applies to service principals.
 
@@ -60,6 +54,52 @@ Create a location based Conditional Access policy that applies to service princi
 1. Your policy can be saved in **Report-only** mode, allowing administrators to estimate the effects, or policy is enforced by turning policy **On**.
 1. Select **Create** to complete your policy.
 
+### Create a risk-based Conditional Access policy
+
+Use this sample JSON for a risk-based policy using the [Microsoft Graph beta endpoint](/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0&preserve-view=true). 
+
+> [!NOTE]
+> Report-only mode doesn't report account risk on a risky workload identity.
+
+```json
+{
+"displayName": "Name",
+"state": "enabled OR disabled",
+"conditions": {
+"applications": {
+"includeApplications": [
+"All"
+],
+"excludeApplications": [],
+"includeUserActions": [],
+"includeAuthenticationContextClassReferences": [],
+"applicationFilter": null
+},
+"userRiskLevels": [],
+"signInRiskLevels": [],
+"clientApplications": {
+"includeServicePrincipals": [
+"ServicePrincipalsInMyTenant"
+],
+"excludeServicePrincipals": []
+},
+"servicePrincipalRiskLevels": [
+"low",
+"medium",
+"high"
+]
+},
+"grantControls": {
+"operator": "and",
+"builtInControls": [
+"block"
+],
+"customAuthenticationFactors": [],
+"termsOfUse": []
+}
+}
+```
+
 ## Roll back
 
 If you wish to roll back this feature, you can delete or disable any created policies.
@@ -77,14 +117,14 @@ Failure reason when Service Principal is blocked by Conditional Access: “Acces
 
 ### Finding the objectID
 
-You can get the objectID of the service principal from Azure AD Enterprise Applications. The Object ID in Azure AD App registrations cannot be used. This identifier is the Object ID of the app registration, not of the service principal.
+You can get the objectID of the service principal from Azure AD Enterprise Applications. The Object ID in Azure AD App registrations can’t be used. This identifier is the Object ID of the app registration, not of the service principal.
 
 1. Browse to the **Azure portal** > **Azure Active Directory** > **Enterprise Applications**, find the application you registered.
 1. From the **Overview** tab, copy the **Object ID** of the application. This identifier is the unique to the service principal, used by Conditional Access policy to find the calling app.
 
 ### Microsoft Graph
 
-Sample JSON for configuration using the Microsoft Graph beta endpoint.
+Sample JSON for location-based configuration using the Microsoft Graph beta endpoint.
 
 ```json
 {

articles/active-directory/identity-protection/howto-export-risk-data.md

@@ -6,12 +6,12 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: identity-protection
 ms.topic: how-to
-ms.date: 07/30/2021
+ms.date: 02/18/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
 manager: karenhoran
-ms.reviewer: sahandle
+ms.reviewer: sahandle, etbasser
 
 ms.collection: M365-identity-device-management
 ---
@@ -26,18 +26,20 @@ Azure AD stores reports and security signals for a defined period of time. When
 | Azure AD MFA usage | 30 days | 30 days | 30 days |
 | Risky sign-ins | 7 days | 30 days | 30 days |
 
-Organizations can choose to store data for longer periods by changing diagnostic settings in Azure AD to send **RiskyUsers** and **UserRiskEvents** data to a Log Analytics workspace, archive data to a storage account, stream data to an Event Hub, or send data to a partner solution. Find these options in the **Azure portal** > **Azure Active Directory**, **Diagnostic settings** > **Edit setting**. If you don't have a diagnostic setting, follow the instructions in the article [Create diagnostic settings to send platform logs and metrics to different destinations](../../azure-monitor/essentials/diagnostic-settings.md) to create one.
+Organizations can choose to store data for longer periods by changing diagnostic settings in Azure AD to send **RiskyUsers**, **UserRiskEvents**, **RiskyServicePrincipals**, and **ServicePrincipalRiskEvents** data to a Log Analytics workspace, archive data to a storage account, stream data to an event hub, or send data to a partner solution. Find these options in the **Azure portal** > **Azure Active Directory**, **Diagnostic settings** > **Edit setting**. If you don't have a diagnostic setting, follow the instructions in the article [Create diagnostic settings to send platform logs and metrics to different destinations](../../azure-monitor/essentials/diagnostic-settings.md) to create one.
 
 [ ![Diagnostic settings screen in Azure AD showing existing configuration](./media/howto-export-risk-data/change-diagnostic-setting-in-portal.png) ](./media/howto-export-risk-data/change-diagnostic-setting-in-portal.png#lightbox)
 
 ## Log Analytics
 
 Log Analytics allows organizations to query data using built in queries or custom created Kusto queries, for more information, see [Get started with log queries in Azure Monitor](../../azure-monitor/logs/get-started-queries.md).
 
-Once enabled you will find access to Log Analytics in the **Azure portal** > **Azure AD** > **Log Analytics**. The tables of most interest to Identity Protection administrators are **AADRiskyUsers** and **AADUserRiskEvents**.
+Once enabled you'll find access to Log Analytics in the **Azure portal** > **Azure AD** > **Log Analytics**. The following tables are of most interest to Identity Protection administrators:
 
 - AADRiskyUsers - Provides data like the **Risky users** report in Identity Protection.
 - AADUserRiskEvents - Provides data like the **Risk detections** report in Identity Protection.
+- RiskyServicePrincipals - Provides data like the **Risky workload identities** report in Identity Protection.
+- ServicePrincipalRiskEvents - Provides data like the **Workload identity detections** report in Identity Protection.
 
 [ ![Log Analytics view showing a query against the AADUserRiskEvents table showing the top 5 events](./media/howto-export-risk-data/log-analytics-view-query-user-risk-events.png) ](./media/howto-export-risk-data/log-analytics-view-query-user-risk-events.png#lightbox)