Merge pull request #212102 from MicrosoftDocs/main

9/21 PM Publish

Author: huypub

.openpublishing.publish.config.json

@@ -674,6 +674,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "cosmos-db-sql-api-javascript-samples",
+      "url": "https://github.com/Azure-Samples/cosmos-db-sql-api-javascript-samples",
+      "branch": "main",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "azure-cosmos-db-python-getting-started",
       "url": "https://github.com/Azure-Samples/azure-cosmos-db-python-getting-started",

articles/active-directory/develop/reference-aadsts-error-codes.md

@@ -348,6 +348,7 @@ The `error` field has several possible values - review the protocol documentatio
 | AADSTS700022 | InvalidMultipleResourcesScope - The provided value for the input parameter scope isn't valid because it contains more than one resource. |
 | AADSTS700023 | InvalidResourcelessScope - The provided value for the input parameter scope isn't valid when request an access token. |
 | AADSTS7000215 | Invalid client secret is provided. Developer error - the app is attempting to sign in without the necessary or correct authentication parameters.|
+| AADSTS7000218 | The request body must contain the following parameter: 'client_assertion' or 'client_secret'. |
 | AADSTS7000222 | InvalidClientSecretExpiredKeysProvided - The provided client secret keys are expired. Visit the Azure portal to create new keys for your app, or consider using certificate credentials for added security: [https://aka.ms/certCreds](./active-directory-certificate-credentials.md) |
 | AADSTS700005 | InvalidGrantRedeemAgainstWrongTenant - Provided Authorization Code is intended to use against other tenant, thus rejected. OAuth2 Authorization Code must be redeemed against same tenant it was acquired for (/common or /{tenant-ID} as appropriate) |
 | AADSTS1000000 | UserNotBoundError - The Bind API requires the Azure AD user to also authenticate with an external IDP, which hasn't happened yet. |

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/develop/v2-oauth2-auth-code-flow.md

@@ -72,7 +72,7 @@ client_id=6731de76-14a6-49ae-97bc-6eba6914391e
 &response_type=code
 &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
 &response_mode=query
-&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
+&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
 &state=12345
 &code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
 &code_challenge_method=S256

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/fundamentals/security-operations-user-accounts.md

@@ -257,8 +257,8 @@ The following are listed in order of importance based on the effect and severity
 | What to monitor| Risk Level| Where| Filter/sub-filter| Notes |
 | - |- |- |- |- |
 | Users authenticating to other Azure AD tenants.| Low| Azure AD Sign-ins log| Status = success<br>Resource tenantID != Home Tenant ID| Detects when a user has successfully authenticated to another Azure AD tenant with an identity in your organization's tenant.<br>Alert if Resource TenantID isn't equal to Home Tenant ID <br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AuditLogs/UsersAuthenticatingtoOtherAzureADTenants.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|
-|User state changed from Guest to Member|Medium|Azure AD Audit logs|Activity: Update user<br>Category: UserManagement<br>UserType changed from Guest to Member|Monitor and alert on change of user type from Guest to Member. Was this expected?<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/UserStatechangedfromGuesttoMember.yaml<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure))
-|Guest users invited to tenant by non-approved inviters|Medium|Azure AD Audit logs|Activity: Invite external user<br>Category: UserManagement<br>Initiated by (actor): User Principal Name|Monitor and alert on non-approved actors inviting external users.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/GuestUsersInvitedtoTenantbyNewInviters.yaml<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|
+|User state changed from Guest to Member|Medium|Azure AD Audit logs|Activity: Update user<br>Category: UserManagement<br>UserType changed from Guest to Member|Monitor and alert on change of user type from Guest to Member. Was this expected?<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/UserStatechangedfromGuesttoMember.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)
+|Guest users invited to tenant by non-approved inviters|Medium|Azure AD Audit logs|Activity: Invite external user<br>Category: UserManagement<br>Initiated by (actor): User Principal Name|Monitor and alert on non-approved actors inviting external users.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/GuestUsersInvitedtoTenantbyNewInviters.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|
 
 ### Monitoring for failed unusual sign ins
 

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)