Skip to content

Commit c9045eb

Browse files
Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into crs-functions-event-grid-update
2 parents 3c13e5a + 8f3fcfc commit c9045eb

File tree

2,116 files changed

+17328
-14646
lines changed

Some content is hidden

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

2,116 files changed

+17328
-14646
lines changed

.openpublishing.redirection.json

+20
Original file line numberDiff line numberDiff line change
@@ -992,6 +992,11 @@
992992
"redirect_url": "/azure/machine-learning/service/how-to-configure-environment",
993993
"redirect_document_id": false
994994
},
995+
{
996+
"source_path": "articles/firewall/public-preview.md",
997+
"redirect_url": "/azure/firewall/overview",
998+
"redirect_document_id": false
999+
},
9951000
{
9961001
"source_path": "articles/frontdoor/waf-faq.md",
9971002
"redirect_url": "/azure/web-application-firewall/afds/waf-faq",
@@ -12367,6 +12372,21 @@
1236712372
"redirect_url": "/azure/cosmos-db/sql-api-sdk-java",
1236812373
"redirect_document_id": true
1236912374
},
12375+
{
12376+
"source_path": "articles/cosmos-db/logging.md",
12377+
"redirect_url": "/azure/cosmos-db/monitor-cosmos-db",
12378+
"redirect_document_id": false
12379+
},
12380+
{
12381+
"source_path": "articles/cosmos-db/cosmos-db-azure-monitor-metrics.md",
12382+
"redirect_url": "/azure/cosmos-db/monitor-cosmos-db",
12383+
"redirect_document_id": false
12384+
},
12385+
{
12386+
"source_path": "articles/cosmos-db/monitor-accounts.md",
12387+
"redirect_url": "/azure/cosmos-db/monitor-cosmos-db",
12388+
"redirect_document_id": false
12389+
},
1237012390
{
1237112391
"source_path": "articles/iot-suite/iot-suite-v1-connecting-devices-linux.md",
1237212392
"redirect_url": "https://docs.microsoft.com/previous-versions/azure/iot-suite/iot-suite-v1-connecting-devices-linux",

articles/active-directory-b2c/active-directory-b2c-reference-oauth-code.md

+2-1
Original file line numberDiff line numberDiff line change
@@ -111,6 +111,7 @@ grant_type=authorization_code&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&sco
111111
|{tenant}| Required | Name of your Azure AD B2C tenant|
112112
|{policy}| Required| The user flow that was used to acquire the authorization code. You cannot use a different user flow in this request. |
113113
| 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. |
114115
| grant_type |Required |The type of grant. For the authorization code flow, the grant type must be `authorization_code`. |
115116
| 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. |
116117
| code |Required |The authorization code that you acquired in the first leg of the flow. |
@@ -176,7 +177,7 @@ grant_type=refresh_token&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&scope=90
176177
|{tenant}| Required | Name of your Azure AD B2C tenant|
177178
|{policy} |Required |The user flow that was used to acquire the original refresh token. You cannot use a different user flow in this request. |
178179
| 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. |
180181
| grant_type |Required |The type of grant. For this leg of the authorization code flow, the grant type must be `refresh_token`. |
181182
| 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. |
182183
| redirect_uri |Optional |The redirect URI of the application where you received the authorization code. |

articles/active-directory-b2c/active-directory-b2c-ui-customization-custom.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -202,4 +202,4 @@ In the Modify your sign-up or sign-in custom policy section, you configured the
202202
203203
## Next steps
204204
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).

articles/active-directory-b2c/validation-technical-profile.md

+3
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,9 @@ A validation technical profile can be conditionally executed based on preconditi
3535

3636
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.
3737

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+
3841
## ValidationTechnicalProfiles
3942

4043
The **ValidationTechnicalProfiles** element contains the following elements:

articles/active-directory-domain-services/TOC.yml

+8
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,8 @@
2323
href: tutorial-configure-password-hash-sync.md
2424
- name: Create an advanced managed domain
2525
href: tutorial-create-instance-advanced.md
26+
- name: Create a forest trust (preview)
27+
href: tutorial-create-forest-trust.md
2628
- name: Samples
2729
items:
2830
- name: Create a managed domain using Azure PowerShell
@@ -33,6 +35,12 @@
3335
href: administration-concepts.md
3436
- name: Common deployment scenarios
3537
href: scenarios.md
38+
- name: Forests and trusts
39+
items:
40+
- name: Resource forests
41+
href: concepts-resource-forest.md
42+
- name: Forest trusts
43+
href: concepts-forest-trust.md
3644
- name: How Azure AD DS synchronization works
3745
href: synchronization.md
3846
- name: How password hash synchronization works

articles/active-directory-domain-services/administration-concepts.md

+15
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,18 @@ For users synchronized from an on-premises AD DS environment using Azure AD Conn
5656
5757
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].
5858

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+
5971
## Next steps
6072

6173
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].
6678
[secure-domain]: secure-your-domain.md
6779
[azure-ad-password-sync]: ../active-directory/hybrid/how-to-connect-password-hash-synchronization.md#password-hash-sync-process-for-azure-ad-domain-services
6880
[create-instance]: tutorial-create-instance.md
81+
[tutorial-create-instance-advanced]: tutorial-create-instance-advanced.md
82+
[concepts-forest]: concepts-resource-forest.md
83+
[concepts-trust]: concepts-forest-trust.md

0 commit comments

Comments
 (0)