Skip to content

Commit e017947

Browse files
committed
Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into cdnfreshness2
2 parents ffcb568 + 3226369 commit e017947

File tree

783 files changed

+10146
-8836
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

783 files changed

+10146
-8836
lines changed

.openpublishing.redirection.azure-monitor.json

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,16 @@
3030
"redirect_url": "/azure/azure-monitor/change/change-analysis",
3131
"redirect_document_id": false
3232
},
33+
{
34+
"source_path_from_root": "/articles/azure-monitor/app/visual-studio.md",
35+
"redirect_url": "https://learn.microsoft.com/visualstudio/azure/azure-app-insights-add-connected-service",
36+
"redirect_document_id": false
37+
},
38+
{
39+
"source_path_from_root": "/articles/azure-monitor/app/visual-studio-codelens.md",
40+
"redirect_url": "https://learn.microsoft.com/visualstudio/azure/azure-app-insights-add-connected-service",
41+
"redirect_document_id": false
42+
},
3343
{
3444
"source_path_from_root": "/articles/azure-monitor/app/javascript-react-plugin.md",
3545
"redirect_url": "/azure/azure-monitor/app/javascript-framework-extensions",

.openpublishing.redirection.json

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21965,6 +21965,16 @@
2196521965
"source_path": "articles/virtual-machines/workloads/sap/index.md",
2196621966
"redirect_URL": "/azure/sap/workloads/get-started",
2196721967
"redirect_document_id": false
21968+
},
21969+
{
21970+
"source_path": "articles/private-multi-access-edge-compute-mec/deploy-metaswitch-fusion-core-solution.md",
21971+
"redirect_URL": "/azure/private-5g-core",
21972+
"redirect_document_id": false
21973+
},
21974+
{
21975+
"source_path": "articles/private-multi-access-edge-compute-mec/metaswitch-fusion-core-overview.md",
21976+
"redirect_URL": "/azure/private-5g-core",
21977+
"redirect_document_id": false
2196821978
}
2196921979
]
2197021980
}

articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ ms.service: active-directory
88
ms.subservice: app-provisioning
99
ms.workload: identity
1010
ms.topic: tutorial
11-
ms.date: 11/04/2022
11+
ms.date: 02/23/2023
1212
ms.author: kenwith
1313
ms.reviewer: arvinh
1414
---
@@ -74,7 +74,7 @@ The following table lists an example of required attributes:
7474
|lastName|name.familyName|surName|
7575
|workMail|emails[type eq “work”].value|Mail|
7676
|manager|manager|manager|
77-
|tag|urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:tag|extensionAttribute1|
77+
|tag|`urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:tag`|extensionAttribute1|
7878
|status|active|isSoftDeleted (computed value not stored on user)|
7979

8080
The following JSON payload shows an example SCIM schema:
@@ -117,7 +117,7 @@ It helps to categorize between `/User` and `/Group` to map any default user attr
117117

118118
The following table lists an example of user attributes:
119119

120-
| Azure AD user | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User |
120+
| Azure AD user | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User` |
121121
| --- | --- |
122122
| IsSoftDeleted |active |
123123
|department| `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department`|
@@ -140,7 +140,7 @@ The following table lists an example of user attributes:
140140

141141
The following table lists an example of group attributes:
142142

143-
| Azure AD group | urn:ietf:params:scim:schemas:core:2.0:Group |
143+
| Azure AD group | `urn:ietf:params:scim:schemas:core:2.0:Group` |
144144
| --- | --- |
145145
| displayName |displayName |
146146
| members |members |
@@ -218,7 +218,7 @@ Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
218218
### /Schemas (Schema discovery):
219219

220220
* [Sample request/response](#schema-discovery)
221-
* Schema discovery isn't currently supported on the custom non-gallery SCIM application, but it's being used on certain gallery applications. Going forward, schema discovery will be used as the sole method to add more attributes to the schema of an existing gallery SCIM application.
221+
* Schema discovery is being used on certain gallery applications. Schema discovery is the sole method to add more attributes to the schema of an existing gallery SCIM application. Schema discovery isn't currently supported on custom non-gallery SCIM application.
222222
* If a value isn't present, don't send null values.
223223
* Property values should be camel cased (for example, readWrite).
224224
* Must return a list response.
@@ -1373,8 +1373,8 @@ The SCIM spec doesn't define a SCIM-specific scheme for authentication and autho
13731373
|--|--|--|--|
13741374
|Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
13751375
|Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
1376-
|OAuth authorization code grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
1377-
|OAuth client credentials grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API. Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
1376+
|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
1377+
|OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API. Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
13781378

13791379
> [!NOTE]
13801380
> It's not recommended to leave the token field blank in the Azure AD provisioning configuration custom app UI. The token generated is primarily available for testing purposes.

articles/active-directory/authentication/certificate-based-authentication-faq.yml

Lines changed: 16 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@ metadata:
77
ms.service: active-directory
88
ms.subservice: authentication
99
ms.topic: faq
10-
ms.date: 10/05/2022
10+
ms.date: 02/21/2023
1111
ms.author: justinha
12-
author: vimrang
12+
author: justinha
1313
manager: amycolannino
1414
ms.reviewer: vimrang
1515
ms.collection: M365-identity-device-management
@@ -69,7 +69,7 @@ sections:
6969
7070
Use the [Set-AzureADTrustedCertificateAuthority](/powershell/module/azuread/set-azureadtrustedcertificateauthority) cmdlet:
7171
72-
```powershell
72+
```PowerShell
7373
$c=Get-AzureADTrustedCertificateAuthority
7474
$c[0]. crlDistributionPoint=""
7575
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
@@ -120,14 +120,14 @@ sections:
120120
The browser caches the certificate after the certificate picker appears. If the user retries, the cached certificate is used automatically. The user should close the browser, and reopen a new session to try CBA again.
121121
122122
- question: |
123-
Why does not proof up for registering other auth methods come up when I use single factor certificates?
123+
Why doesn't proof up for registering other auth methods come up when I use single factor certificates?
124124
answer: |
125-
A user will be considered MFA capable when a user is in scope for Certificate-based authentication auth method. This means user will not be able to use proof up as part of their authentication to registerd other available methods and should have MFA via another method to register other available auth methods.
125+
A user is considered capable for MFA when the user is in scope for **Certificate-based authentication** in the Authentication methods policy. This policy requirement means a user can't use proof up as part of their authentication to register other available methods.
126126
127127
- question: |
128128
How can I use single-factor certificates to complete MFA?
129129
answer: |
130-
We have support for single factor CBA to get MFA. CBA SF + PSI (passwordless phone sign in) and CBA SF + FIDO2 are the two supported combinations to get MFA using single factor certificates.
130+
We have support for single factor CBA to get MFA. CBA SF + passwordless phone sign-in (PSI) and CBA SF + FIDO2 are the two supported combinations to get MFA using single factor certificates.
131131
[MFA with single factor certificates](../authentication/concept-certificate-based-authentication-technical-deep-dive.md#mfa-authentication-flow-using-single-factor-certificates-and-passwordless-sign-in)
132132
133133
- question: |
@@ -146,7 +146,16 @@ sections:
146146
GET https://graph.microsoft.com/v1.0/users?$filter=certificateUserIds/any(x:x eq '[email protected]')
147147
```
148148
149-
149+
- question: |
150+
After a CRL endpoint is configured, end users aren't able to sign in and they see the following diagnostic message:
151+
152+
```http
153+
AADSTS500173: Unable to download CRL. Invalid status code Forbidden from CRL distribution point
154+
errorCode: 500173
155+
```
156+
157+
answer: |
158+
This is commonly seen when a firewall rule setting blocks access to the CRL endpoint.
150159
151160
additionalContent: |
152161
## Next steps

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -37,9 +37,6 @@ There are multiple scenarios that organizations can now enable using filter for
3737

3838
Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
3939

40-
> [!IMPORTANT]
41-
> Device state and filter for devices cannot be used together in Conditional Access policy.
42-
4340
The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios).
4441

4542
Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.

articles/active-directory/conditional-access/concept-conditional-access-grant.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -194,7 +194,7 @@ When user risk is detected, administrators can employ the user risk policy condi
194194
When a user is prompted to change a password, they'll first be required to complete multifactor authentication. Make sure all users have registered for multifactor authentication, so they're prepared in case risk is detected for their account.
195195

196196
> [!WARNING]
197-
> Users must have previously registered for self-service password reset before triggering the user risk policy.
197+
> Users must have previously registered for multifactor authentication before triggering the user risk policy.
198198
199199
The following restrictions apply when you configure a policy by using the password change control:
200200

articles/active-directory/conditional-access/concept-conditional-access-policies.md

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -83,10 +83,6 @@ The software the user is employing to access the cloud app. For example, 'Browse
8383

8484
The behavior of the client apps condition was updated in August 2020. If you have existing Conditional Access policies, they'll remain unchanged. However, if you select on an existing policy, the configure toggle has been removed and the client apps the policy applies to are selected.
8585

86-
#### Device state
87-
88-
This control is used to exclude devices that are hybrid Azure AD joined, or marked a compliant in Intune. This exclusion can be done to block unmanaged devices.
89-
9086
#### Filter for devices
9187

9288
This control allows targeting specific devices based on their attributes in a policy.

articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ Sign-in frequency previously applied to only to the first factor authentication
5858

5959
### User sign-in frequency and device identities
6060

61-
On Azure AD joined and hybrid Azure AD joined devices, unlocking the device, or signing in interactively will only refresh the Primary Refresh Token (PRT) every 4 hours. The last refresh timestamp recorded for PRT compared with the current timestamp must be within the time allotted in SIF policy for PRT to satisfy SIF and grant access to a PRT that has an existing MFA claim. On [Azure AD registered devices](/active-directory/devices/concept-azure-ad-register), unlock/sign-in would not satisfy the SIF policy because the user is not accessing an Azure AD registered device via an Azure AD account. However, the [Azure AD WAM](../develop/scenario-desktop-acquire-token-wam.md) plugin can refresh a PRT during native application authentication using WAM.
61+
On Azure AD joined and hybrid Azure AD joined devices, unlocking the device, or signing in interactively will only refresh the Primary Refresh Token (PRT) every 4 hours. The last refresh timestamp recorded for PRT compared with the current timestamp must be within the time allotted in SIF policy for PRT to satisfy SIF and grant access to a PRT that has an existing MFA claim. On [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register), unlock/sign-in would not satisfy the SIF policy because the user is not accessing an Azure AD registered device via an Azure AD account. However, the [Azure AD WAM](../develop/scenario-desktop-acquire-token-wam.md) plugin can refresh a PRT during native application authentication using WAM.
6262

6363
Note: The timestamp captured from user log-in is not necessarily the same as the last recorded timestamp of PRT refresh because of the 4-hour refresh cycle. The case when it is the same is when a PRT has expired and a user log-in refreshes it for 4 hours. In the following examples, assume SIF policy is set to 1 hour and PRT is refreshed at 00:00.
6464

@@ -196,4 +196,4 @@ We factor for five minutes of clock skew, so that we don’t prompt users more o
196196

197197
## Next steps
198198

199-
* If you're ready to configure Conditional Access policies for your environment, see the article [Plan a Conditional Access deployment](plan-conditional-access.md).
199+
* If you're ready to configure Conditional Access policies for your environment, see the article [Plan a Conditional Access deployment](plan-conditional-access.md).

articles/active-directory/conditional-access/resilience-defaults.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,7 @@ When resilience defaults are disabled, the Backup Authentication Service won't u
7373
7474
## Testing resilience defaults
7575

76-
It isn't possible to conduct a dry run using the Backup Authentication Service or simulate the result of a policy with resilience defaults enabled or disabled at this time. Azure AD will conduct monthly exercises using the Backup Authentication Service. The sign-in logs will display if the Backup Authentication Service was used to issue the access token.
76+
It isn't possible to conduct a dry run using the Backup Authentication Service or simulate the result of a policy with resilience defaults enabled or disabled at this time. Azure AD will conduct monthly exercises using the Backup Authentication Service. The sign-in logs will display if the Backup Authentication Service was used to issue the access token. In **Azure portal** > **Monitoring** > **Sign-in Logs** blade, you can add the filter "Token issuer type == Azure AD Backup Auth" to display the logs processed by Azure AD Backup Authentication service.
7777

7878
## Configuring resilience defaults
7979

articles/active-directory/conditional-access/workload-identity.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ These differences make workload identities harder to manage and put them at high
2929

3030
> [!IMPORTANT]
3131
> Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals.
32-
> In directories without appropriate licenses, Conditional Access policies created prior to the release of Workload Identities Premium will be available for deletion only.
32+
> In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information see [Microsoft Entra Workload Identities](https://www.microsoft.com/security/business/identity-access/microsoft-entra-workload-identities#office-StandaloneSKU-k3hubfz).  
3333
3434
> [!NOTE]
3535
> Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy.

0 commit comments

Comments
 (0)