blocking-issues-fix

Author: shlipsey3

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/21/2023
+ms.date: 08/22/2023
 
 ms.author: justinha
 author: justinha
@@ -46,7 +46,7 @@ To optimize the frequency of authentication prompts for your users, you can conf
 
 ### Evaluate session lifetime policies
 
-Without any session lifetime settings, there are no persistent cookies in the browser session. Every time a user closes and open the browser, they get a prompt for reauthentication. In Office clients, the default time period is a rolling window of 90 days. With this default Office configuration, if the user has reset their password or there has been inactivity of over 90 days, the user is required to reauthenticate with all required factors (first and second factor).
+Without any session lifetime settings, there are no persistent cookies in the browser session. Every time a user closes and opens the browser, they get a prompt for reauthentication. In Office clients, the default time period is a rolling window of 90 days. With this default Office configuration, if the user has reset their password or there has been inactivity of over 90 days, the user is required to reauthenticate with all required factors (first and second factor).
 
 A user might see multiple MFA prompts on a device that doesn't have an identity in Azure AD. Multiple prompts result when each application has its own OAuth Refresh Token that isn't shared with other client apps. In this scenario, MFA prompts multiple times as each application requests an OAuth Refresh Token to be validated with MFA.
 

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

@@ -18,7 +18,7 @@ ms.reviewer: besiler
 Azure AD logs all sign-ins into an Azure tenant for compliance purposes. As an IT administrator, you need to know what the values in the sign-in logs mean, so that you can interpret the log values correctly.
 
 - [Learn about the sign-in logs](concept-sign-ins.md).
-- [Customize and filter the sign-in logs](howto-customize-filter-logs.md)
+- [Customize and filter the sign-in logs](howto-customize-filter-sign-in-logs.md)
 
 This article explains the values on the Basic info tab of the sign-ins log.
 
@@ -60,7 +60,7 @@ When analyzing authentication details, take note of the following details:
     - A **satisfied by claim in the token** message is incorrectly displayed when sign-in events are initially logged. 
     - The **Primary authentication** row isn't initially logged.
 - 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 are 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).
+- 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 
@@ -71,7 +71,7 @@ In Azure AD, a resource access has three relevant components:
 - **How** – The client (Application) used for the access.  
 - **What** – The target (Resource) accessed by the identity.
 
-Each component has an associated unique identifier (ID). Below is an example of user using the Microsoft Azure classic deployment model to access the Azure portal.
+Each component has an associated unique identifier (ID).
 
 ### Tenant
 
@@ -85,12 +85,12 @@ 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 are looking for sign-ins with a specific token, you need to extract the request ID from the token, first.
+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 is not guaranteed because the value is based on parameters passed by a client. 
+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. 
 
 ### Sign-in
 
@@ -121,14 +121,14 @@ The type of a user. Examples include `member`, `guest`, or `external`.
 
 This attribute describes the type of cross-tenant access used by the actor to access the resource. Possible values are: 
 
-- `none` - A sign-in event that did not cross an Azure AD tenant's boundaries.
+- `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 did not the pass the boundaries of a tenant, the value is `none`.
+If the sign-in didn't the pass the boundaries of a tenant, the value is `none`.
 
 ### Conditional Access evaluation 
 

articles/active-directory/reports-monitoring/concept-sign-ins.md

@@ -8,25 +8,25 @@ ms.service: active-directory
 ms.topic: conceptual
 ms.workload: identity
 ms.subservice: report-monitor
-ms.date: 08/16/2023
+ms.date: 08/22/2023
 ms.author: sarahlipsey
 ms.reviewer: besiler
 ---
 # What are Azure Active Directory sign-in logs?
 
 Azure Active Directory (Azure AD) logs all sign-ins into an Azure tenant, which includes your internal apps and resources. As an IT administrator, you need to know what the values in the sign-in logs mean, so that you can interpret the log values correctly.
 
-Reviewing sign-in errors and patterns provides valuable insight into how your users access applications and services. The sign-in logs provided by Azure Azure AD are a powerful type of [activity log](overview-reports.md) that you can analyze. This article explains how to access and utilize the sign-in logs.
+Reviewing sign-in errors and patterns provides valuable insight into how your users access applications and services. The sign-in logs provided by Azure AD are a powerful type of [activity log](overview-reports.md) that you can analyze. This article explains how to access and utilize the sign-in logs.
 
-The preview view of the sign-in logs include interactive and non-interactive user sign-ins as well as service principle and managed identity sign-ins. You can still view the classic sign-in logs, which only include interactive sign-ins. 
+The preview view of the sign-in logs includes interactive and non-interactive user sign-ins as well as service principal and managed identity sign-ins. You can still view the classic sign-in logs, which only include interactive sign-ins. 
 
 Two other activity logs are also available to help monitor the health of your tenant:
 - **[Audit](concept-audit-logs.md)** – Information about changes applied to your tenant, such as users and group management or updates applied to your tenant’s resources.
 - **[Provisioning](concept-provisioning-logs.md)** – Activities performed by a provisioning service, such as the creation of a group in ServiceNow or a user imported from Workday.
 
 ## What can you do with sign-in logs?
 
-You can use the sing-in logs to answer questions such as:
+You can use the sign-in logs to answer questions such as:
 
 - How many users have signed into a particular application this week?
 - How many failed sign-in attempts have occurred in the last 24 hours?
@@ -54,10 +54,10 @@ The classic sign-in logs only include interactive user sign-ins.
 
 Interactive user sign-ins provide an authentication factor to Azure AD. That authentication factor could also interact with a helper app, such as the Microsoft Authenticator app. Users can provide passwords, responses to MFA challenges, biometric factors, or QR codes to Azure AD or to a helper app. This log also includes federated sign-ins from identity providers that are federated to Azure AD.  
 
-![Screenshot of the interactive user sign-ins log.](media/concept-sign-ins/sign-in-logs-user-interactive.png)
+:::image type="content" source="media/concept-sign-ins/sign-in-logs-user-interactive.png" alt-text="Screenshot of the interactive user sign-ins log." lightbox="media/concept-sign-ins/sign-in-logs-user-interactive-expanded.png":::
 
 > [!NOTE] 
-> The interactive user sign-in log previously contained some non-interactive sign-ins from Microsoft Exchange clients. Although those sign-ins were non-interactive, they were included in the interactive user sign-in log for additional visibility. Once the non-interactive user sign-in log entered public preview in November 2020, those non-interactive sign-in logs were moved to the non-interactive user sign in log for increased accuracy. 
+> The interactive user sign-in log previously contained some non-interactive sign-ins from Microsoft Exchange clients. Although those sign-ins were non-interactive, they were included in the interactive user sign-in log for additional visibility. Once the non-interactive user sign-in log entered public preview in November 2020, those non-interactive sign-in logs were moved to the non-interactive user sign-in log for increased accuracy. 
 
 **Report size:** small </br>
 **Examples:**
@@ -97,7 +97,7 @@ To make it easier to digest the data, non-interactive sign-in events are grouped
 
 :::image type="content" source="media/concept-sign-ins/aggregate-sign-in.png" alt-text="Screenshot of an aggregate sign-in expanded to show all rows." lightbox="media/concept-sign-ins/aggregate-sign-in-expanded.png":::
 
-When Azure AD logs multiple sign-ins that are identical other than time and date, those sign-ins are from the same entity and are aggregated into a single row. A row with multiple identical sign-ins (except for date and time issued) have a value greater than 1 in the *# sign-ins* column. These aggregated sign-ins may also appear to have the same time stamps. The **Time aggregate** filter can set to 1 hour, 6 hours, or 24 hours. You can expand the row to see all the different sign-ins and their different time stamps. 
+When Azure AD logs multiple sign-ins that are identical other than time and date, those sign-ins are from the same entity and are aggregated into a single row. A row with multiple identical sign-ins (except for date and time issued) has a value greater than 1 in the *# sign-ins* column. These aggregated sign-ins may also appear to have the same time stamps. The **Time aggregate** filter can set to 1 hour, 6 hours, or 24 hours. You can expand the row to see all the different sign-ins and their different time stamps. 
 
 Sign-ins are aggregated in the non-interactive users when the following data matches:
 
@@ -142,7 +142,7 @@ Managed identities for Azure resources sign-ins are sign-ins that were performed
 
  You can't customize the fields shown in this report.
 
-To make it easier to digest the data, managed identities for Azure resources sign in logs, non-interactive sign-in events are grouped. Sign-ins from the same entity are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the managed identities report when all of the following data matches:
+To make it easier to digest the data, managed identities for Azure resources sign-in logs, non-interactive sign-in events are grouped. Sign-ins from the same entity are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the managed identities report when all of the following data matches:
 
 - Managed identity name or ID
 - Status

articles/active-directory/reports-monitoring/howto-customize-filter-logs.md

@@ -45,27 +45,27 @@ You can always access your own sign-in history at [https://mysignins.microsoft.c
 
 With the information in the Azure AD audit logs, you can access all records of system activities for compliance purposes. Audit logs can be accessed from the **Monitoring and health** section of Azure AD, where you can sort and filter on every category and activity. You can also access audit logs in the area of the portal for the service you're investigating.
 
-![Screenshot of the audit logs option on the side menu.](media/howto-customize-filter-logs/audit-logs-nav.png)
+![Screenshot of the audit logs option on the side menu.](media/howto-customize-filter-logs/audit-logs-navigation.png)
 
 For example, if you're looking into changes to Azure AD groups, you can access the Audit logs from **Azure AD** > **Groups**. When you access the audit logs from the service, the filter is automatically adjusted according to the service.
 
 ![Screenshot of the audit logs option from the Groups menu.](media/howto-customize-filter-logs/audit-logs-groups.png)
 
 ### Customize the layout of the audit logs
 
-Audit logs can be customized like the sign-in logs. There aren't as many column options, but it's just as important to make sure you're seeing the columns you need. The **Service**, **Category** and **Activity** columns are related to each other, so these should always be visible. 
+Audit logs can be customized like the sign-in logs. There aren't as many column options, but it's as important to make sure you're seeing the columns you need. The **Service**, **Category** and **Activity** columns are related to each other, so these columns should always be visible. 
 
 ### Filter the audit logs
 
 When you filter the logs by **Service**, the **Category** and **Activity** details automatically change. In some cases, there may only be one Category or Activity. For a detailed table of all potential combinations of these details, see [Audit activities](reference-audit-activities.md).
 
-![Screenshot of the audit log activities filter with Conditional Access as the service.](media/howto-customize-filter-logs/audit-log-activities-filter.png)
+:::image type="content" source="media/howto-customize-filter-logs/audit-log-activities-filter.png" alt-text="Screenshot of the audit log activities filter with Conditional Access as the service." lightbox="media/howto-customize-filter-logs/audit-log-activities-filter-expanded.png":::
 
 ## Sign-in logs
 
-On the sign-in logs page, you can switch between four sign-in log types. For more information on the the logs, see [What are Azure AD sign-in logs?](concept-sign-ins.md).
+On the sign-in logs page, you can switch between four sign-in log types. For more information on the logs, see [What are Azure AD sign-in logs?](concept-sign-ins.md).
 
-![Screenshot of the sign-in log types.](./media/howto-customize-filter-logs/sign-in-logs-types.png)
+:::image type="content" source="media/howto-customize-filter-logs/sign-in-logs-types.png" alt-text="Screenshot of the sign-in log types." lightbox="media/howto-customize-filter-logs/sign-in-logs-types-expanded.png":::
 
 - **Interactive user sign-ins:** Sign-ins where a user provides an authentication factor, such as a password, a response through an MFA app, a biometric factor, or a QR code.
 
@@ -94,7 +94,7 @@ Select the **Add filters** option from the top of the table to get started.
 
 ![Screenshot of the sign-in logs page with the Add filters option highlighted.](./media/howto-customize-filter-logs/sign-in-logs-add-filters.png)
 
-Once you apply a filter, you may to either enter a specific detail - such as a Request ID - or select another filter option. 
+Once you apply a filter, you may either enter a specific detail - such as a Request ID - or select another filter option. 
 
 ![Screenshot of the filter options with a field to enter filter details open.](./media/howto-customize-filter-logs/sign-in-logs-filter-options.png)
 
@@ -113,7 +113,7 @@ You can filter on several details. The following table describes some commonly u
 
 Now that your sign-in logs table is formatted for your needs, you can more effectively analyze the data. Further analysis and retention of sign-in data can be accomplished by exporting the logs to other tools. 
 
-Customizing the columns and adjusting the filter helps to look at logs with similar characteristics. To look at the details of a sign-in select a row in the table to open the **Activity Details** panel. There are several tabs in the panel to explore. For more information, see [Sign-in log activity details](concept-sign-in-log-activity-details.md).
+Customizing the columns and adjusting the filter helps to look at logs with similar characteristics. To look at the details of a sign-in, select a row in the table to open the **Activity Details** panel. There are several tabs in the panel to explore. For more information, see [Sign-in log activity details](concept-sign-in-log-activity-details.md).
 
 :::image type="content" source="media/howto-customize-filter-logs/sign-in-activity-details.png" alt-text="Screenshot of the sign-in activity details." lightbox="media/howto-customize-filter-logs/sign-in-activity-details-expanded.png":::
 
@@ -123,14 +123,14 @@ Customizing the columns and adjusting the filter helps to look at logs with simi
 
 - **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 will show 'Success'.
+    - *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. 
 
-- **Home tenant name:** Due to privacy commitments, Azure AD does not populate the home tenant name field in the case of a cross-tenant scenario.
+- **Home tenant name:** Due to privacy commitments, Azure AD doesn't populate the home tenant name field during cross-tenant scenarios.
 
 - **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`.
 
-- **Client app:** The **Client app** filter option has two sub-categories: **Modern authentication clients** and **Legacy authentication clients**.
+- **Client app:** The **Client app** filter option has two subcategories: **Modern authentication clients** and **Legacy authentication clients**.
     - *Browser* and *Mobile apps and desktop clients* are the two options in the Modern authentication clients category.
     - Review the following table for the *Legacy authentication client* details.