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
|{tenant}| Required | Name of your Azure AD B2C tenant|
112
112
|{policy}| Required| The user flow that was used to acquire the authorization code. You cannot use a different user flow in this request. |
113
113
| client_id |Required |The application ID assigned to your app in the [Azure portal](https://portal.azure.com).|
114
+
| client_secret | Yes, in Web Apps | The application secret that was generated in the [Azure portal](https://portal.azure.com/). Client secrets are used in this flow for Web App scenarios, where the client can securely store a client secret. For Native App (public client) scenarios, client secrets cannot be securely stored, and therefore are not used in this call. If you use a client secret, please change it on a periodic basis. |
114
115
| grant_type |Required |The type of grant. For the authorization code flow, the grant type must be `authorization_code`. |
115
116
| scope |Recommended |A space-separated list of scopes. A single scope value indicates to Azure AD both of the permissions that are being requested. Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID. The `offline_access` scope indicates that your app needs a refresh token for long-lived access to resources. You also can use the `openid` scope to request an ID token from Azure AD B2C. |
116
117
| code |Required |The authorization code that you acquired in the first leg of the flow. |
|{tenant}| Required | Name of your Azure AD B2C tenant|
177
178
|{policy} |Required |The user flow that was used to acquire the original refresh token. You cannot use a different user flow in this request. |
178
179
| client_id |Required |The application ID assigned to your app in the [Azure portal](https://portal.azure.com). |
179
-
| client_secret |Required |The client_secret associated to your client_id in the [Azure portal](https://portal.azure.com). |
180
+
| client_secret | Yes, in Web Apps |The application secret that was generated in the [Azure portal](https://portal.azure.com/). Client secrets are used in this flow for Web App scenarios, where the client can securely store a client secret. For Native App (public client) scenarios, client secrets cannot be securely stored, and therefore are not used in this call. If you use a client secret, please change it on a periodic basis. |
180
181
| grant_type |Required |The type of grant. For this leg of the authorization code flow, the grant type must be `refresh_token`. |
181
182
| scope |Recommended |A space-separated list of scopes. A single scope value indicates to Azure AD both of the permissions that are being requested. Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID. The `offline_access` scope indicates that your app will need a refresh token for long-lived access to resources. You also can use the `openid` scope to request an ID token from Azure AD B2C. |
182
183
| redirect_uri |Optional |The redirect URI of the application where you received the authorization code. |
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/active-directory-b2c-ui-customization-custom.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -202,4 +202,4 @@ In the Modify your sign-up or sign-in custom policy section, you configured the
202
202
203
203
## Next steps
204
204
205
-
For more information about UI elements that can be customized, see [reference guide for UI customization for built-in policies](active-directory-b2c-reference-ui-customization.md).
205
+
For more information about UI elements that can be customized, see [reference guide for UI customization for user flows](active-directory-b2c-reference-ui-customization.md).
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/validation-technical-profile.md
+3
Original file line number
Diff line number
Diff line change
@@ -35,6 +35,9 @@ A validation technical profile can be conditionally executed based on preconditi
35
35
36
36
A self-asserted technical profile may define a validation technical profile to be used for validating some or all of its output claims. All of the input claims of the referenced technical profile must appear in the output claims of the referencing validation technical profile.
37
37
38
+
> [!NOTE]
39
+
> Only self-asserted technical profiles can use validation technical profiles. If you need to validate the output claims from non-self-asserted technical profiles, consider using an additional orchestration step in your user journey to accommodate the technical profile in charge of the validation.
40
+
38
41
## ValidationTechnicalProfiles
39
42
40
43
The **ValidationTechnicalProfiles** element contains the following elements:
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/administration-concepts.md
+15
Original file line number
Diff line number
Diff line change
@@ -56,6 +56,18 @@ For users synchronized from an on-premises AD DS environment using Azure AD Conn
56
56
57
57
Once appropriately configured, the usable password hashes are stored in the Azure AD DS managed domain. If you delete the Azure AD DS managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Azure AD can't be reused if you later create an Azure AD DS managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Azure AD needs to generate and store the password hashes in the new Azure AD DS managed domain. For more information, see [Password hash sync process for Azure AD DS and Azure AD Connect][azure-ad-password-sync].
58
58
59
+
## Forests and trusts
60
+
61
+
A *forest* is a logical construct used by Active Directory Domain Services (AD DS) to group one or more *domains*. The domains then store objects for user or groups, and provide authentication services.
62
+
63
+
In Azure AD DS, the forest only contains one domain. On-premises AD DS forests often contain many domains. In large organizations, especially after mergers and acquisitions, you may end up with multiple on-premises forests that each then contain multiple domains.
64
+
65
+
By default, an Azure AD DS managed domain is created as a *user* forest. This type of forest synchronizes all objects from Azure AD, including any user accounts created in an on-premises AD DS environment. User accounts can directly authenticate against the Azure AD DS managed domain, such as to sign in to a domain-joined VM. A user forest works when the password hashes can be synchronized and users aren't using exclusive sign-in methods like smart card authentication.
66
+
67
+
In an Azure AD DS *resource* forest, users authenticate over a one-way forest *trust* from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Azure AD DS. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed. Azure AD DS resource forests are currently in preview.
68
+
69
+
For more information about forest types in Azure AD DS, see [What are resource forests?][concepts-forest] and [How do forest trusts work in Azure AD DS?][concepts-trust]
70
+
59
71
## Next steps
60
72
61
73
To get started, [create an Azure AD DS managed domain][create-instance].
@@ -66,3 +78,6 @@ To get started, [create an Azure AD DS managed domain][create-instance].
0 commit comments