Merge branch 'master' into alexbuckgit/docutune-autopr-20211118-155057-9378336

Author: alexbuckgit

.openpublishing.redirection.healthcare-apis.json

@@ -72,11 +72,6 @@
         "redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/azure-api-for-fhir-additional-settings",
         "redirect_document_id": false
     },
-    {
-        "source_path_from_root": "/articles/healthcare-apis/configure-azure-rbac.md",
-        "redirect_url": "/azure/healthcare-apis/fhir/configure-azure-rbac",
-        "redirect_document_id": true
-    },
     {
         "source_path_from_root": "/articles/healthcare-apis/configure-cross-origin-resource-sharing.md",
         "redirect_url": "/azure/healthcare-apis/fhir/configure-cross-origin-resource-sharing",
@@ -222,12 +217,7 @@
         "redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/access-fhir-postman-tutorial",
         "redirect_document_id": true
     },
-    {
-        "source_path_from_root": "/articles/healthcare-apis/fhir/configure-azure-rbac.md",
-        "redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/configure-azure-rbac",
-        "redirect_document_id": true
-    },
-    {
+   {
         "source_path_from_root": "/articles/healthcare-apis/fhir/configure-database.md",
         "redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/configure-database",
         "redirect_document_id": true
@@ -457,5 +447,50 @@
         "redirect_url": "/azure/healthcare-apis/security-controls-policy",
         "redirect_document_id": true
     },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/fhir/azure-active-directory-identity-configuration.md",
+        "redirect_url": "/azure/healthcare-apis/authentication-authorization",
+        "redirect_document_id": true
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/fhir/fhir-service-access-token-validation.md",
+        "redirect_url": "/azure/healthcare-apis/get-access-token",
+        "redirect_document_id": true
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/fhir/get-healthcare-apis-access-token-cli.md",
+        "redirect_url": "/azure/healthcare-apis/get-access-token",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/dicom/dicom-get-access-token-azure-cli.md",
+        "redirect_url": "/azure/healthcare-apis/get-access-token",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/dicom/dicom-register-service-client-application.md",
+        "redirect_url": "/azure/healthcare-apis/register-application",
+        "redirect_document_id": true
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/dicom/dicom-register-public-application.md",
+        "redirect_url": "/azure/healthcare-apis/register-application",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/dicom/dicom-register-confidential-client-application.md",
+        "redirect_url": "/azure/healthcare-apis/register-application",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/dicom/dicom-configure-azure-rbac.md",
+        "redirect_url": "/azure/healthcare-apis/configure-azure-rbac",
+        "redirect_document_id": true
+    },
+    {
+        "source_path_from_root": "/articles/healthcare-apis/fhir/configure-azure-rbac-for-fhir.md",
+        "redirect_url": "/azure/healthcare-apis/configure-azure-rbac",
+        "redirect_document_id": false
+    }
   ]
 }

.openpublishing.redirection.json

@@ -44771,6 +44771,11 @@
       "redirect_url": "/azure/azure-monitor/essentials/tutorial-metrics",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/azure-monitor/vm/monitor-vm-azure.md",
+      "redirect_url": "/azure/virtual-machines/monitor-vm",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/load-balancer/tutorial-load-balancer-standard-manage-portal.md",
       "redirect_url": "/azure/load-balancer/quickstart-load-balancer-standard-public-portal",

.vscode/settings.json

@@ -0,0 +1,8 @@
+{
+    "markdownlint.config": {
+        "MD028": false,
+        "MD025": {
+            "front_matter_title": ""
+        }
+    }
+}

articles/active-directory-b2c/error-codes.md

@@ -1,5 +1,6 @@
 ---
 title: Extensions app in Azure Active Directory B2C  
+titleSuffix: Azure AD B2C
 description: Restoring the b2c-extensions-app.
 services: active-directory-b2c
 author: kengaderdus
@@ -13,7 +14,7 @@ ms.author: kengaderdus
 ms.subservice: B2C
 ---
 
-# Azure AD B2C: Extensions app 
+# Extensions app in Azure AD B2C
 
 When an Azure AD B2C directory is created, an app called **b2c-extensions-app** is automatically created inside the new directory. This app is visible in *App registrations*. It is used by the Azure AD B2C service to store information about users and custom attributes. If the app is deleted, Azure AD B2C will not function correctly and your production environment will be affected.
 

articles/active-directory-b2c/extensions-app.md

@@ -35,7 +35,7 @@ zone_pivot_groups: b2c-policy-type
 
 ## Create an ID.me application
 
-To enable sign-in for users with an ID.me account in Azure Active Directory B2C (Azure AD B2C), you need to create an application in [ID.me Developer Resources for API & SDK](https://developers.id.me/). For more information, see [OAuth Integration Guide](https://developers.id.me/documentation/oauth/overview/kyc). If you don't already have an ID.me developer account, you can sign up at [https://developers.id.me/registration/new](https://developers.id.me/registration/new).
+To enable sign-in for users with an ID.me account in Azure Active Directory B2C (Azure AD B2C), you need to create an application in [ID.me Developer Resources for API & SDK](https://developers.id.me/). For more information, see [OAuth Integration Guide](https://developers.id.me/documentation/). If you don't already have an ID.me developer account, you can sign up at [https://developers.id.me/registration/new](https://developers.id.me/registration/new).
 
 1. Sign in to the [ID.me Developer Resources for API & SDK](https://developers.id.me/) with your ID.me account credentials.
 1. Select **View My Applications**, and select **Continue**.
@@ -169,4 +169,4 @@ Next, you need a claims transformation to create the displayName claim. Add the
 
 If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.
 
-::: zone-end
+::: zone-end

articles/active-directory-b2c/identity-provider-id-me.md

@@ -427,7 +427,7 @@ The following SAML application scenarios are supported via your own metadata end
 * Specify multiple logout URLs or POST binding for the logout URL in the application or service principal object.
 * Specify a signing key to verify relying party requests in the application or service principal object.
 * Specify a token encryption key in the application or service principal object.
-* Specify IdP-initiated sign-on, where the identity provider is Azure AD B2C.
+* [Specify IdP-initiated sign-on, where the identity provider is Azure AD B2C](saml-service-provider-options.md#configure-idp-initiated-flow).
 
 ## Next steps
 

articles/active-directory-b2c/saml-service-provider.md

@@ -14,10 +14,12 @@ ms.author: kengaderdus
 ms.subservice: B2C
 ---
 
-# Mitigate credential attacks in Azure AD B2C
+# Mitigate credential attacks in Azure AD B2C with smart lockout
 
 Credential attacks lead to unauthorized access to resources. Passwords that are set by users are required to be reasonably complex. Azure AD B2C has mitigation techniques in place for credential attacks. Mitigation includes detection of brute-force credential attacks and dictionary credential attacks. By using various signals, Azure Active Directory B2C (Azure AD B2C) analyzes the integrity of requests. Azure AD B2C is designed to intelligently differentiate intended users from hackers and botnets.
 
+## How smart lockout works
+
 Azure AD B2C uses a sophisticated strategy to lock accounts. The accounts are locked based on the IP of the request and the passwords entered. The duration of the lockout also increases based on the likelihood that it's an attack. After a password is tried 10 times unsuccessfully (the default attempt threshold), a one-minute lockout occurs. The next time a login is unsuccessful after the account is unlocked (that is, after the account has been automatically unlocked by the service once the lockout period expires), another one-minute lockout occurs and continues for each unsuccessful login. Entering the same, or similar password repeatedly doesn't count as multiple unsuccessful logins.
 
 > [!NOTE]
@@ -27,16 +29,16 @@ Azure AD B2C uses a sophisticated strategy to lock accounts. The accounts are lo
 
 The first 10 lockout periods are one minute long. The next 10 lockout periods are slightly longer and increase in duration after every 10 lockout periods. The lockout counter resets to zero after a successful login when the account isn’t locked. Lockout periods can last up to five hours. Users must wait for the lockout duration to expire. However, the user can unlock by using self-service [password user flow](add-password-reset-policy.md).
 
-## Manage password protection settings
+## Manage smart lockout settings
 
-To manage password protection settings, including the lockout threshold:
+To manage smart lockout settings, including the lockout threshold:
 
 1. Sign in to the [Azure portal](https://portal.azure.com)
 1. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.
 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.
 1. In the left menu, select **Azure AD B2C**. Or, select **All services** and search for and select **Azure AD B2C**.
 1. Under **Security**, select **Authentication methods (Preview)**, then select **Password protection**.
-1. Under **Custom smart lockout**, enter your desired password protection settings:
+1. Under **Custom smart lockout**, enter your desired smart lockout settings:
 
    - **Lockout threshold**: The number of failed sign-in tries that are allowed before the account is first locked out. If the first sign-in after a lockout also fails, the account locks again.
    - **Lockout duration in seconds**: The minimum duration of each lockout in seconds. If an account locks repeatedly, this duration increases.
@@ -46,7 +48,7 @@ To manage password protection settings, including the lockout threshold:
 
 1. Select **Save**.
 
-## Testing the password protection settings
+## Testing smart lockout
 
 The smart lockout feature uses many factors to determine when an account should be locked, but the primary factor is the password pattern. The smart lockout feature considers slight variations of a password as a set, and they’re counted as a single try. For example:
 

articles/active-directory-b2c/threat-management.md

@@ -27,11 +27,11 @@ A *forest* is a logical construct used by Active Directory Domain Services (AD D
 
 In an Azure AD DS managed domain, 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, a 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 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.
+By default, a 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 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 a managed domain *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 the managed domain. 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.
 
-Resource forests also provide the capability to lift-and-shift your applications one component at a time. Many legacy on-premises applications are multi-tiered, often using a web server or front end and many database-related components. These tiers make it hard to lift-and-shift the entire application to the cloud in one step. With resource forests, you can lift your application to the cloud in phased approach, which makes it easier to move your application to Azure.
+Resource forests also provide the capability to lift-and-shift your applications one component at a time. Many legacy on-premises applications are multi-tiered, often using a web server or front end and many database-related components. These tiers make it hard to lift-and-shift the entire application to the cloud in one step. With resource forests, you can lift your application to the cloud in a phased approach, which makes it easier to move your application to Azure.
 
 ## What are trusts?
 
@@ -49,7 +49,7 @@ Trusts are also be configured to handle additional trust relationships in one of
 * **Nontransitive** - The trust exists only between the two trust partner domains.
 * **Transitive** - Trust automatically extends to any other domains that either of the partners trusts.
 
-In some cases, trust relationships are automatically established when domains are created. Other times, you must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts used and the structure of those trust relationships depend on how the AD DS directory is organized, and whether different versions of Windows coexist on the network.
+In some cases, trust relationships are automatically established when domains are created. Other times, you must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts used and the structure of those trust relationships depend on how the AD DS directory is organized and whether different versions of Windows coexist on the network.
 
 ## Trusts between two forests
 

articles/active-directory-domain-services/concepts-resource-forest.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 07/07/2021
+ms.date: 11/18/2021
 ms.reviewer: arvinh
 ---
 
@@ -116,8 +116,8 @@ The following attributes and objects aren't supported:
    - Reference attributes (for example, manager).
    - Groups.
    - Complex anchors (for example, ObjectTypeName+UserName).
-   - On-premises applications are sometimes not federated with Azure AD and require local passwords. The on-premises provisioning preview *doesn't support provisioning one-time passwords or synchronizing passwords* between Azure AD and third-party applications.
-   - The **export_password** virtual attribute, **SetPassword**, and **ChangePassword** operations aren't supported.
+   - Binary attributes.
+   - On-premises applications are sometimes not federated with Azure AD and require local passwords. The on-premises provisioning preview does not support password synchronization. Provisioning one-time passwords is supported. Please ensure that you are using the [Redact](https://docs.microsoft.com/azure/active-directory/app-provisioning/functions-for-customizing-application-data#redact) function to redact the passwords from the logs. The passwords are not exported on the initial call to the application, but rather a second call with set password.   
 
 #### SSL certificates
    The Azure AD ECMA Connector Host currently requires either an SSL certificate to be trusted by Azure or the provisioning agent to be used. The certificate subject must match the host name the Azure AD ECMA Connector Host is installed on.
@@ -128,5 +128,9 @@ The following attributes and objects aren't supported:
 #### Attribute discovery and mapping
    The attributes that the target application supports are discovered and surfaced in the Azure portal in **Attribute Mappings**. Newly added attributes will continue to be discovered. If an attribute type has changed, for example, string to Boolean, and the attribute is part of the mappings, the type won't change automatically in the Azure portal. Customers will need to go into advanced settings in mappings and manually update the attribute type.
 
+#### Provisioning agent
+- The agent does not currently support auto update for the on-prem application provisioning scenario. We are actively working to close this gap and ensure that auto update is enabled by default and required for all customers. 
+- The same provisioning agent cannot be used for on-prem app provisioning and cloud sync / HR- driven provisioning. 
+
 ## Next steps
 [How provisioning works](how-provisioning-works.md)