Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into mdb-quotas

Author: RoseHJM

articles/active-directory/app-provisioning/user-provisioning-sync-attributes-for-mapping.md

@@ -43,7 +43,7 @@ Next, if one or more of the users that will need access to the application do no
 The following sections outline how to create extension attributes for a tenant with cloud only users, and for a tenant with Active Directory users.
 
 ## Create an extension attribute in a tenant with cloud only users
-You can use Microsoft Graph and PowerShell to extend the user schema for users in Azure AD.  This is necessary if you do not have any users who need that attribute and originate in on-premises Active Directory. (If you do have Active Directory, then continue reading below in the section on how to [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect).)
+You can use Microsoft Graph and PowerShell to extend the user schema for users in Azure AD.  This is necessary if you have any users who need that attribute and do not originate in on-premises Active Directory. (If you do have Active Directory, then continue reading below in the section on how to [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect).)
 
 Once schema extensions are created, these extension attributes are automatically discovered when you next visit the provisioning page in the Azure portal, in most cases.
 
@@ -82,7 +82,7 @@ Content-type: application/json
   "extension_inputAppId_extensionName": "extensionValue"
 }
 ```
-Finally, verify the attribute for the user. To learn more, see [Get a user](/graph/api/user-get).
+Finally, verify the attribute for the user. To learn more, see [Get a user](/graph/api/user-get).  Note that the Graph v1.0 does not by default return any of a user's directory extension attributes, unless the attributes are specified in the request as one of the properties to return.
 
 ```json
 GET https://graph.microsoft.com/v1.0/users/{id}?$select=displayName,extension_inputAppId_extensionName

articles/active-directory/authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime.md

@@ -7,7 +7,7 @@ ms.service: active-directory
 ms.subservice: authentication
 ms.custom: has-azure-ad-ps-ref
 ms.topic: conceptual
-ms.date: 08/22/2023
+ms.date: 08/31/2023
 
 ms.author: justinha
 author: justinha
@@ -99,7 +99,7 @@ This setting allows configuration of lifetime for token issued by Azure Active D
 
 Now that you understand how different settings works and the recommended configuration, it's time to check your tenants. You can start by looking at the sign-in logs to understand which session lifetime policies were applied during sign-in.
 
-Under each sign-in log, go to the **Authentication Details** tab and explore **Session Lifetime Policies Applied**. For more information, see [Authentication details](../reports-monitoring/concept-sign-in-log-activity-details.md#authentication-details).
+Under each sign-in log, go to the **Authentication Details** tab and explore **Session Lifetime Policies Applied**. For more information, see the [Learn about the sign-in log activity details](../reports-monitoring/concept-sign-in-log-activity-details.md) article.
 
 ![Screenshot of authentication details.](./media/concepts-azure-multi-factor-authentication-prompts-session-lifetime/details.png)
 

articles/active-directory/multi-tenant-organizations/multi-tenant-organization-configure-graph.md

@@ -23,7 +23,7 @@ ms.custom: it-pro
 
 This article describes the key steps to configure a multi-tenant organization using the Microsoft Graph API. This article uses an example owner tenant named *Cairo* and two member tenants named *Berlin* and *Athens*.
 
-If you instead want to use the Microsoft 365 admin center to configure a multi-tenant organization, see [Set up a multi-tenant org in Microsoft 365 (Preview)](/microsoft-365/enterprise/set-up-multi-tenant-org) and [Join or leave a multi-tenant organization in Microsoft 365 (Preview)](/microsoft-365/enterprise/join-leave-multi-tenant-org).
+If you instead want to use the Microsoft 365 admin center to configure a multi-tenant organization, see [Set up a multi-tenant org in Microsoft 365 (Preview)](/microsoft-365/enterprise/set-up-multi-tenant-org) and [Join or leave a multi-tenant organization in Microsoft 365 (Preview)](/microsoft-365/enterprise/join-leave-multi-tenant-org). To learn how to configure Microsoft Teams for your multi-tenant organization, see [The new Microsoft Teams desktop client](/microsoftteams/new-teams-desktop-admin).
 
 ## Prerequisites
 
@@ -464,4 +464,5 @@ You delete a multi-tenant organization by removing all tenants. The process for
 
 - [Set up a multi-tenant org in Microsoft 365 (Preview)](/microsoft-365/enterprise/set-up-multi-tenant-org)
 - [Synchronize users in multi-tenant organizations in Microsoft 365 (Preview)](/microsoft-365/enterprise/sync-users-multi-tenant-orgs)
+- [The new Microsoft Teams desktop client](/microsoftteams/new-teams-desktop-admin)
 - [Configure multi-tenant organization templates using the Microsoft Graph API (Preview)](./multi-tenant-organization-configure-templates.md)

articles/active-directory/reports-monitoring/concept-sign-in-log-activity-details.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.topic: conceptual
 ms.workload: identity
 ms.subservice: report-monitor
-ms.date: 08/22/2023
+ms.date: 08/31/2023
 ms.author: sarahlipsey
 ms.reviewer: besiler
 ---
@@ -22,7 +22,7 @@ Azure AD logs all sign-ins into an Azure tenant for compliance purposes. As an I
 
 This article explains the values on the Basic info tab of the sign-ins log.
 
-## Basic info tab
+## [Basic info](#tab/basic-info)
 
 The Basic info tab contains most of the details that are also displayed in the table. You can launch the Sign-in Diagnostic from the Basic info tab. For more information, see [How to use the Sign-in Diagnostic](howto-use-sign-in-diagnostics.md).
 
@@ -32,11 +32,11 @@ If a sign-in failed, you can get more information about the reason in the Basic
 
 ![Screenshot of the sign-in error code on the basics tab.](media/concept-sign-in-log-activity-details/sign-in-error-code.png)
 
-## Location and Device info
+## [Location and Device](#tab/location-and-device)
 
 The **Location** and **Device info** tabs display general information about the location and IP address of the user. The Device info tab provides details on the browser and operating system used to sign in. This tab also provides details on if the device is compliant, managed, or hybrid Azure AD joined.
 
-## Authentication details
+## [Authentication details](#tab/authentication-details)
 
 The **Authentication Details** tab in the details of a sign-in log provides the following information for each authentication attempt:
 
@@ -62,77 +62,78 @@ When analyzing authentication details, take note of the following details:
 - If you're unsure of a detail in the logs, gather the **Request ID** and **Correlation ID** to use for further analyzing or troubleshooting.
 - If Conditional Access policies for authentication or session lifetime are applied, they're listed above the sign-in attempts. If you don't see either of these, those policies aren't currently applied. For more information, see [Conditional Access session controls](../conditional-access/concept-conditional-access-session.md).
 
+---
 
 ## Unique identifiers 
 
 In Azure AD, a resource access has three relevant components:
 
-- **Who** – The identity (User) doing the sign-in. 
-- **How** – The client (Application) used for the access.  
-- **What** – The target (Resource) accessed by the identity.
-
-Each component has an associated unique identifier (ID).
-
-### Tenant
-
-The sign-in log tracks two tenant identifiers:
-
-- **Home tenant** – The tenant that owns the user identity. 
-- **Resource tenant** – The tenant that owns the (target) resource.
-
-These identifiers are relevant in cross-tenant scenarios. For example, to find out how users outside your tenant are accessing your resources, select all entries where the home tenant doesn’t match the resource tenant.
-For the home tenant, Azure AD tracks the ID and the name. 
-
-### Request ID
-
-The request ID is an identifier that corresponds to an issued token. If you're looking for sign-ins with a specific token, you need to extract the request ID from the token, first.
-
-
-### Correlation ID
-
-The correlation ID groups sign-ins from the same sign-in session. The identifier was implemented for convenience. Its accuracy isn't guaranteed because the value is based on parameters passed by a client. 
+- **Who:** The identity (User) doing the sign-in. 
+- **How:** The client (Application) used for the access.  
+- **What:** The target (Resource) accessed by the identity.
 
-### Sign-in
+Each component has an associated unique identifier (ID).:
 
-The sign-in identifier is a string the user provides to Azure AD to identify itself when attempting to sign-in. It's usually a user principal name (UPN), but can be another identifier such as a phone number. 
+- **Authentication requirement:** Shows the highest level of authentication needed through all the sign-in steps for the sign-in to succeed.
+    - Graph API supports `$filter` (`eq` and `startsWith` operators only).
 
-### Authentication requirement 
+- **Conditional Access evaluation:** Shows whether continuous access evaluation (CAE) was applied to the sign-in event.
+    - There are multiple sign-in requests for each authentication, which can appear on either the interactive or non-interactive tabs.
+    - CAE is only displayed as true for one of the requests, and it can appear on the interactive tab or non-interactive tab.
+    - For more information, see [Monitor and troubleshoot sign-ins with continuous access evaluation in Azure AD](../conditional-access/howto-continuous-access-evaluation-troubleshoot.md).
 
-This attribute shows the highest level of authentication needed through all the sign-in steps for the sign-in to succeed. Graph API supports `$filter` (`eq` and `startsWith` operators only).
+- **Correlation ID:** The correlation ID groups sign-ins from the same sign-in session. The value is based on parameters passed by a client, so may Azure AD cannot guarantee its accuracy. 
 
-### Sign-in event types 
+- **Cross-tenant access type:** Describes the type of cross-tenant access used by the actor to access the resource. Possible values are: 
+    - `none` - A sign-in event that didn't cross an Azure AD tenant's boundaries.
+    - `b2bCollaboration`- A cross tenant sign-in performed by a guest user using B2B Collaboration.
+    - `b2bDirectConnect` - A cross tenant sign-in performed by a B2B.
+    - `microsoftSupport`- A cross tenant sign-in performed by a Microsoft support agent in a Microsoft customer tenant.
+    - `serviceProvider` - A cross-tenant sign-in performed by a Cloud Service Provider (CSP) or similar admin on behalf of that CSP's customer in a tenant
+    - `unknownFutureValue` - A sentinel value used by MS Graph to help clients handle changes in enum lists. For more information, see [Best practices for working with Microsoft Graph](/graph/best-practices-concept).
+    - If the sign-in didn't the pass the boundaries of a tenant, the value is `none`.
 
-Indicates the category of the sign in the event represents. For user sign-ins, the category can be `interactiveUser` or `nonInteractiveUser` and corresponds to the value for the **isInteractive** property on the sign-in resource. For managed identity sign-ins, the category is `managedIdentity`. For service principal sign-ins, the category is **servicePrincipal**. The Azure portal doesn't show this value, but the sign-in event is placed in the tab that matches its sign-in event type. Possible values are:
+- **Request ID:** An identifier that corresponds to an issued token. If you're looking for sign-ins with a specific token, you need to extract the request ID from the token, first.
 
-- `interactiveUser`
-- `nonInteractiveUser`
-- `servicePrincipal`
-- `managedIdentity`
-- `unknownFutureValue`
+- **Sign-in:** String the user provides to Azure AD to identify itself when attempting to sign-in. It's usually a user principal name (UPN), but can be another identifier such as a phone number. 
 
-The Microsoft Graph API, supports: `$filter` (`eq` operator only)
+- **Sign-in event types:** Indicates the category of the sign-in the event represents.
+    - The user sign-ins category can be `interactiveUser` or `nonInteractiveUser` and corresponds to the value for the **isInteractive** property on the sign-in resource.
+    - The managed identity category is `managedIdentity`.
+    - The service principal category is **servicePrincipal**.
+    - The Azure portal doesn't show this value, but the sign-in event is placed in the tab that matches its sign-in event type. Possible values are:
+        - `interactiveUser`
+        - `nonInteractiveUser`
+        - `servicePrincipal`
+        - `managedIdentity`
+        - `unknownFutureValue`
+    - The Microsoft Graph API, supports: `$filter` (`eq` operator only).
 
-### User type 
+- **Tenant:** The sign-in log tracks two tenant identifiers:
+    - **Home tenant** – The tenant that owns the user identity. Azure AD tracks the ID and name.
+    - **Resource tenant** – The tenant that owns the (target) resource.
+    - These identifiers are relevant in cross-tenant scenarios.
+    - For example, to find out how users outside your tenant are accessing your resources, select all entries where the home tenant doesn’t match the resource tenant.
+    
+- **User type:** Type of a user.
+    - Examples include `member`, `guest`, or `external`.
 
-The type of a user. Examples include `member`, `guest`, or `external`.
 
 
-### Cross-tenant access type 
+## Considerations for sign-in logs
 
-This attribute describes the type of cross-tenant access used by the actor to access the resource. Possible values are: 
+The following scenarios are important to consider when you're reviewing sign-in logs.
 
-- `none` - A sign-in event that didn't cross an Azure AD tenant's boundaries.
-- `b2bCollaboration`- A cross tenant sign-in performed by a guest user using B2B Collaboration.
-- `b2bDirectConnect` - A cross tenant sign-in performed by a B2B.
-- `microsoftSupport`- A cross tenant sign-in performed by a Microsoft support agent in a Microsoft customer tenant.
-- `serviceProvider` - A cross-tenant sign-in performed by a Cloud Service Provider (CSP) or similar admin on behalf of that CSP's customer in a tenant
-- `unknownFutureValue` - A sentinel value used by MS Graph to help clients handle changes in enum lists. For more information, see [Best practices for working with Microsoft Graph](/graph/best-practices-concept).
+- **IP address and location:** There's no definitive connection between an IP address and where the computer with that address is physically located. Mobile providers and VPNs issue IP addresses from central pools that are often far from where the client device is actually used. Currently, converting IP address to a physical location is a best effort based on traces, registry data, reverse lookups and other information.
 
-If the sign-in didn't the pass the boundaries of a tenant, the value is `none`.
+- **Conditional Access:** 
+    - *Not applied:* No policy applied to the user and application during sign-in.
+    - *Success:* One or more Conditional Access policies applied to or were evaluated for the user and application (but not necessarily the other conditions) during sign-in. Even though a Conditional Access policy might not apply, if it was evaluated, the Conditional Access status shows *Success*.
+    - *Failure:* The sign-in satisfied the user and application condition of at least one Conditional Access policy and grant controls are either not satisfied or set to block access. 
 
-### Conditional Access evaluation 
+- **Home tenant name:** Due to privacy commitments, Azure AD doesn't populate the home tenant name field during cross-tenant scenarios.
 
-This value shows whether continuous access evaluation (CAE) was applied to the sign-in event. There are multiple sign-in requests for each authentication. Some are shown on the interactive tab, while others are shown on the non-interactive tab. CAE is only displayed as true for one of the requests, and it can be on the interactive tab or non-interactive tab. For more information, see [Monitor and troubleshoot sign-ins with continuous access evaluation in Azure AD](../conditional-access/howto-continuous-access-evaluation-troubleshoot.md). 
+- **Multifactor authentication:** When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, additional MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Azure AD sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.
 
 ## Next steps