Merge pull request #187911 from MicrosoftDocs/main

2/08 AM Publish

Author: huypub

articles/active-directory/app-provisioning/on-premises-application-provisioning-architecture.md

@@ -13,7 +13,7 @@ ms.author: billmath
 ms.collection: M365-identity-device-management
 ---
 
-# Azure AD on-premises application provisioning architecture
+# Azure AD on-premises application provisioning architecture (preview)
 
 ## Overview
 

articles/active-directory/app-provisioning/on-premises-ldap-connector-configure.md

@@ -1,5 +1,5 @@
 ---
-title: Azure AD Provisioning to LDAP directories
+title: Azure AD Provisioning to LDAP directories (preview)
 description: This document describes how to configure Azure AD to provision users into an LDAP directory.
 services: active-directory
 author: billmath
@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: how-to
 ms.workload: identity
-ms.date: 10/15/2021
+ms.date: 02/08/2022
 ms.author: billmath
 ms.reviewer: arvinh
 ---

articles/active-directory/app-provisioning/tutorial-ecma-sql-connector.md

@@ -1,13 +1,13 @@
 ---
-title:  Azure AD Provisioning to SQL applications
+title:  Azure AD Provisioning to SQL applications (preview)
 description: This tutorial describes how to provision users from Azure AD into a SQL database.
 services: active-directory
 author: billmath
 manager: karenhoran
 ms.service: active-directory
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 10/21/2021
+ms.date: 02/08/2022
 ms.subservice: hybrid
 ms.author: billmath
 ms.reviewer: arvinh

articles/active-directory/conditional-access/overview.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: overview
-ms.date: 12/02/2021
+ms.date: 02/08/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -51,6 +51,7 @@ Common signals that Conditional Access can take in to account when making a poli
    - Administrators can specify entire countries/regions IP ranges to block or allow traffic from.
 - Device
    - Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies.
+   - Use filters for devices to target policies to specific devices like privileged access workstations.
 - Application
    - Users attempting to access specific applications can trigger different Conditional Access policies. 
 - Real-time and calculated risk detection
@@ -88,7 +89,7 @@ Many organizations have [common access concerns that Conditional Access policies
 
 Customers with [Microsoft 365 Business Premium licenses](/office365/servicedescriptions/office-365-service-descriptions-technet-library) also have access to Conditional Access features. 
 
-[Sign-in Risk](concept-conditional-access-conditions.md#sign-in-risk) requires access to [Identity Protection](../identity-protection/overview-identity-protection.md)
+Risk-based policies require access to [Identity Protection](../identity-protection/overview-identity-protection.md), which is an Azure AD P2 feature.
 
 ## Next steps
 

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

@@ -73,7 +73,8 @@ Starting with Windows 10 version 2004, you can use Azure AD groups to manage adm
 > [!NOTE]
 > Starting in the Windows 10 20H2 update, we recommend using [Local Users and Groups](/windows/client-management/mdm/policy-csp-localusersandgroups) policy instead of the Restricted Groups policy.
 
-Currently, there's no UI in Intune to manage these policies and they need to be configured using [Custom OMA-URI Settings](/mem/intune/configuration/custom-settings-windows-10). A few considerations for using either of these policies: 
+These policies can be configured in Intune using either [Custom OMA-URI Settings](/mem/intune/configuration/custom-settings-windows-10) or the [Local user group membership profile](/mem/intune/protect/endpoint-security-account-protection-policy#manage-local-groups-on-windows-devices) which is currently in preview as per the following [blog](https://techcommunity.microsoft.com/t5/intune-customer-success/new-settings-available-to-configure-local-user-group-membership/ba-p/3093207).  
+A few considerations for using either of these policies: 
 
 - Adding Azure AD groups through the policy requires the group's SID that can be obtained by executing the [Microsoft Graph API for Groups](/graph/api/resources/group). The SID is defined by the property `securityIdentifier` in the API response.
 

articles/active-directory/devices/azuread-join-sso.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: devices
 ms.topic: conceptual
-ms.date: 02/07/2022
+ms.date: 02/08/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 ---
 # How SSO to on-premises resources works on Azure AD joined devices
 
-It's probably not a surprise that an Azure Active Directory (Azure AD) joined device gives you a single sign-on (SSO) experience to your tenant's cloud apps. If your environment has an on-premises Active Directory (AD), you can also get SSO experience on Azure AD joined devices to resources and applications that rely on on-premises AD. 
+It's probably not a surprise that an Azure Active Directory (Azure AD) joined device gives you a single sign-on (SSO) experience to your tenant's cloud apps. If your environment has on-premises Active Directory Domain Services (AD DS), you can also get SSO experience on Azure AD joined devices to resources and applications that rely on on-premises AD. 
 
 This article explains how this works.
 
@@ -66,11 +66,11 @@ You can use:
 
 ## What you should know
 
-You may have to adjust your [domain-based filtering](../hybrid/how-to-connect-sync-configure-filtering.md#domain-based-filtering) in Azure AD Connect to ensure that the data about the required domains is synchronized if you have multiple domains.
-
-Apps and resources that depend on Active Directory machine authentication don't work because Azure AD joined devices don't have a computer object in AD. 
-
-You can't share files with other users on an Azure AD-joined device.
+- You may have to adjust your [domain-based filtering](../hybrid/how-to-connect-sync-configure-filtering.md#domain-based-filtering) in Azure AD Connect to ensure that the data about the required domains is synchronized if you have multiple domains.
+- Apps and resources that depend on Active Directory machine authentication don't work because Azure AD joined devices don't have a computer object in AD. 
+- You can't share files with other users on an Azure AD-joined device.
+- Applications running on your Azure AD joined device may authenticate users. They must use the implicit UPN or the NT4 type syntax with the domain FQDN name as the domain part, for example: [email protected] or contoso.corp.com\user.
+   - If applications use the NETBIOS or legacy name like contoso\user, the errors the application gets would be either, NT error STATUS_BAD_VALIDATION_CLASS - 0xc00000a7, or Windows error ERROR_BAD_VALIDATION_CLASS - 1348 “The validation information class requested was invalid.” This happens even if you can resolve the legacy domain name.
 
 ## Next steps
 

articles/active-directory/external-identities/cross-tenant-access-overview.md

@@ -105,7 +105,7 @@ The output is a list of outbound sign-ins initiated by your users to apps in ext
 
 ### Azure Monitor
 
-If your organization subscribes to the Azure Monitor service, you can use the [Cross-tenant access activity workbook](/reports-monitoring/workbook-cross-tenant-access-activity.md) (available in the Monitoring workbooks gallery in the Azure portal) to visually explore inbound and outbound sign-ins for longer time periods.
+If your organization subscribes to the Azure Monitor service, you can use the [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md) (available in the Monitoring workbooks gallery in the Azure portal) to visually explore inbound and outbound sign-ins for longer time periods.
 
 ### Security Information and Event Management (SIEM) Systems
 

articles/active-directory/identity-protection/TOC.yml

@@ -15,6 +15,8 @@
     href: concept-identity-protection-policies.md
   - name: What is the sign-in experience?
     href: concept-identity-protection-user-experience.md
+  - name: Securing workload identities
+    href: concept-workload-identity-risk.md
   - name: Identity Protection and B2B users
     href: concept-identity-protection-b2b.md
 - name: How-to guides

articles/active-directory/identity-protection/concept-workload-identity-risk.md

@@ -0,0 +1,107 @@
+---
+title: Securing workload identities with Azure AD Identity Protection
+description: Workload identity risk in Azure Active Directory Identity Protection
+
+services: active-directory
+ms.service: active-directory
+ms.subservice: identity-protection
+ms.topic: conceptual
+ms.date: 02/07/2022
+
+ms.author: joflore
+author: MicrosoftGuyJFlo
+manager: karenhoran
+ms.reviewer: etbasser
+
+ms.collection: M365-identity-device-management
+---
+# Securing workload identities with Identity Protection
+
+Azure AD Identity Protection has historically protected users in detecting, investigating, and remediating identity-based risks. We're now extending these capabilities to workload identities to protect applications, service principals, and Managed 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 they:
+
+- Can’t perform multi-factor authentication.
+- Often have no formal lifecycle process.
+- Need to store their credentials or secrets somewhere.
+
+These differences make workload identities harder to manage and put them at higher risk for compromise.
+
+> [!IMPORTANT]
+> In public preview, you can secure workload identities with Identity Protection and Azure Active Directory Premium P2 edition active in your tenant. After general availability, additional licenses might be required.
+
+## Prerequisites
+
+To make use of workload identity risk, including the new **Risky workload identities (preview)** blade and the **Workload identity detections** tab in the **Risk detections** blade, in the Azure portal you must have the following.
+
+- Azure AD Premium P2 licensing
+- One of the following administrator roles assigned
+   - Global administrator
+   - Security administrator
+   - Security operator
+   - Security reader
+
+## Workload identity risk detections
+
+We detect risk on workload identities across sign-in behavior and offline indicators of compromise. 
+
+| Detection name | Detection type | Description |
+| --- | --- | --- |
+| Azure AD threat intelligence | Offline | This risk detection indicates some activity that is consistent with known attack patterns based on Microsoft's internal and external threat intelligence sources. |
+| Suspicious Sign-ins | Offline | This risk detection indicates sign-in properties or patterns that are unusual for this service principal. <br><br> The detection learns the baselines sign-in behavior for workload identities in your tenant in between 2 and 60 days, and fires if one or more of the following unfamiliar properties appear during a later sign-in: IP address / ASN, target resource, user agent, hosting/non-hosting IP change, IP country, credential type. <br><br> Because of the programmatic nature of workload identity sign-ins, we provide a timestamp for the suspicious activity instead of flagging a specific sign-in event. <br><br>  Sign-ins that are initiated after an authorized configuration change may trigger this detection. |
+| Admin confirmed account compromised | Offline | This detection indicates an admin has selected 'Confirm compromised' in the Risky Workload Identities UI or using riskyServicePrincipals API. To see which admin has confirmed this account compromised, check the account’s risk history (via UI or API). |
+
+## Identify risky workload identities
+
+Organizations can find workload identities that have been flagged for risk in one of two locations:
+
+1. Navigate to the [Azure portal](https://portal.azure.com).
+1. Browse to **Azure Active Directory** > **Security** > **Risky workload identities (preview)**.
+1. Or browse to **Azure Active Directory** > **Security** > **Risk detections**.
+   1. Select the **Workload identity detections** tab.
+
+:::image type="content" source="media/concept-workload-identity-risk/workload-identity-detections-in-risk-detections-report.png" alt-text="Screenshot showing risks detected against workload identities in the report." lightbox="media/concept-workload-identity-risk/workload-identity-detections-in-risk-detections-report.png":::
+
+### Graph APIs
+
+You can also query risky workload identities [using the Microsoft Graph API](/graph/use-the-api). There are two new collections in the [Identity Protection APIs](/graph/api/resources/identityprotection-root?view=graph-rest-beta&preserve-view=true) 
+
+- riskyServicePrincipals
+- servicePrincipalRiskDetections
+
+### Export risk data 
+
+Organizations can export data by configurating [diagnostic settings in Azure AD](howto-export-risk-data.md) to send risk data to a Log Analytics workspace, archive it to a storage account, stream it to an event hub, or send it to a SIEM solution. 
+
+## Investigate risky workload identities
+
+Identity Protection provides organizations with two reports they can use to investigate workload identity risk. These reports are the risky workload identities, and risk detections for workload identities. All reports allow for downloading of events in .CSV format for further analysis outside of the Azure portal. 
+
+Some of the key questions to answer during your investigation include:
+
+- Do accounts show suspicious sign-in activity?
+- Have there been unauthorized changes to the credentials?
+- Have there been suspicious configuration changes to accounts?
+- Did the account acquire unauthorized application roles?
+
+The [Azure Active Directory security operations guide for Applications](../fundamentals/security-operations-applications.md) provides detailed guidance on the above investigation areas.
+
+Once you determine if the workload identity was compromised, dismiss the account’s risk or confirm the account as compromised in the Risky workload identities (preview) report. You can also select “Disable service principal” if you want to block the account from further sign-ins.
+
+:::image type="content" source="media/concept-workload-identity-risk/confirm-compromise-or-dismiss-risk.png" alt-text="Confirm workload identity compromise or dismiss the risk in the Azure portal." lightbox="media/concept-workload-identity-risk/confirm-compromise-or-dismiss-risk.png":::
+
+## Remediate risky workload identities
+
+1.	Inventory credentials assigned to the risky workload identity, whether for the service principal or application objects.
+1. Add a new credential. Microsoft recommends using x509 certificates.
+1. Remove the compromised credentials. If you believe the account is at risk, we recommend removing all existing credentials.
+1.	Remediate any Azure KeyVault secrets that the Service Principal has access to by rotating them. 
+
+The [Azure AD Toolkit](https://github.com/microsoft/AzureADToolkit) is a PowerShell module that can help you perform some of these actions.
+
+## Next steps
+
+- [Conditional Access for workload identities](../conditional-access/workload-identity.md)
+- [Microsoft Graph API](/graph/use-the-api)
+- [Azure AD audit logs](../reports-monitoring/concept-audit-logs.md)
+- [Azure AD sign-in logs](../reports-monitoring/concept-sign-ins.md)