Merge pull request #101590 from MicrosoftDocs/master

1/17 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -1756,6 +1756,11 @@
       "redirect_url": "/azure/cosmos-db/conflict-resolution-policies",
       "redirect_document_id": true
     },
+    {
+      "source_path": "articles/cosmos-db/how-to-custom-synchronization.md",
+      "redirect_url": "/azure/cosmos-db/how-to-multi-master",
+      "redirect_document_id": true
+    },
     {
       "source_path": "articles/cosmos-db/create-sql-api-dotnet-preview.md",
       "redirect_url": "/azure/cosmos-db/create-sql-api-dotnet",
@@ -46575,6 +46580,11 @@
       "redirect_url": "/azure/active-directory/managed-identities-azure-resources/overview",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/load-balancer/load-balancer-standard-overview.md",
+      "redirect_url": "/azure/load-balancer/load-balancer-overview",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/load-balancer/load-balancer-arm.md",
       "redirect_url": "/azure/load-balancer/load-balancer-overview",

articles/active-directory-b2c/active-directory-b2c-setup-goog-app.md

@@ -18,11 +18,14 @@ ms.subservice: B2C
 
 ## Create a Google application
 
-To use a Google account as an [identity provider](active-directory-b2c-reference-oauth-code.md) in Azure Active Directory B2C (Azure AD B2C), you need to create an application in your tenant that represents it. If you don't already have a Google account you can sign up at [https://accounts.google.com/SignUp](https://accounts.google.com/SignUp).
+To use a Google account as an [identity provider](active-directory-b2c-reference-oauth-code.md) in Azure Active Directory B2C (Azure AD B2C), you need to create an application in your Google Developers Console. If you don't already have a Google account you can sign up at [https://accounts.google.com/SignUp](https://accounts.google.com/SignUp).
 
 1. Sign in to the [Google Developers Console](https://console.developers.google.com/) with your Google account credentials.
 1. In the upper-left corner of the page, select the project list, and then select **New Project**.
-1. Enter a **Project Name**, click **Create**, and then make sure you are using the new project.
+1. Enter a **Project Name**, select **Create**.
+1. Make sure you are using the new project by selecting the project drop-down in the top-left of the screen, select your project by name, then select **Open**.
+1. Select **OAuth consent screen** in the left menu, select **External**, and then select **Create**.
+Enter a **Name** for your application. Enter *b2clogin.com* in the **Authorized domains** section and select **Save**.
 1. Select **Credentials** in the left menu, and then select **Create credentials** > **Oauth client ID**.
 1. Under **Application type**, select **Web application**.
 1. Enter a **Name** for your application, enter `https://your-tenant-name.b2clogin.com` in **Authorized JavaScript origins**, and `https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp` in **Authorized redirect URIs**. Replace `your-tenant-name` with the name of your tenant. You need to use all lowercase letters when entering your tenant name even if the tenant is defined with uppercase letters in Azure AD B2C.

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

@@ -125,7 +125,7 @@ The technical profile also returns claims, that aren't returned by the identity
 | SendClaimsIn | No | Specifies how the input claims are sent to the RESTful claims provider. Possible values: `Body` (default), `Form`, `Header`, or `QueryString`. The `Body` value is the input claim that is sent in the request body in JSON format. The `Form` value is the input claim that is sent in the request body in an ampersand '&' separated key value format. The `Header` value is the input claim that is sent in the request header. The `QueryString` value is the input claim that is sent in the request query string. The HTTP verbs invoked by each are as follows:<br /><ul><li>`Body`: POST</li><li>`Form`: POST</li><li>`Header`: GET</li><li>`QueryString`: GET</li></ul> |
 | ClaimsFormat | No | Specifies the format for the output claims. Possible values: `Body` (default), `Form`, `Header`, or `QueryString`. The `Body` value is the output claim that is sent in the request body in JSON format. The `Form` value is the output claim that is sent in the request body in an ampersand '&' separated key value format. The `Header` value is the output claim that is sent in the request header. The `QueryString` value is the output claim that is sent in the request query string. |
 | ClaimUsedForRequestPayload| No | Name of a string claim that contains the payload to be sent to the REST API. |
-| DebugMode | No | Runs the technical profile in debug mode. In debug mode, the REST API can return more information. See the returning error message section. |
+| DebugMode | No | Runs the technical profile in debug mode. Possible values: `true`, or `false` (default). In debug mode, the REST API can return more information. See the [Returning error message](#returning-error-message) section. |
 
 ## Cryptographic keys
 
@@ -212,7 +212,7 @@ If the type of authentication is set to `Bearer`, the **CryptographicKeys** elem
 
 ## Returning error message
 
-Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. In an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code) with following attributes:
+Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. If an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code) with following attributes:
 
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |

articles/active-directory/authentication/overview-authentication.md

@@ -1,64 +1,98 @@
 ---
-title: Authenticating and securing users - Azure Active Directory
-description: As an Azure AD Administrator how do I protect user authentication while reducing end-user impact?
+title: Azure Active Directory authentication overview
+description: Learn about the different authentication methods and security features for user sign-ins with Azure Active Directory.
 
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: overview
-ms.date: 11/21/2019
+ms.date: 01/17/2020
 
 ms.author: iainfou
 author: iainfoulds
 manager: daveba
 ms.reviewer: sahenry, michmcla
 
-# Customer intent: As an Azure AD administrator, I want to understand which Azure AD features I can use to secure sign-in and make the user authentication process safe and easy. 
 ms.collection: M365-identity-device-management
+
+# Customer intent: As an Azure AD administrator, I want to understand which Azure AD features I can use to secure sign-in and make the user authentication process safe and easy.
 ---
-# What methods are available for authentication?
+# What is Azure Active Directory authentication?
+
+One of the main features of an identity platform is to verify, or *authenticate*, credentials when a user signs in to a device, application, or service. In Azure Active Directory (Azure AD), authentication involves more than just the verification of a username and password. To improve security and reduce the need for help desk assistance, Azure AD authentication includes the following components:
 
-We hear reports in the news, passwords being stolen, and identities being compromised. Requiring a second factor in addition to a password immediately increases the security of your organization. Microsoft Azure Active Directory (Azure AD) includes features, like Azure Multi-Factor Authentication (Azure MFA) and Azure AD self-service password reset (SSPR), to help administrators protect their organizations and users with additional authentication methods.
+* Self-service password reset
+* Azure Multi-Factor Authentication
+* Hybrid integration to write password changes back to on-premises environment
+* Hybrid integration to enforce password protection policies for an on-premises environment
+* Passwordless authentication
 
-There are many scenarios that include: signing in to an application, resetting their password, enabling Windows Hello, and others, your users may be asked to provide additional verification that they are who they say they are.
+## Improve the end-user experience
 
-Additional verification may come in the form of authentication methods such as:
+Azure AD helps to protect a user's identity and simplify their sign-in experience. Features like self-service password reset let users update or change their passwords using a web browser from any device. This feature is especially useful when the user has forgotten their password or their account is locked. Without waiting for a helpdesk or administrator to provide support, a user can unblock themselves and continue to work.
 
-* A code provided in an email or text message
-* A phone call
-* A notification or code on their phone
-* Answers to security questions
+Azure Multi-Factor Authentication lets users choose an additional form of authentication during sign-in, such as a phone call or mobile app notification. This ability reduces the requirement for a single, fixed form of secondary authentication like a hardware token. If the user doesn't currently have one form of additional authentication, they can choose a different method and continue to work.
 
-![Example login.microsoftonline.com login page in Chrome](media/overview-authentication/overview-login.png)
+![Authentication methods in use at the sign-in screen](media/concept-authentication-methods/overview-login.png)
 
-Azure MFA and Azure AD self-service password reset give administrators control over configuration, policy, monitoring, and reporting using Azure AD and the Azure portal to protect their organizations.
+Passwordless authentication removes the need for the user to create and remember a secure password at all. Capabilities like Windows Hello for Business or FIDO2 security keys let users sign in to a device or application without a password. This ability can reduce the complexity of managing passwords across different environments.
 
 ## Self-service password reset
 
-Self-service password reset provides your users the ability to reset their password, with no administrator intervention, when and where they need to.
+Self-service password reset gives users the ability to change or reset their password, with no administrator or help desk involvement. If a user's account is locked or they forget their password, they can follow prompts to unblock themselves and get back to work. This ability reduces help desk calls and loss of productivity when a user can't sign in to their device or an application.
+
+Self-service password reset works in the following scenarios:
+
+* **Password change -** when a user knows their password but wants to change it to something new.
+* **Password reset -** when a user can't sign in, such as when they forgot password, and want to reset their password.
+* **Account unlock -** when a user can't sign in because their account is locked out and want to unlock their account.
+
+When a user updates or resets their password using self-service password reset, that password can also be written back to an on-premises Active Directory environment. Password writeback makes sure that a user can immediately use their updated credentials with on-premises devices and applications.
+
+## Azure Multi-Factor Authentication
+
+Multi-factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan.
+
+If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, is it really the user signing in with the username and password, or is it an attacker? When you require a second form of authentication, security is increased as this additional factor isn't something that's easy for an attacker to obtain or duplicate.
+
+![Conceptual image of the different forms of multi-factor authentication](./media/concept-mfa-howitworks/methods.png)
+
+Azure Multi-Factor Authentication works by requiring two or more of the following authentication methods:
+
+* Something you know, typically a password.
+* Something you have, such as a trusted device that is not easily duplicated, like a phone or hardware key.
+* Something you are - biometrics like a fingerprint or face scan.
+
+Users can register themselves for both self-service password reset and Azure Multi-Factor Authentication in one step to simplify the on-boarding experience. Administrators can define what forms of secondary authentication can be used. Azure Multi-Factor Authentication can also be required when users perform a self-service password reset to further secure that process.
+
+## Password protection
+
+By default, Azure AD blocks weak passwords such as *Password1*. A global banned password list is automatically updated and enforced that includes known weak passwords. If an Azure AD user tries to set their password to one of these weak passwords, they receive a notification to choose a more secure password.
 
-> [!VIDEO https://www.youtube.com/embed/hc97Yx5PJiM]
+To increase security, you can define custom password protection policies. These policies can use filters to block any variation of a password containing a name such as *Contoso* or a location like *London*, for example.
 
-Self-service password reset includes:
+For hybrid security, you can integrate Azure AD password protection with an on-premises Active Directory environment. A component installed in the on-prem environment receives the global banned password list and custom password protection policies from Azure AD, and domain controllers use them to process password change events. This hybrid approach makes sure that no matter how or where a user changes their credentials, you enforce the use of strong passwords.
 
-* **Password change:** I know my password but want to change it to something new.
-* **Password reset:** I can't sign in and want to reset my password using one or more approved authentication methods.
-* **Account unlock:** I can't sign in because my account is locked out and I want to unlock using one or more approved authentication methods.
+## Passwordless authentication
 
-## Multi-Factor Authentication
+The end-goal for many environments is to remove the use of passwords as part of sign-in events. Features like Azure password protection or Azure Multi-Factor Authentication help improve security, but a username and password remains a weak form of authentication that can be exposed or brute-force attacked.
 
-Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution. Using administrator approved authentication methods, Azure MFA helps safeguard your access to data and applications, while meeting the demand for a simple sign-in process.
+![Security versus convenience with the authentication process that leads to passwordless](./media/concept-authentication-passwordless/passwordless-convenience-security.png)
 
-## License requirements
+When you sign in with a passwordless method, credentials are provided through the use of methods like biometrics with Windows Hello for Business, or a FIDO2 security key. These authentication methods can't be easily duplicated by an attacker.
 
-[!INCLUDE [Active Directory P1 license](../../../includes/active-directory-p1-license.md)]
+Azure AD provides ways to natively authenticate using passwordless methods to simplify the sign-in experience for users and reduce the risk of attacks.
 
 ## Next steps
 
-The next step is to dive in and configure self-service password reset and Azure Multi-Factor Authentication.
+To get started, see the [quickstart for self-service password reset][quickstart-sspr] and [Azure Multi-Factor Authentication tutorial][tutorial-mfa-applications].
 
-To get started with self-service password reset, see the [enable SSPR quickstart article](quickstart-sspr.md).
+To learn more about self-service password reset concepts, see [How Azure AD self-service password reset works][concept-sspr].
 
-Learn more about self-service password reset in the article, [How it works: Azure AD self-service password reset](concept-sspr-howitworks.md)
+To learn more about multi-factor authentication concepts, see [How Azure Multi-Factor Authentication works][concept-mfa].
 
-Learn more about Azure Multi-Factor Authentication in the article, [How it works: Azure Multi-Factor Authentication](concept-mfa-howitworks.md)
+<!-- INTERNAL LINKS -->
+[quickstart-sspr]: quickstart-sspr.md
+[tutorial-mfa-applications]: tutorial-mfa-applications.md
+[concept-sspr]: concept-sspr-howitworks.md
+[concept-mfa]: concept-mfa-howitworks.md

articles/active-directory/develop/msal-js-pass-custom-state-authentication-request.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 05/29/2019
+ms.date: 01/16/2020
 ms.author: twhitney
 ms.reviewer: saeeda
 ms.custom: aaddev
@@ -19,6 +19,7 @@ ms.collection: M365-identity-device-management
 ---
 
 # Pass custom state in authentication requests using MSAL.js
+
 The *state* parameter, as defined by OAuth 2.0, is included in an authentication request and is also returned in the token response to prevent cross-site request forgery attacks. By default, Microsoft Authentication Library for JavaScript (MSAL.js) passes a randomly generated unique *state* parameter value in the authentication requests.
 
 The state parameter can also be used to encode information of the app's state before redirect. You can pass the user's state in the app, such as the page or view they were on, as input to this parameter. The MSAL.js library allows you to pass your custom state as state parameter in the `Request` object:
@@ -37,9 +38,17 @@ export type AuthenticationParameters = {
     account?: Account;
     sid?: string;
     loginHint?: string;
+    forceRefresh?: boolean;
 };
 ```
 
+> [!Note]
+> If you would like to skip a cached token and go to the server, please pass in the boolean `forceRefresh` into the AuthenticationParameters object used to make a login/token request.
+> `forceRefresh` should not be used by default, because of the performance impact on your application.
+> Relying on the cache will give your users a better experience.
+> Skipping the cache should only be used in scenarios where you know the currently cached data does not have up-to-date information.
+> Such as an Admin tool that adds roles to a user that needs to get a new token with updated roles.
+
 For example:
 
 ```javascript

articles/active-directory/manage-apps/application-proxy-qlik.md

@@ -47,7 +47,7 @@ Follow these steps to publish your app. For a more detailed walkthrough of steps
 ### Application #2: 
 Follow the same steps as for Application #1, with the following exceptions: 
 
-**Step #5**: The Internal URL should now be the QlikSense URL with the authentication port used by the application. The default is **4244** for HTTPS, and 4248 for HTTP. Ex: **https&#58;//demo.qlik.com:4244**</br></br> 
+**Step #5**: The Internal URL should now be the QlikSense URL with the authentication port used by the application. The default is **4244** for HTTPS, and **4248** for HTTP for QlikSense releases prior to April 2018. The default for QlikSense releases after April 2018 is **443** for HTTPS and **80** for HTTP.  Ex: **https&#58;//demo.qlik.com:4244**</br></br> 
 **Step #10:** Don’t set up SSO, and leave the **Single sign-on disabled**