resolve merge conflict

Author: ktoliver

articles/active-directory/develop/v2-app-types.md

@@ -77,7 +77,7 @@ You can ensure the user's identity by validating the ID token with a public sign
 
 To see this scenario in action, try the code samples in [Sign in users from a Web app](scenario-web-app-sign-user-overview.md).
 
-In addition to simple sign-in, a web server app might need to access another web service, such as a Representational State Transfer ([REST](https://docs.microsoft.com/rest/api/azure/)) API. In this case, the web server app engages in a combined OpenID Connect and OAuth 2.0 flow, by using the [OAuth 2.0 authorization code flow](v2-oauth2-auth-code-flow.md). For more information about this scenario, refer to our code [sample](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/2-WebApp-graph-user/2-1-Call-MSGraph/README.md).
+In addition to simple sign-in, a web server app might need to access another web service, such as a [Representational State Transfer (REST) API](/rest/api/azure/). In this case, the web server app engages in a combined OpenID Connect and OAuth 2.0 flow, by using the [OAuth 2.0 authorization code flow](v2-oauth2-auth-code-flow.md). For more information about this scenario, refer to our code [sample](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/2-WebApp-graph-user/2-1-Call-MSGraph/README.md).
 
 ## Web APIs
 

articles/active-directory/enterprise-users/licensing-service-plan-reference.md

@@ -13,7 +13,7 @@ ms.service: active-directory
 ms.subservice: enterprise-users
 ms.topic: reference
 ms.workload: identity
-ms.date: 09/19/2022
+ms.date: 09/21/2022
 ms.author: nicholak
 ms.reviewer: Nicholak-MS
 ms.custom: "it-pro;seo-update-azuread-jan"
@@ -32,7 +32,7 @@ When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
 - **Service plans included (friendly names)**: A list of service plans (friendly names) in the product that correspond to the string ID and GUID
 
 >[!NOTE]
->This information last updated on September 19th, 2022.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
+>This information last updated on September 21st, 2022.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
 ><br/>
 
 | Product name | String ID | GUID | Service plans included | Service plans included (friendly names) |

articles/active-directory/fundamentals/secure-with-azure-ad-multiple-tenants.md

@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 
 # Resource isolation with multiple tenants
 
-There are specific scenarios when delegating administration within a single tenant boundary won't meet your needs. In this section, we'll discuss requirements that may drive you to create a multi-tenant architecture. Multi-tenant organizations might span two or more Azure AD tenants. This can result in unique cross-tenant collaboration and management requirements. Multi-tenant architectures increase management overhead and complexity and should be used with caution. We recommend using a single tenant if your needs can be met with that architecture. For more detailed information, see [Multi-tenant user management]../fundamentals/multi-tenant-user-management-introduction.md).
+There are specific scenarios when delegating administration within a single tenant boundary won't meet your needs. In this section, we'll discuss requirements that may drive you to create a multi-tenant architecture. Multi-tenant organizations might span two or more Azure AD tenants. This can result in unique cross-tenant collaboration and management requirements. Multi-tenant architectures increase management overhead and complexity and should be used with caution. We recommend using a single tenant if your needs can be met with that architecture. For more detailed information, see [Multi-tenant user management](multi-tenant-user-management-introduction.md).
 
 A separate tenant creates a new boundary, and therefore decoupled management of Azure AD directory roles, directory objects, conditional access policies, Azure resource groups, Azure management groups, and other controls as described in previous sections.
 
@@ -183,4 +183,4 @@ Devices: This tenant contains a reduced number of devices; only those that are n
 
 * [Resource isolation in a single tenant](secure-with-azure-ad-single-tenant.md)
 
-* [Best practices](secure-with-azure-ad-best-practices.md)
+* [Best practices](secure-with-azure-ad-best-practices.md)

articles/active-directory/governance/TOC.yml

@@ -245,6 +245,8 @@
     href: workflows-faqs.md  
   - name: Developer API reference Lifecycle Workflows- Azure Active Directory
     href: lifecycle-workflows-developer-reference.md  
+  - name: Set employeeLeaveDateTime for leaver workflows
+    href: set-employee-leave-date-time.md  
   - name: Preparing user accounts for Lifecycle workflows tutorials (Preview)
     href: tutorial-prepare-azure-ad-user-accounts.md 
   - name: Configure a Logic App for Lifecycle Workflow use (Preview)

articles/active-directory/governance/how-to-lifecycle-workflow-sync-attributes.md

@@ -23,10 +23,10 @@ The following table shows the scheduling (trigger) relevant attributes and the m
 |Attribute|Type|Supported in HR Inbound Provisioning|Support in Azure AD Connect Cloud Sync|Support in Azure AD Connect Sync| 
 |-----|-----|-----|-----|-----|
 |employeeHireDate|DateTimeOffset|Yes|Yes|Yes|
-|employeeLeaveDateTime|DateTimeOffset|Not currently(manually setting supported)|Not currently(manually setting supported)|Not currently(manually setting supported)|
+|employeeLeaveDateTime|DateTimeOffset|Yes|Not currently|Not currently|
 
 > [!NOTE]
-> Currently, automatic synchronization of the employeeLeaveDateTime attribute for HR Inbound scenarios is not available. To take advantaged of leaver scenarios, you can set the employeeLeaveDateTime manually. Manually setting the attribute can be done in the portal or with Graph. For more information see [User profile in Azure](../fundamentals/active-directory-users-profile-azure-portal.md) and [Update user](/graph/api/user-update?view=graph-rest-beta&tabs=http).
+> To take advantaged of leaver scenarios, you can set the employeeLeaveDateTime manually for cloud-only users. For more information, see: [Set employeeLeaveDateTime](set-employee-leave-date-time.md)
 
 This document explains how to set up synchronization from on-premises Azure AD Connect cloud sync and Azure AD Connect for the required attributes.
 

articles/active-directory/governance/set-employee-leave-date-time.md

@@ -0,0 +1,70 @@
+---
+title: Set employeeLeaveDateTime
+description: Explains how to manually set employeeLeaveDateTime. 
+author: owinfreyATL
+ms.author: owinfrey
+ms.service: active-directory
+ms.topic: how-to 
+ms.date: 09/07/2022
+ms.custom: template-how-to 
+---
+
+# Set employeeLeaveDateTime
+
+This article describes how to manually set the employeeLeaveDateTime attribute for a user. This attribute can be set as a trigger for leaver workflows created using Lifecycle Workflows.
+
+## Required permission and roles
+
+To set the employeeLeaveDateTime attribute, you must make sure the correct delegated roles and application permissions are set. They are as follows:
+
+### Delegated
+
+In delegated scenarios, the signed-in user needs the Global Administrator role to update the employeeLeaveDateTime attribute. One of the following delegated permissions is also required:
+- User-LifeCycleInfo.ReadWrite.All
+- Directory.AccessAsUser.All
+
+### Application
+
+Updating the employeeLeaveDateTime requires the User-LifeCycleInfo.ReadWrite.All application permission.
+
+>[!NOTE]
+> The User-LifeCycleInfo.ReadWrite.All permissions is currently hidden and cannot be configured in Graph Explorer or the API permission blade of app registrations.
+
+## Set employeeLeaveDateTime via PowerShell
+To set the employeeLeaveDateTime for a user using PowerShell enter the following information:
+
+ ```powershell    
+    Connect-MgGraph -Scopes "User-LifeCycleInfo.ReadWrite.All"
+    Select-MgProfile -Name "beta"
+
+    $UserId = "<Object ID of the user>"
+    $employeeLeaveDateTime = "<Leave date>"
+    
+    $Body = '{"employeeLeaveDateTime": "' + $employeeLeaveDateTime + '"}'
+    Update-MgUser -UserId $UserId -BodyParameter $Body
+
+    $User = Get-MgUser -UserId $UserId -Property employeeLeaveDateTime
+    $User.AdditionalProperties
+ ```
+
+ This script is an example of a user who will leave on September 30, 2022 at 23:59.
+
+ ```powershell
+    Connect-MgGraph -Scopes "User-LifeCycleInfo.ReadWrite.All"
+    Select-MgProfile -Name "beta"
+
+    $UserId = "528492ea-779a-4b59-b9a3-b3773ef6da6d"
+    $employeeLeaveDateTime = "2022-09-30T23:59:59Z"
+    
+    $Body = '{"employeeLeaveDateTime": "' + $employeeLeaveDateTime + '"}'
+    Update-MgUser -UserId $UserId -BodyParameter $Body
+
+    $User = Get-MgUser -UserId $UserId -Property employeeLeaveDateTime
+    $User.AdditionalProperties
+``` 
+
+
+## Next steps
+
+- [How to synchronize attributes for Lifecycle workflows](how-to-lifecycle-workflow-sync-attributes.md)
+- [Lifecycle Workflows templates](lifecycle-workflow-templates.md)

articles/active-directory/hybrid/how-to-connect-password-hash-synchronization.md

@@ -124,6 +124,9 @@ Caveat: If there are synchronized accounts that need to have non-expiring passwo
 > [!NOTE]
 > The Set-MsolPasswordPolicy PowerShell command will not work on federated domains. 
 
+> [!NOTE]
+> The Set-AzureADUser PowerShell command will not work on federated domains. 
+
 #### Synchronizing temporary passwords and "Force Password Change on Next Logon"
 
 It is typical to force a user to change their password during their first logon, especially after an admin password reset occurs.  It is commonly known as setting a "temporary" password and is completed by checking the "User must change password at next logon" flag on a user object in Active Directory (AD).

articles/active-directory/hybrid/how-to-connect-sync-whatis.md

@@ -29,7 +29,7 @@ The sync service consists of two components, the on-premises **Azure AD Connect
 >
 >To find out if you are already eligible for Cloud Sync, please verify your requirements in [this wizard](https://admin.microsoft.com/adminportal/home?Q=setupguidance#/modernonboarding/identitywizard).
 >
->To learn more about Cloud Sync please read [this article](https://docs.microsoft.com/azure/active-directory/cloud-sync/what-is-cloud-sync), or watch this [short video](https://www.microsoft.com/en-us/videoplayer/embed/RWJ8l5).
+>To learn more about Cloud Sync please read [this article](/azure/active-directory/cloud-sync/what-is-cloud-sync), or watch this [short video](https://www.microsoft.com/videoplayer/embed/RWJ8l5).
 >
 
 

articles/active-directory/reports-monitoring/how-to-view-applied-conditional-access-policies.md

@@ -1,7 +1,7 @@
 ---
 
-title: How to view applied conditional access policies in the Azure AD sign-in logs | Microsoft Docs
-description: Learn how to view applied conditional access policies in the Azure AD sign-in logs
+title: View applied Conditional Access policies in Azure AD sign-in logs
+description: Learn how to view Conditional Access policies in Azure AD sign-in logs so that you can assess the impact of those policies.
 services: active-directory
 documentationcenter: ''
 author: MarkusVi
@@ -19,45 +19,35 @@ ms.reviewer: besiler
 ms.collection: M365-identity-device-management
 ---
 
-# How to: View applied conditional access policies in the Azure AD sign-in logs
+# View applied Conditional Access policies in Azure AD sign-in logs
 
-With conditional access policies, you can control, how your users get access to the resources of your Azure tenant. As a tenant admin, you need to be able to determine what impact your conditional access policies have on sign-ins to your tenant, so that you can take action if necessary. The sign-in logs in Azure AD provide you with the information you need to assess the impact of your policies.
-
-  
-This article explains how you can get access to the information about applied conditional access policies. 
+With Conditional Access policies, you can control how your users get access to the resources of your Azure tenant. As a tenant admin, you need to be able to determine what impact your Conditional Access policies have on sign-ins to your tenant, so that you can take action if necessary. 
 
+The sign-in logs in Azure Active Directory (Azure AD) give you the information that you need to assess the impact of your policies. This article explains how to view applied Conditional Access policies in those logs.
 
 ## What you should know
 
 As an Azure AD administrator, you can use the sign-in logs to:
 
-- Troubleshoot sign in problems
-- Check on feature performance
-- Evaluate security of a tenant
-
-Some scenarios require you to get an understanding for how your conditional access policies were applied to a sign-in event. Common examples include:
-
-- **Helpdesk administrators** who need to look at applied conditional access policies to understand if a policy is the root cause of a ticket opened by a user. 
-
-- **Tenant administrators** who need to verify that conditional access policies have the intended impact on the users of a tenant.
+- Troubleshoot sign-in problems.
+- Check on feature performance.
+- Evaluate the security of a tenant.
 
+Some scenarios require you to get an understanding of how your Conditional Access policies were applied to a sign-in event. Common examples include:
 
-You can access the sign-in logs using the Azure portal, MS Graph, and PowerShell.  
+- *Helpdesk administrators* who need to look at applied Conditional Access policies to understand if a policy is the root cause of a ticket that a user opened. 
 
+- *Tenant administrators* who need to verify that Conditional Access policies have the intended impact on the users of a tenant.
 
+You can access the sign-in logs by using the Azure portal, Microsoft Graph, and PowerShell.  
 
 ## Required administrator roles 
 
+To see applied Conditional Access policies in the sign-in logs, administrators must have permissions to view both the logs and the policies.
 
-To see applied conditional access policies in the sign-in logs, administrators must have permissions to:  
-
-- View sign-in logs 
-- View conditional access policies
-
-The least privileged built-in role that grants both permissions is the **Security Reader**. As a best practice, your global administrator should add the **Security Reader** role to the related administrator accounts. 
-
+The least privileged built-in role that grants both permissions is *Security Reader*. As a best practice, your global administrator should add the Security Reader role to the related administrator accounts. 
 
-The following built in roles grant permissions to read conditional access policies:
+The following built-in roles grant permissions to read Conditional Access policies:
 
 - Global Administrator 
 
@@ -70,7 +60,7 @@ The following built in roles grant permissions to read conditional access polici
 - Conditional Access Administrator 
 
 
-The following built in roles grant permission to view sign-in logs: 
+The following built-in roles grant permission to view sign-in logs: 
 
 - Global Administrator 
 
@@ -82,64 +72,57 @@ The following built in roles grant permission to view sign-in logs:
 
 - Reports Reader 
 
-
 ## Permissions for client apps 
 
-If you use a client app to pull sign-in logs from Graph, your app needs permissions to receive the **appliedConditionalAccessPolicy** resource from Graph. As a best practice, assign **Policy.Read.ConditionalAccess** because it's the least privileged permission. Any of the following permissions is sufficient for a client app to access applied CA policies in sign-in logs through Graph: 
+If you use a client app to pull sign-in logs from Microsoft Graph, your app needs permissions to receive the `appliedConditionalAccessPolicy` resource from Microsoft Graph. As a best practice, assign `Policy.Read.ConditionalAccess` because it's the least privileged permission. 
 
-- Policy.Read.ConditionalAccess 
+Any of the following permissions is sufficient for a client app to access applied certificate authority (CA) policies in sign-in logs through Microsoft Graph: 
 
-- Policy.ReadWrite.ConditionalAccess 
+- `Policy.Read.ConditionalAccess` 
 
-- Policy.Read.All 
+- `Policy.ReadWrite.ConditionalAccess` 
 
- 
+- `Policy.Read.All` 
 
 ## Permissions for PowerShell 
 
-Like any other client app, the Microsoft Graph PowerShell module needs client permissions to access applied conditional access policies in the sign-in logs. To successfully pull applied conditional access in the sign-in logs, you must consent to the necessary permissions with your administrator account for MS Graph PowerShell. As a best practice, consent to:
+Like any other client app, the Microsoft Graph PowerShell module needs client permissions to access applied Conditional Access policies in the sign-in logs. To successfully pull applied Conditional Access policies in the sign-in logs, you must consent to the necessary permissions with your administrator account for Microsoft Graph PowerShell. As a best practice, consent to:
 
-- Policy.Read.ConditionalAccess
-- AuditLog.Read.All 
-- Directory.Read.All 
+- `Policy.Read.ConditionalAccess`
+- `AuditLog.Read.All` 
+- `Directory.Read.All` 
 
 These permissions are the least privileged permissions with the necessary access. 
 
 To consent to the necessary permissions, use: 
 
-` Connect-MgGraph -Scopes Policy.Read.ConditionalAccess, AuditLog.Read.All, Directory.Read.All `
+`Connect-MgGraph -Scopes Policy.Read.ConditionalAccess, AuditLog.Read.All, Directory.Read.All`
 
 To view the sign-in logs, use: 
 
-`Get-MgAuditLogSignIn `
-
-The output of this cmdlet contains a **AppliedConditionalAccessPolicies** property that shows all the conditional access policies applied to the sign-in. 
+`Get-MgAuditLogSignIn`
 
 For more information about this cmdlet, see [Get-MgAuditLogSignIn](https://learn.microsoft.com/powershell/module/microsoft.graph.reports/get-mgauditlogsignin?view=graph-powershell-1.0).
 
-The AzureAD Graph PowerShell module doesn't support viewing applied conditional access policies; only the Microsoft Graph PowerShell module returns applied conditional access policies.  
+The Azure AD Graph PowerShell module doesn't support viewing applied Conditional Access policies. Only the Microsoft Graph PowerShell module returns applied Conditional Access policies.  
 
 ## Confirming access 
 
-In the **Conditional Access** tab, you see a list of conditional access policies applied to that sign-in event.  
-
+On the **Conditional Access** tab, you see a list of Conditional Access policies applied to that sign-in event. 
 
-To confirm that you have admin access to view applied conditional access policies in the sign-ins logs, do: 
+To confirm that you have admin access to view applied Conditional Access policies in the sign-in logs: 
 
-1. Navigate to the Azure portal. 
+1. Go to the Azure portal. 
 
-2. In the top-right corner, select your directory, and then select **Azure Active Directory** in the left navigation pane. 
+2. In the upper-right corner, select your directory, and then select **Azure Active Directory** on the left pane. 
 
 3. In the **Monitoring** section, select **Sign-in logs**. 
 
-4. Click an item in the sign-in row table to bring up the Activity Details: Sign-ins context pane.  
-
-5. Click on the Conditional Access tab in the context pane. If your screen is small, you may need to click the ellipsis […] to see all context pane tabs.  
-
-
+4. Select an item in the sign-in table to open the **Activity Details: Sign-ins context** pane.  
 
+5. Select the **Conditional Access** tab on the context pane. If your screen is small, you might need to select the ellipsis (**...**) to see all tabs on the context pane.  
 
 ## Next steps
 
-* [Sign-ins error codes reference](./concept-sign-ins.md)
-* [Sign-ins report overview](concept-sign-ins.md)
+* [Sign-in error code reference](./concept-sign-ins.md)
+* [Sign-in report overview](concept-sign-ins.md)