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-domain-services/troubleshoot-alerts.md
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ ms.service: active-directory
10
10
ms.subservice: domain-services
11
11
ms.workload: identity
12
12
ms.topic: troubleshooting
13
-
ms.date: 08/17/2022
13
+
ms.date: 09/20/2022
14
14
ms.author: justinha
15
15
16
16
---
@@ -193,7 +193,9 @@ The managed domain's health automatically updates itself within two hours and re
193
193
194
194
### Resolution
195
195
196
-
This error is unrecoverable. To resolve the alert, [delete your existing managed domain](delete-aadds.md) and recreate it. If you have trouble deleting the managed domain, [open an Azure support request][azure-support] for additional troubleshooting assistance.
196
+
Azure AD DS creates additional resources to function properly, such as public IP addresses, virtual network interfaces, and a load balancer. If any of these resources are modified, the managed domain is in an unsupported state and can't be managed. For more information about these resources, see [Network resources used by Azure AD DS](network-considerations.md#network-resources-used-by-azure-ad-ds).
197
+
198
+
This alert is generated when one of these required resources is modified and can't automatically be recovered by Azure AD DS. To resolve the alert, [open an Azure support request][azure-support] to fix the instance.
# Application types for the Microsoft identity platform
19
19
20
-
The Microsoft identity platform supports authentication for a variety of modern app architectures, all of them based on industry-standard protocols [OAuth 2.0 or OpenID Connect](active-directory-v2-protocols.md). This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. The information is designed to help you understand high-level scenarios before you start working with the code in the [application scenarios](authentication-flows-app-scenarios.md#application-scenarios).
20
+
The Microsoft identity platform supports authentication for various modern app architectures, all of them based on industry-standard protocols [OAuth 2.0 or OpenID Connect](active-directory-v2-protocols.md). This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. The information is designed to help you understand high-level scenarios before you start working with the code in the [application scenarios](authentication-flows-app-scenarios.md#application-scenarios).
Many modern apps have a single-page app front end written primarily in JavaScript, often with a framework like Angular, React, or Vue. The Microsoft identity platform supports these apps by using the [OpenID Connect](v2-protocols-oidc.md) protocol for authentication and either [OAuth 2.0 implicit grant flow](v2-oauth2-implicit-grant-flow.md) or the more recent [OAuth 2.0 authorization code + PKCE flow](v2-oauth2-auth-code-flow.md) for authorization (see below).
41
+
Many modern apps have a single-page app front end written primarily in JavaScript, often with a framework like Angular, React, or Vue. The Microsoft identity platform supports these apps by using the [OpenID Connect](v2-protocols-oidc.md) protocol for authentication and one of two types of authorization grants defined by OAuth 2.0. The supported grant types are either the [OAuth 2.0 implicit grant flow](v2-oauth2-implicit-grant-flow.md) or the more recent [OAuth 2.0 authorization code + PKCE flow](v2-oauth2-auth-code-flow.md) (see below).
42
42
43
43
The flow diagram below demonstrates the OAuth 2.0 authorization code grant (with details around PKCE omitted), where the app receives a code from the Microsoft identity platform `authorize` endpoint, and redeems it for an access token and a refresh token using cross-site web requests. The access token expires every 24 hours, and the app must request another code using the refresh token. In addition to the access token, an `id_token` that represents the signed-in user to the client application is typically also requested through the same flow and/or a separate OpenID Connect request (not shown here).
44
44
@@ -48,9 +48,7 @@ To see this scenario in action, check out the [Tutorial: Sign in users and call
48
48
49
49
### Authorization code flow vs. implicit flow
50
50
51
-
For most of the history of OAuth 2.0, the [implicit flow](v2-oauth2-implicit-grant-flow.md) was the recommended way to build single-page apps. With the removal of [third-party cookies](reference-third-party-cookies-spas.md) and [greater attention](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14) paid to security concerns around the implicit flow, we've moved to the authorization code flow for single-page apps.
52
-
53
-
To ensure compatibility of your app in Safari and other privacy-conscious browsers, we no longer recommend use of the implicit flow and instead recommend the authorization code flow.
51
+
For most of the history of OAuth 2.0, the [implicit flow](v2-oauth2-implicit-grant-flow.md) was the recommended way to build single-page apps. With the removal of [third-party cookies](reference-third-party-cookies-spas.md) and [greater attention](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14) paid to security concerns around the implicit flow, the authorization code flow for single-page apps should now be implemented to ensure compatibility of your app in Safari and other privacy-conscious browsers. The continued use of the implicit flow is not recommended.
Further details of different types of tokens used in the Microsoft identity platform are available in the [access token](access-tokens.md) reference and [id_token reference](id-tokens.md)
70
+
Further details of different types of tokens used in the Microsoft identity platform are available in the [access token](access-tokens.md) reference and [id_token](id-tokens.md) reference.
73
71
74
72
In web server apps, the sign-in authentication flow takes these high-level steps:
75
73
76
74
77
75
78
76
You can ensure the user's identity by validating the ID token with a public signing key that is received from the Microsoft identity platform. A session cookie is set, which can be used to identify the user on subsequent page requests.
79
77
80
-
To see this scenario in action, try the code samples in the [Web app that signs in users scenario](scenario-web-app-sign-user-overview.md).
78
+
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).
81
79
82
-
In addition to simple sign-in, a web server app might need to access another web service, such as a REST 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, read about [getting started with web apps and Web APIs](https://github.com/AzureADQuickStarts/AppModelv2-WebApp-WebAPI-OpenIDConnect-DotNet).
80
+
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).
Copy file name to clipboardExpand all lines: articles/active-directory/fundamentals/multi-tenant-user-management-introduction.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
@@ -98,7 +98,7 @@ There are several mechanisms available for creating and managing the lifecycle o
98
98
99
99
| Mechanism | Description | Best when |
100
100
| - | - | - |
101
-
|[End-user-initiated](multi-tenant-user-management-scenarios.md#end-user-initiated-scenario)| Resource tenant admins delegate the ability to invite guest users to the tenant, an app, or a resource to users within the resource tenant. Users from the home tenant are invited or sign up individually. | <li>Users need improvised access to resources. <li>No automatic synchronization of user attributes is necessary.<li>Unified GAL is not needed.a|
101
+
|[End-user-initiated](multi-tenant-user-management-scenarios.md#end-user-initiated-scenario)| Resource tenant admins delegate the ability to invite guest users to the tenant, an app, or a resource to users within the resource tenant. Users from the home tenant are invited or sign up individually. | <li>Users need improvised access to resources. <li>No automatic synchronization of user attributes is necessary.<li>Unified GAL is not needed. |
102
102
|[Scripted](multi-tenant-user-management-scenarios.md#scripted-scenario)| Resource tenant administrators deploy a scripted “pull” process to automate discovery and provisioning of guest users to support sharing scenarios. | <li>No more than two tenants.<li>No automatic synchronization of user attributes is necessary.<li>Users need pre-configured (not improvised) access to resources.|
103
103
|[Automated](multi-tenant-user-management-scenarios.md#automated-scenario)|Resource tenant admins use an identity provisioning system to automate the provisioning and deprovisioning processes. | <li>Full identity lifecycle management with provisioning and deprovisioning must be automated.<li>Attribute syncing is required to populate the GAL details and support dynamic entitlement scenarios.<li>Users need pre-configured (not ad hoc) access to resources on “Day One”.|
Copy file name to clipboardExpand all lines: articles/active-directory/governance/what-are-lifecycle-workflows.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ Azure AD Lifecycle Workflows is a new Azure AD Identity Governance service that
23
23
24
24
Workflows contain specific processes, which run automatically against users as they move through their life cycle. Workflows are made up of [Tasks](lifecycle-workflow-tasks.md) and [Execution conditions](understanding-lifecycle-workflows.md#understanding-lifecycle-workflows).
25
25
26
-
Tasks are specific actions that run automatically when a workflow is triggered. An Execution condition defines the 'Scope' of "“who” and the 'Trigger' of “when” a workflow will be performed. For example, send a manager an email 7 days before the value in the NewEmployeeHireDate attribute of new employees, can be described as a workflow. It consists of:
26
+
Tasks are specific actions that run automatically when a workflow is triggered. An Execution condition defines the 'Scope' of "who" and the 'Trigger' of "when" a workflow will be performed. For example, sending a manager an email 7 days before the value in the NewEmployeeHireDate attribute of new employees can be described as a workflow. It consists of:
27
27
- Task: send email
28
28
- When (trigger): Seven days before the NewEmployeeHireDate attribute value
29
29
- Who (scope): new employees
@@ -40,17 +40,17 @@ Finally, Lifecycle Workflows can even [integrate with Logic Apps](lifecycle-work
40
40
Anyone who wants to modernize their identity lifecycle management process for employees, needs to ensure:
41
41
42
42
-**New employee on-boarding** - That when a user joins the organization, they're ready to go on day one. They have the correct access to the information, membership to groups, and applications they need.
43
-
-**Employee retirement/terminations/off-boarding** - That users who are no longer tied to the company for various reasons (termination, separation, leave of absence or retirement), have their access revoked in a timely manner
43
+
-**Employee retirement/terminations/off-boarding** - That users who are no longer tied to the company for various reasons (termination, separation, leave of absence or retirement), have their access revoked in a timely manner.
44
44
-**Easy to administer in my organization** - That there's a seamless process to accomplish the above tasks, that isn't overly burdensome or time consuming for Administrators.
45
45
-**Robust troubleshooting/auditing/compliance** - That there's the ability to easily troubleshoot issues when they arise and that there's sufficient logging to help with this and compliance related issues.
46
46
47
47
The following are key reasons to use Lifecycle workflows.
48
48
-**Extend** your HR-driven provisioning process with other workflows that simplify and automate tasks.
49
49
-**Centralize** your workflow process so you can easily create and manage workflows all in one location.
50
-
- Easily **troubleshoot** workflow scenarios with the Workflow history and Audit logs
50
+
- Easily **troubleshoot** workflow scenarios with the Workflow history and Audit logs.
51
51
-**Manage** user lifecycle at scale. As your organization grows, the need for other resources to manage user lifecycles are reduced.
52
-
-**Reduce** or remove manual tasks that were done in the past with automated lifecycle workflows
53
-
-**Apply** logic apps to extend workflows for more complex scenarios using your existing Logic apps
52
+
-**Reduce** or remove manual tasks that were done in the past with automated lifecycle workflows.
53
+
-**Apply** logic apps to extend workflows for more complex scenarios using your existing Logic apps.
54
54
55
55
56
56
All of the above can help ensure a holistic experience by allowing you to remove other dependencies and applications to achieve the same result. Thus translating into, increased on-boarding and off-boarding efficiency.
@@ -73,4 +73,4 @@ You can use Lifecycle workflows to address any of the following conditions.
73
73
74
74
## Next steps
75
75
-[Create a custom workflow using the Azure portal](tutorial-onboard-custom-workflow-portal.md)
76
-
-[Create a Lifecycle workflow](create-lifecycle-workflow.md)
76
+
-[Create a Lifecycle workflow](create-lifecycle-workflow.md)
Copy file name to clipboardExpand all lines: articles/active-directory/manage-apps/review-admin-consent-requests.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
@@ -51,7 +51,7 @@ To review the admin consent requests and take action:
51
51
52
52
## Review admin consent requests using Microsoft Graph
53
53
54
-
To review the admin consent requests programmatically, use the [appConsentRequest resource type](/graph/api/resources/userconsentrequest) and [userConsentRequest resource type](/graph/api/resources/userconsentrequest) and their associated methods in Microsoft Graph. You cannot approve or deny consent requests using Microsoft Graph.
54
+
To review the admin consent requests programmatically, use the [appConsentRequest resource type](/graph/api/resources/appconsentrequest) and [userConsentRequest resource type](/graph/api/resources/userconsentrequest) and their associated methods in Microsoft Graph. You cannot approve or deny consent requests using Microsoft Graph.
55
55
56
56
## Next steps
57
57
-[Review permissions granted to apps](manage-application-permissions.md)
Copy file name to clipboardExpand all lines: articles/app-service/overview.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
@@ -72,14 +72,14 @@ First, validate that the new platform update which contains Debian 11 has reache
72
72
Next, create a deployment slot to test that your application works properly with Debian 11 before applying the change to production.
73
73
74
74
1.[Create a deployment slot](deploy-staging-slots.md#add-a-slot) if you do not already have one, and clone your settings from the production slot. A deployment slot will allow you to safely test changes to your application (such as upgrading to Debian 11) and swap those changes into production after review.
75
-
1. To upgrade to Debian 11 (Bullseye), create an app setting on your slot named `ORYX_DEFAULT_OS` with a value of `bullseye`.
75
+
1. To upgrade to Debian 11 (Bullseye), create an app setting on your slot named `WEBSITE_LINUX_OS_VERSION` with a value of `DEBIAN|BULLSEYE`.
76
76
77
77
```bash
78
-
az webapp config appsettings set -g MyResourceGroup -n MyUniqueApp --settings ORYX_DEFAULT_OS=bullseye
78
+
az webapp config appsettings set -g MyResourceGroup -n MyUniqueApp --settings WEBSITE_LINUX_OS_VERSION="DEBIAN|BULLSEYE"
79
79
```
80
80
1. Deploy your application to the deployment slot using the tool of your choice (VS Code, Azure CLI, GitHub Actions, etc.)
81
81
1. Confirm your application is functioning as expected in the deployment slot.
82
-
1. [Swap your production and staging slots](deploy-staging-slots.md#swap-two-slots). This will apply the `ORYX_DEFAULT_OS=bullseye` app setting to production.
82
+
1. [Swap your production and staging slots](deploy-staging-slots.md#swap-two-slots). This will apply the `WEBSITE_LINUX_OS_VERSION=DEBIAN|BULLSEYE` app setting to production.
83
83
1. Delete the deployment slot if you are no longer using it.
0 commit comments