Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into patricka-blockchain-ad-update

Author: PatAltimore

.openpublishing.redirection.json

@@ -320,6 +320,9 @@
       href: active-directory-b2c-devquickstarts-graph-dotnet.md
   - name: Audit logs
     href: active-directory-b2c-reference-audit-logs.md
+  - name: Manage users - Azure portal
+    href: manage-users-portal.md
+    displayName: create users, add users, delete users
   - name: Secure API Management API
     href: secure-api-management.md
     displayName: apim, api management, migrate, b2clogin.com

articles/active-directory-b2c/TOC.yml

@@ -273,10 +273,11 @@ Inspect the `B2CGraphClient.SendGraphPatchRequest()` method for details on how t
 
 ### Search users
 
-You can search for users in your B2C tenant in two ways:
+You can search for users in your B2C tenant in the following ways:
 
 * Reference the user's **object ID**.
 * Reference their sign-in identifer, the `signInNames` property.
+* Reference any of the valid OData parameters. For example, 'givenName', 'surname', 'displayName' etc.
 
 Run one of the following commands to search for a user:
 
@@ -290,6 +291,9 @@ For example:
 ```cmd
 B2C Get-User 2bcf1067-90b6-4253-9991-7f16449c2d91
 B2C Get-User $filter=signInNames/any(x:x/value%20eq%20%27consumer@fabrikam.com%27)
+B2C get-user $filter=givenName%20eq%20%27John%27
+B2C get-user $filter=surname%20eq%20%27Doe%27
+B2C get-user $filter=displayName%20eq%20%27John%20Doe%27
 ```
 
 ### Delete users

articles/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet.md

@@ -111,6 +111,7 @@ grant_type=authorization_code&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&sco
 |{tenant}| Required | Name of your Azure AD B2C tenant|
 |{policy}| Required| The user flow that was used to acquire the authorization code. You cannot use a different user flow in this request. |
 | client_id |Required |The application ID assigned to your app in the [Azure portal](https://portal.azure.com).|
+| 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. |
 | grant_type |Required |The type of grant. For the authorization code flow, the grant type must be `authorization_code`. |
 | 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. |
 | 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
 |{tenant}| Required | Name of your Azure AD B2C tenant|
 |{policy} |Required |The user flow that was used to acquire the original refresh token. You cannot use a different user flow in this request. |
 | client_id |Required |The application ID assigned to your app in the [Azure portal](https://portal.azure.com). |
-| client_secret |Required |The client_secret associated to your client_id in the [Azure portal](https://portal.azure.com). |
+| 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. |
 | grant_type |Required |The type of grant. For this leg of the authorization code flow, the grant type must be `refresh_token`. |
 | 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. |
 | redirect_uri |Optional |The redirect URI of the application where you received the authorization code. |

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

@@ -0,0 +1,60 @@
+---
+title: Create & delete Azure AD B2C consumer user accounts in the Azure portal
+description: Learn how to use the Azure portal to create and delete consumer users in your Azure AD B2C directory.
+services: active-directory-b2c
+author: mmacy
+manager: celestedg
+
+ms.service: active-directory
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 11/09/2019
+ms.author: marsma
+ms.subservice: B2C
+---
+
+# Use the Azure portal to create and delete consumer users in Azure AD B2C
+
+There might be scenarios in which you want to manually create consumer accounts in your Azure Active Directory B2C (Azure AD B2C) directory. Although consumer accounts in an Azure AD B2C directory are most commonly created when users sign up to use one of your applications, you can create them programmatically and by using the Azure portal. This article focuses on the Azure portal method of user creation and deletion.
+
+To add or delete users, your account must be assigned the *User administrator* or *Global administrator* role.
+
+[!INCLUDE [active-directory-b2c-public-preview](../../includes/active-directory-b2c-public-preview.md)]
+
+## Types of user accounts
+
+As described in [Overview of user accounts in Azure AD B2C](user-overview.md), there are three types of user accounts that can be created in an Azure AD B2C directory:
+
+* Work
+* Guest
+* Consumer
+
+This article focuses on working with **consumer accounts** in the Azure portal. For information about creating and deleting Work and Guest accounts, see [Add or delete users using Azure Active Directory](../active-directory/fundamentals/add-users-azure-active-directory.md).
+
+## Create a consumer user
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + subscription** filter in the top menu, and then select the directory that contains your Azure AD B2C tenant.
+1. In the left menu, select **Azure AD B2C**. Or, select **All services** and search for and select **Azure AD B2C**.
+1. Under **Manage**, select **Users**.
+1. Select **New user**.
+1. Select **Create Azure AD B2C user**.
+1. Choose a **Sign in method** and enter either an **Email** address or a **Username** for the new user. The sign in method you select here must match the setting you've specified for your Azure AD B2C tenant's *Local account* identity provider (see **Manage** > **Identity providers** in your Azure AD B2C tenant).
+1. Enter a **Name** for the user. This is typically the full name (given and surname) of the user.
+1. (Optional) You can **Block sign in** if you wish to delay the ability for the user to sign in. You can enable sign in later by editing the user's **Profile** in the Azure portal.
+1. Choose **Auto-generate password** or **Let me create password**.
+1. Specify the user's **First name** and **Last name**.
+1. Select **Create**.
+
+Unless you've selected **Block sign in**, the user can now sign in using the sign in method (email or username) that you specified.
+
+## Delete a consumer user
+
+1. In your Azure AD B2C directory, select **Users**, and then select the user you want to delete.
+1. Select **Delete**, and then **Yes** to confirm the deletion.
+
+For details about restoring a user within the first 30 days after deletion, or for permanently deleting a user, see [Restore or remove a recently deleted user using Azure Active Directory](../active-directory/fundamentals/active-directory-users-restore.md).
+
+## Next steps
+
+For automated user management scenarios, for example migrating users from another identity provider to your Azure AD B2C directory, see [Azure AD B2C: User migration](active-directory-b2c-user-migration.md).

articles/active-directory-b2c/manage-users-portal.md

@@ -35,6 +35,9 @@ A validation technical profile can be conditionally executed based on preconditi
 
 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.
 
+> [!NOTE]
+> 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.    
+
 ## ValidationTechnicalProfiles
 
 The **ValidationTechnicalProfiles** element contains the following elements:

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

@@ -23,6 +23,8 @@
       href: tutorial-configure-password-hash-sync.md
     - name: Create an advanced managed domain
       href: tutorial-create-instance-advanced.md
+    - name: Create a forest trust (preview)
+      href: tutorial-create-forest-trust.md
 - name: Samples
   items:
     - name: Create a managed domain using Azure PowerShell
@@ -33,6 +35,12 @@
       href: administration-concepts.md
     - name: Common deployment scenarios
       href: scenarios.md
+    - name: Forests and trusts
+      items:
+        - name: Resource forests
+          href: concepts-resource-forest.md
+        - name: Forest trusts
+          href: concepts-forest-trust.md
     - name: How Azure AD DS synchronization works
       href: synchronization.md
     - name: How password hash synchronization works

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

@@ -56,6 +56,18 @@ For users synchronized from an on-premises AD DS environment using Azure AD Conn
 
 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].
 
+## Forests and trusts
+
+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.
+
+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.
+
+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.
+
+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.
+
+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]
+
 ## Next steps
 
 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].
 [secure-domain]: secure-your-domain.md
 [azure-ad-password-sync]: ../active-directory/hybrid/how-to-connect-password-hash-synchronization.md#password-hash-sync-process-for-azure-ad-domain-services
 [create-instance]: tutorial-create-instance.md
+[tutorial-create-instance-advanced]: tutorial-create-instance-advanced.md
+[concepts-forest]: concepts-resource-forest.md
+[concepts-trust]: concepts-forest-trust.md