You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/develop/saml-claims-customization.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ Any constant (static) value can be assigned to any claim. Use the following step
83
83
1. On the **Attributes & Claims** blade, select the required claim that you want to modify.
84
84
1. Enter the constant value without quotes in the **Source attribute** as per your organization and select **Save**. The constant value is displayed.
85
85
86
-
### Directory Schema extensions
86
+
### Directory Schema extensions (Preview)
87
87
88
88
You can also configure directory schema extension attributes as non-conditional/conditional attributes. Use the following steps to configure the single or multi-valued directory schema extension attribute as a claim:
89
89
@@ -116,7 +116,7 @@ To apply a transformation to a user attribute:
116
116
117
117
1. In **Manage claim**, select *Transformation* as the claim source to open the **Manage transformation** page.
118
118
1. Select the function from the transformation dropdown. Depending on the function selected, provide parameters and a constant value to evaluate in the transformation.
119
-
1. Select the source of the attribute by clicking on the appropriate radio button.
119
+
1. Select the source of the attribute by clicking on the appropriate radio button. Directory schema extension source is in preview currently.
120
120
1. Select the attribute name from the dropdown.
121
121
1.**Treat source as multivalued** is a checkbox indicating whether the transform should be applied to all values or just the first. By default, transformations are only applied to the first element in a multi-value claim, by checking this box it ensures it's applied to all. This checkbox is only be enabled for multi-valued attributes, for example `user.proxyaddresses`.
122
122
1. To apply multiple transformations, select **Add transformation**. You can apply a maximum of two transformations to a claim. For example, you could first extract the email prefix of the `user.mail`. Then, make the string upper case.
@@ -237,7 +237,7 @@ To add a claim condition:
237
237
1. In **Manage claim**, expand the Claim conditions.
238
238
1. Select the user type.
239
239
1. Select the group(s) to which the user should belong. You can select up to 50 unique groups across all claims for a given application.
240
-
1. Select the **Source** where the claim is going to retrieve its value. You can either select a user attribute from the dropdown for the source attribute or apply a transformation to the user attribute. You can also select a directory schema extension before emitting it as a claim.
240
+
1. Select the **Source** where the claim is going to retrieve its value. You can either select a user attribute from the dropdown for the source attribute or apply a transformation to the user attribute. You can also select a directory schema extension (preview) before emitting it as a claim.
241
241
242
242
The order in which you add the conditions are important. Microsoft Entra first evaluates all conditions with source `Attribute` and then evaluates all conditions with source `Transformation` to decide which value to emit in the claim. Conditions with the same source are evaluated from top to bottom. The last value, which matches the expression is emitted in the claim. Transformations such as `IsNotEmpty` and `Contains` act like restrictions.
Copy file name to clipboardExpand all lines: articles/active-directory/develop/sample-v2-code.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -285,7 +285,7 @@ The following samples show how to build applications for the Java language and p
285
285
> | Web API |[Sign in users](https://github.com/Azure-Samples/ms-identity-msal-java-samples/tree/main/4-spring-web-app/3-Authorization-II/protect-web-api)|[MSAL Java](/java/api/com.microsoft.aad.msal4j)| On-Behalf-Of (OBO) |
286
286
> | Desktop |[Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-msal-java-samples/tree/main/2-client-side/Integrated-Windows-Auth-Flow)|[MSAL Java](/java/api/com.microsoft.aad.msal4j)| Integrated Windows authentication |
287
287
> | Mobile |[Sign in users and call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-android-java)|[MSAL Android](https://github.com/AzureAD/microsoft-authentication-library-for-android)| Authorization code with PKCE |
288
-
> | Headless |[Sign in users and invoke protected API from text-only device](https://github.com/Azure-Samples/ms-identity-msal-java-samples/tree/main/2.%20Client-Side%20Scenarios/Device-Code-Flow)|[MSAL Java](/java/api/com.microsoft.aad.msal4j)| Device code |
288
+
> | Headless | Sign in users and invoke protected API from text-only device |[MSAL Java](/java/api/com.microsoft.aad.msal4j)| Device code |
289
289
> | Service/</br>daemon |•[Call Microsoft Graph with Secret](https://github.com/Azure-Samples/ms-identity-msal-java-samples/tree/main/1-server-side/msal-client-credential-secret) <br/> •[Call Microsoft Graph with Certificate](https://github.com/Azure-Samples/ms-identity-msal-java-samples/tree/main/1-server-side/msal-client-credential-certificate)|[MSAL Java](/java/api/com.microsoft.aad.msal4j)| Client credentials grant|
Copy file name to clipboardExpand all lines: articles/active-directory/governance/lifecycle-workflow-history.md
+45-2Lines changed: 45 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ ms.custom: template-concept
17
17
18
18
19
19
20
-
Workflows created using Lifecycle Workflows allow for the automation of lifecycle task for users no matter where they fall in the Joiner-Mover-Leaver (JML) model of their identity lifecycle in your organization. Making sure workflows are processed correctly is an important part of an organization's lifecycle management process. Workflows that aren't processed correctly can lead to many issues in terms of security and compliance. With Lifecycle Workflow's history features, you can specify which workflow events you want to view a history of based on user, runs, or task summaries. This reporting feature allows you to quickly see what ran for who, and rather or not it was successful. Along with the summaries in these specific areas, you're also able to view detailed information about each specific event recorded in their respective summary section. In this article you'll learn the difference between the three different type of history summaries, and details, you can query with Lifecycle Workflows. You'll also learn when you would use each when getting more information about how your workflows were utilized for users in your organization. For detailed information about every action Lifecycle Workflows take, see: [Auditing Lifecycle Workflows](lifecycle-workflow-audits.md).
20
+
Workflows created using Lifecycle Workflows allow for the automation of lifecycle task for users no matter where they fall in the Joiner-Mover-Leaver (JML) model of their identity lifecycle in your organization. Making sure workflows are processed correctly is an important part of an organization's lifecycle management process. Workflows that aren't processed correctly can lead to many issues in terms of security and compliance. With Lifecycle Workflow's history features, you can specify which workflow events you want to view a history of based on users, runs, or task summaries. This reporting feature allows you to quickly see what ran for who, and rather or not it was successful. Along with the summaries in these specific areas, you're also able to view detailed information about each specific event recorded in their respective summary section. In this article, you'll learn the difference between the three different type of history summaries, and details, you can query with Lifecycle Workflows. You'll also learn when you would use each when getting more information about how your workflows were utilized for users in your organization. For detailed information about every action Lifecycle Workflows takes, see: [Auditing Lifecycle Workflows](lifecycle-workflow-audits.md).
21
21
22
22
## Lifecycle Workflow History Summaries
23
23
@@ -56,9 +56,23 @@ User detailed history information allows you to filter for specific information
56
56
-**Workflow execution type**: You can filter on workflow execution type such as **Scheduled** or **on-demand**
57
57
-**Completed date**: You can filter a specific range from as short as 24 hours up to 30 days of when the user was processed in a workflow.
58
58
59
+
### User history status details
60
+
61
+
When viewing the status of user processing history, the status values correspond to the following information:
62
+
63
+
|Status |Details |
64
+
|---------|---------|
65
+
|Completed | This state is reported if all of the workflow's tasks processes successfully for a user. |
66
+
|In Progress | This state is reported when a workflow begins running tasks for a user.. The status remains in this state until all the workflow's tasks are processed for the user, or it fails. |
67
+
|Queued | This state is reported when a user is identified by the Lifecycle Workflow engine that meets the execution conditions of a workflow. From here a user either enters a state of *In progress* if the workflow begins running for them, or canceled if the admin manually cancels the workflow. |
68
+
|Canceled | This state is reported for the following reasons: <br><br>**1.** If the workflow was deleted, all scheduled users it's set to run for are canceled.<br>**2.** If the workflow was disabled, all scheduled users it's set to run for are canceled.<br>**3**. If the workflow's schedule was disabled, all scheduled users it's set to run for are canceled.<br>**4.** If the workflow had a new version created and all tasks were disabled, all scheduled users it's set to run for are canceled.<br>**5.** If users don't meet the current execution conditions of the workflow's new version, the scheduled runs are canceled.<br>**6.** If the user was queued to have the workflow run for them, but has a profile change and no longer meet the current execution conditions of the workflow immediately before it runs, the processing is canceled. |
69
+
|Completed with errors | This state is reported if the workflow completed, but one or more tasks that are set have **continueOnError** set as *true* have failed. |
70
+
|Failed | This state is reported if a task with **continueOnError** set as *false* fails. |
71
+
59
72
For a complete guide on getting user processed summary information, see: [User workflow history using the Microsoft Entra admin center](check-status-workflow.md#user-workflow-history-using-the-microsoft-entra-admin-center).
60
73
61
74
75
+
62
76
## Runs Summary
63
77
64
78
Runs summaries allow you to view workflow information through the lens of its run history
@@ -84,7 +98,22 @@ Runs detailed history information allows you to filter for specific information
84
98
-**Workflow execution type**: You can filter on workflow execution type such as **Scheduled** or **On-demand**.
85
99
-**Completed date**: You can filter a specific range from as short as 24 hours up to 30 days of when the workflow ran.
86
100
87
-
For a complete guide on getting runs information, see: [Run workflow history using the Microsoft Entra admin center](check-status-workflow.md#run-workflow-history-using-the-microsoft-entra-admin-center)
101
+
### Runs history status details
102
+
103
+
When viewing the status of run history, the status values correspond to the following information:
104
+
105
+
106
+
|Status |Details |
107
+
|---------|---------|
108
+
|Queued | This state is reported the first time a workflow is set to run. |
109
+
|In Progress | This state is reported as soon as the workflow begins processing its first task. |
110
+
|Canceled | This state is reported if it was *In Progress* at one point of time, and is now frozen in that state. |
111
+
|Completed with errors | This state is reported if the workflow runs successfully for some, but not others. If a workflow enters the queued state, but all of its instances are canceled before executing, then it will also show this state before ever entering a state of *In Progress*. |
112
+
|Completed | This state is reported if the workflow ran successfully for every user. |
113
+
|Failed | This state is reported if all tasks failed for all users the workflow runs for. Canceled users aren't counted as failures in the report. |
114
+
115
+
For a complete guide on getting runs information, see: [Run workflow history using the Microsoft Entra admin center](check-status-workflow.md#run-workflow-history-using-the-microsoft-entra-admin-center).
116
+
88
117
89
118
90
119
## Tasks summary
@@ -113,6 +142,20 @@ Task detailed history information allows you to filter for specific information
113
142
-**Completed date**: You can filter a specific range from as short as 24 hours up to 30 days of when the workflow ran.
114
143
-**Tasks**: You can filter based on specific task names.
115
144
145
+
### Task history status details
146
+
147
+
When viewing the status of task history, the status values correspond to the following information:
148
+
149
+
150
+
|Status |Details |
151
+
|---------|---------|
152
+
|Queued | This state is reported once a workflow instance is scheduled for execution, task reports for all of the tasks within the workflow are also created with this status with Run record. Each task report includes all users but represents a specific task. |
153
+
|In Progress | This state is reported as soon as the first task begins being processed. |
154
+
|Canceled | This state is reported if no tasks are processed before the workflow is canceled. If a workflow that contains the tasks is deleted, then the status will also show as canceled. |
155
+
|Completed with errors | This state is reported if a task is processed for a user, but not every task succeeds. |
156
+
|Completed | This state is reported if all tasks ran successfully for every user. |
157
+
|Failed | This state is reported if all tasks failed. |
158
+
116
159
Separating processing of the workflow from the tasks is important because, in a workflow, processing a user certain tasks could be successful, while others could fail. Whether or not a task runs after a failed task in a workflow depends on parameters such as enabling continue On Error, and their placement within the workflow. For more information, see [Common task parameters](lifecycle-workflow-tasks.md#common-task-parameters).
Copy file name to clipboardExpand all lines: articles/active-directory/hybrid/cloud-sync/migrate-azure-ad-connect-to-cloud-sync.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ Microsoft Entra Cloud Sync is the future for accomplishing your hybrid identity
44
44
|Verify all users are provisioned|As you migrate users, verify that they're provisioning and synchronizing correctly.|
45
45
|Stop Microsoft Entra Connect|Once you've verified that all of your users are migrated, you can turn off the Microsoft Entra Connect synchronization service. Microsoft recommends that you leave the server is a disabled state for a period of time, so you can verify the migration was successful
46
46
|Verify everything is good|After a period of time, verify that everything is good.|
47
-
|Decommission the Microsoft Entra Connect server|Once you've verified everything is good you can use the steps below to take the Microsoft Entra Connect server offline.|
47
+
|Decommission the Microsoft Entra Connect server|Once you've verified everything is good, take the Microsoft Entra Connect server offline. For more information, see [Uninstall Microsoft Entra Connect](../connect/how-to-connect-uninstall.md).|
Copy file name to clipboardExpand all lines: articles/active-directory/hybrid/connect/how-to-connect-fed-group-claims.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -257,7 +257,7 @@ You can also configure group claims in the [optional claims](../../develop/optio
257
257
258
258
In `additionalProperties`, only one of `"sam_account_name"`, `"dns_domain_and_sam_account_name"`, or `"netbios_domain_and_sam_account_name"` is required. If more than one is present, the first is used and any others are ignored.
259
259
260
-
Some applications require group information about the user in the role claim. To change the claim type to from a group claim to a role claim, add `"emit_as_roles"` to additional properties. The group values will be emitted in the role claim.
260
+
Some applications require group information about the user in the role claim. To change the claim type from a group claim to a role claim, add `"emit_as_roles"` to additional properties. The group values will be emitted in the role claim.
261
261
262
262
To emit group display name for cloud-only groups, you can add `"cloud_displayname"` to `additional properties`. This option will work only when `“groupMembershipClaims”` is set to `ApplicationGroup`
Copy file name to clipboardExpand all lines: articles/active-directory/hybrid/connect/how-to-connect-fed-saml-idp.md
+26-10Lines changed: 26 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,16 +92,32 @@ A request and response message pair is shown for the sign-on message exchange.
92
92
The following is a sample request message that is sent from Microsoft Entra ID to a sample SAML 2.0 identity provider. The sample SAML 2.0 identity provider is Active Directory Federation Services (AD FS) configured to use SAML-P protocol. Interoperability testing has also been completed with other SAML 2.0 identity providers.
0 commit comments