fix blocking issues

Author: omondiatieno

articles/active-directory/develop/howto-restrict-your-app-to-a-set-of-users.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: how-to
-ms.date: 03/27/2023
+ms.date: 03/28/2023
 ms.author: cwerner
 ms.reviewer: jmprieur, kkrishna
 ms.custom: aaddev, engagement-fy23
@@ -22,7 +22,7 @@ Applications registered in an Azure Active Directory (Azure AD) tenant are, by d
 
 Similarly, in a [multi-tenant](howto-convert-app-to-be-multi-tenant.md) application, all users in the Azure AD tenant where the application is provisioned can access the application once they successfully authenticate in their respective tenant.
 
-Tenant administrators and developers often have requirements where an application must be restricted to a certain set of users or apps(services). There are two ways to restrict an application to a certain set of users, apps or security groups:
+Tenant administrators and developers often have requirements where an application must be restricted to a certain set of users or apps (services). There are two ways to restrict an application to a certain set of users, apps or security groups:
 
 - Developers can use popular authorization patterns like [Azure role-based access control (Azure RBAC)](howto-implement-rbac-for-apps.md).
 - Tenant administrators and developers can use built-in feature of Azure AD.
@@ -32,7 +32,7 @@ Tenant administrators and developers often have requirements where an applicatio
 The option to restrict an app to a specific set of users, apps or security groups in a tenant works with the following types of applications:
 
 - Applications configured for federated single sign-on with SAML-based authentication.
-- Application proxy applications that use Azure AD pre-authentication.
+- Application proxy applications that use Azure AD preauthentication.
 - Applications built directly on the Azure AD application platform that use OAuth 2.0/OpenID Connect authentication after a user or admin has consented to that application.
 
 ## Update the app to require user assignment
@@ -54,10 +54,10 @@ When an application requires assignment, user consent for that application isn't
 
 Once you've configured your app to enable user assignment, you can go ahead and assign the app to users and groups.
 
-1. Under **Manage**, select the **Users and groups** then select **Add user/group** .
+1. Under **Manage**, select the **Users and groups** then select **Add user/group**.
 1. Select the **Users** selector.
 
-   A list of users and security groups will be shown along with a textbox to search and locate a certain user or group. This screen allows you to select multiple users and groups in one go.
+   A list of users and security groups are shown along with a textbox to search and locate a certain user or group. This screen allows you to select multiple users and groups in one go.
 
 1. Once you're done selecting the users and groups, select **Select**.
 1. (Optional) If you have defined app roles in your application, you can use the **Select role** option to assign the app role to the selected users and groups.
@@ -70,31 +70,31 @@ Follow the steps in this section to secure app-to-app authentication access for
 
 1.	Navigate to Service Principal sign-in logs in your tenant to find services authenticating to access resources in your tenant.
 1.	Check using app ID if a Service Principal exists for both resource and client apps in your tenant that you wish to manage access.
-   ```powershell
-   Get-MgServicePrincipal `
-   -Filter "AppId eq '$appId'"
-   ```
-1.	Create a Service Principal using app ID, if it does not exist:
-   ```powershell
-   New-MgServicePrincipal `
-   -AppId $appId
-   ```
+      ```powershell
+      Get-MgServicePrincipal `
+      -Filter "AppId eq '$appId'"
+      ```
+1.	Create a Service Principal using app ID, if it doesn't exist:
+      ```powershell
+      New-MgServicePrincipal `
+      -AppId $appId
+      ```
 1.	Explicitly assign client apps to resource apps (this functionality is available only in API and not in the Azure AD Portal):
-   ```powershell
-   $clientAppId = “[guid]”
-                  $clientId = (Get-MgServicePrincipal -Filter "AppId eq '$clientAppId'").Id
-   New-MgServicePrincipalAppRoleAssignment `
-   -ServicePrincipalId $clientId `
-   -PrincipalId $clientId `
-   -ResourceId (Get-MgServicePrincipal -Filter "AppId eq '$appId'").Id `
-   -AppRoleId "00000000-0000-0000-0000-000000000000"
-   ```
+      ```powershell
+      $clientAppId = “[guid]”
+                     $clientId = (Get-MgServicePrincipal -Filter "AppId eq '$clientAppId'").Id
+      New-MgServicePrincipalAppRoleAssignment `
+      -ServicePrincipalId $clientId `
+      -PrincipalId $clientId `
+      -ResourceId (Get-MgServicePrincipal -Filter "AppId eq '$appId'").Id `
+      -AppRoleId "00000000-0000-0000-0000-000000000000"
+      ```
 1.	Require assignment for the resource application to restrict access only to the explicitly assigned users or services.
-   ```powershell
-   Update-MgServicePrincipal -ServicePrincipalId (Get-MgServicePrincipal -Filter "AppId eq '$appId'").Id -AppRoleAssignmentRequired:$true
-   ```
-> [!NOTE]
-> If you don't want tokens to be issued for an application or if you want to block an application from being accessed by users or services in your tenant, create a service principal for the application and [disable user sign-in](../manage-apps/disable-user-sign-in-portal.md) for it.
+      ```powershell
+      Update-MgServicePrincipal -ServicePrincipalId (Get-MgServicePrincipal -Filter "AppId eq '$appId'").Id -AppRoleAssignmentRequired:$true
+      ```
+   > [!NOTE]
+   > If you don't want tokens to be issued for an application or if you want to block an application from being accessed by users or services in your tenant, create a service principal for the application and [disable user sign-in](../manage-apps/disable-user-sign-in-portal.md) for it.
 
 ## More information
 

articles/active-directory/reports-monitoring/media/reports-faq/service-principal-sign-ins.png

@@ -29,7 +29,7 @@ sections:
       - question: |
           How soon should I see activities data after getting a premium license?
         answer: |
-          If you already have activities data as a free license, then you can see it immediately. If you don't have any data, then it will take up to three days for the data to show up in the reports.
+          If you already have activities data as a free license, then you can see it immediately. If you don't have any data, then it takes up to three days for the data to show up in the reports.
 
       - question: |
           Can I see last month's data after getting an Azure AD premium license?
@@ -97,29 +97,29 @@ sections:
       - question: |
           Why do my non-interactive sign-ins appear to have the same time stamp?
         answer: |
-          Non-interactive sign-ins can trigger a large volume of events every hour, so they are grouped together in the logs.
+          Non-interactive sign-ins can trigger a large volume of events every hour, so they're grouped together in the logs.
           
-          In many cases, non-interactive sign-ins have all the same characteristics, except for the date and time of the sign-in. If the time aggregate is set to 24 hours, the logs will appear to show the sign-ins at the same time. Each of these grouped rows can be expanded to view the exact time stamp.
+          In many cases, non-interactive sign-ins have all the same characteristics, except for the date and time of the sign-in. If the time aggregate is set to 24 hours, the logs appear to show the sign-ins at the same time. Each of these grouped rows can be expanded to view the exact time stamp.
 
       - question: |
-          I am seeing User IDs in the username field of my sign-ins log. Why is this happening?
+          I'm seeing User IDs in the username field of my sign-ins log. Why is this happening?
         answer: |
-          With passwordless authentication, User IDs appear as the username. To confirm this scenario, look at the details of the sign-in event in question. The *authenticationDetail* field will say *passwordless*.
+          With passwordless authentication, User IDs appear as the username. To confirm this scenario, look at the details of the sign-in event in question. The *authenticationDetail* field says *passwordless*.
 
       - question: |
           I see a 90025 error in the sign in logs. Does this mean my user failed to sign in? Has my tenant hit a throttling limit?
         answer: |
-          No, in general 90025 errors are resolved by an automatic retry without the user noticing the error. This error can occur when an internal Azure AD subservice hits its retry allowance and does not indicate your tenant is being throttled. These errors are usually resolved by Azure AD internally without any user impact. If the user is unable to sign in due to this error, manually trying again should resolve the issue. 
+          No, in general 90025 errors are resolved by an automatic retry without the user noticing the error. This error can occur when an internal Azure AD subservice hits its retry allowance and doesn't indicate your tenant is being throttled. These errors are usually resolved by Azure AD internally without any user impact. If the user is unable to sign in due to this error, manually trying again should resolve the issue. 
 
       - question: |
           In Service Principal sign-in logs, what does it mean if I see “00000000-0000-0000-0000-000000000000” or “” for Service Principal ID or Resource Service Principal ID in my sign-in logs?
         answer: |
-          If the Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there is no Service Principal for the client application in that instance of authentication (Azure AD no longer issues access tokens without a client Service Principal except for a small number of Microsoft and 3rd party applications).
+          If the Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there's no Service Principal for the client application in that instance of authentication (Azure AD no longer issues access tokens without a client Service Principal except for a few Microsoft and third party applications).
 
-          If the Resource Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there is no Service Principal for the resource application in that instance of authentication.
+          If the Resource Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that there's no Service Principal for the resource application in that instance of authentication.
 
           > [!NOTE]
-          > Authentication without a client Service Principal is a deprecated behavior in Azure AD and is not commonly expected. This behavior is currently allowed only for a limited number of resource apps.
+          > Authentication without a client Service Principal is a deprecated behavior in Azure AD and isn't commonly expected. This behavior is currently allowed only for a limited number of resource apps.
  
       - question: |
           In Service Principal sign-in logs, how can I query for instances of authentication without a client or resource Service Principal in my tenant? (That is, Service Principal ID or Resource Service Principal ID is “00000000-0000-0000-0000-000000000000” or “”)
@@ -141,8 +141,6 @@ sections:
           - Make sure you select an appropriate time frame in the Date field (last 24 hours, 7 days etc.).
           -	Add a filter and select **Service Principal ID** and provide the value ‘00000000-0000-0000-0000-000000000000' to get instances of authentication with no client Service Principal.
             
-            :::image type="content" source="media/reports-faq/service-principal-sign-ins.png" alt-text="Screenshot of service principal sign-in.":::
-
       - question: |
           How can I restrict sign-in (authentication) for various apps that I see in the Service Principal sign-in logs?
         answer: