Merge pull request #111857 from MicrosoftDocs/master

4/17 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -51144,6 +51144,11 @@
       "source_path": "articles/healthcare-apis/configure-local-rbac.md",
       "redirect_url": "/azure/healthcare-apis/azure-api-for-fhir-additional-settings",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "articles/media-services/previous/media-services-configure-tricaster-live-encoder.md",
+      "redirect_url": "/azure/media-services",
+      "redirect_document_id": false
     }
   ]
 }

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

@@ -45,7 +45,7 @@ For more information on the differences in how password policies are applied dep
 
 To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.
 
-For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.
+For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed.
 
 For users synchronized from an on-premises AD DS environment using Azure AD Connect, [enable synchronization of password hashes][hybrid-phs].
 

articles/active-directory-domain-services/network-considerations.md

@@ -105,11 +105,12 @@ The following network security group rules are required for Azure AD DS to provi
 | 443         | TCP      | AzureActiveDirectoryDomainServices | Any         | Allow  | Yes      | Synchronization with your Azure AD tenant. |
 | 3389        | TCP      | CorpNetSaw                         | Any         | Allow  | Yes      | Management of your domain. |
 | 5986        | TCP      | AzureActiveDirectoryDomainServices | Any         | Allow  | Yes      | Management of your domain. |
-| 636         | TCP      | Any                                | Any         | Allow  | No       | Only enabled when you configure secure LDAP (LDAPS). |
 
 > [!WARNING]
 > Don't manually edit these network resources and configurations. When you associate a misconfigured network security group or a user defined route table with the subnet in which Azure AD DS is deployed, you may disrupt Microsoft's ability to service and manage the domain. Synchronization between your Azure AD tenant and your Azure AD DS managed domain is also disrupted.
 >
+> If you use secure LDAP, you can add the required TCP port 636 rule to allow external traffic if needed. Adding this rule doesn't place your network security group rules in an unsupported state. For more information, see [Lock down secure LDAP access over the internet](tutorial-configure-ldaps.md#lock-down-secure-ldap-access-over-the-internet)
+>
 > Default rules for *AllowVnetInBound*, *AllowAzureLoadBalancerInBound*, *DenyAllInBound*, *AllowVnetOutBound*, *AllowInternetOutBound*, and *DenyAllOutBound* also exist for the network security group. Don't edit or delete these default rules.
 >
 > The Azure SLA doesn't apply to deployments where an improperly configured network security group and/or user defined route tables have been applied that blocks Azure AD DS from updating and managing your domain.

articles/active-directory-domain-services/synchronization.md

@@ -28,6 +28,8 @@ The following diagram illustrates how synchronization works between Azure AD DS,
 
 User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. This synchronization process is automatic. You don't need to configure, monitor, or manage this synchronization process. The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Azure AD directory. After the initial synchronization is complete, changes that are made in Azure AD, such as password or attribute changes, are then automatically synchronized to Azure AD DS.
 
+When a user is created in Azure AD, they're not synchronized to Azure AD DS until they change their password in Azure AD. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The password hashes are needed to successfully authenticate a user in Azure AD DS.
+
 The synchronization process is one way / unidirectional by design. There's no reverse synchronization of changes from Azure AD DS back to Azure AD. An Azure AD DS managed domain is largely read-only except for custom OUs that you can create. You can't make changes to user attributes, user passwords, or group memberships within an Azure AD DS managed domain.
 
 ## Attribute synchronization and mapping to Azure AD DS
@@ -130,7 +132,7 @@ The encryption keys are unique to each Azure AD tenant. These hashes are encrypt
 
 Legacy password hashes are then synchronized from Azure AD into the domain controllers for an Azure AD DS managed domain. The disks for these managed domain controllers in Azure AD DS are encrypted at rest. These password hashes are stored and secured on these domain controllers similar to how passwords are stored and secured in an on-premises AD DS environment.
 
-For cloud-only Azure AD environments, [users must reset/change their password](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) in order for the required password hashes to be generated and stored in Azure AD. For any cloud user account created in Azure AD after enabling Azure AD Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats. Those new accounts don't need to reset or change their password generate the legacy password hashes.
+For cloud-only Azure AD environments, [users must reset/change their password](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) in order for the required password hashes to be generated and stored in Azure AD. For any cloud user account created in Azure AD after enabling Azure AD Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats. All cloud user accounts must change their password before they're synchronized to Azure AD DS.
 
 For hybrid user accounts synced from on-premises AD DS environment using Azure AD Connect, you must [configure Azure AD Connect to synchronize password hashes in the NTLM and Kerberos compatible formats](tutorial-configure-password-hash-sync.md).
 

articles/active-directory-domain-services/tutorial-create-instance-advanced.md

@@ -205,7 +205,7 @@ The steps to generate and store these password hashes are different for cloud-on
 > [!TIP]
 > If your Azure AD tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.
 
-For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. You can either expire the passwords for all users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct them to manually change their passwords. For this tutorial, let's manually change a user password.
+For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.
 
 Before a user can reset their password, the Azure AD tenant must be [configured for self-service password reset][configure-sspr].
 

articles/active-directory-domain-services/tutorial-create-instance.md

@@ -155,7 +155,7 @@ The steps to generate and store these password hashes are different for cloud-on
 > [!TIP]
 > If your Azure AD tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.
 
-For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. You can either expire the passwords for all users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct them to manually change their passwords. For this tutorial, let's manually change a user password.
+For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.
 
 Before a user can reset their password, the Azure AD tenant must be [configured for self-service password reset][configure-sspr].
 

articles/active-directory/app-provisioning/customize-application-attributes.md

@@ -139,7 +139,10 @@ The SCIM RFC defines a core user and group schema, while also allowing for exten
    4. Select **Edit attribute list for AppName**.
    5. At the bottom of the attribute list, enter information about the custom attribute in the fields provided. Then select **Add Attribute**.
 
-For SCIM applications, the attribute name must follow the pattern shown in the example below. The "CustomExtensionName" and "CustomAttribute" can be customized per your application's requirements, for example:  urn:ietf:params:scim:schemas:extension:2.0:CustomExtensionName:CustomAttribute  or  urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User.CustomAttributeName:value
+For SCIM applications, the attribute name must follow the pattern shown in the example below. The "CustomExtensionName" and "CustomAttribute" can be customized per your application's requirements, for example:  
+ * urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:CustomAttribute 
+ * urn:ietf:params:scim:schemas:extension:2.0:CustomExtensionName:CustomAttribute  
+ * urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User.CustomAttributeName:value
 
 These instructions are only applicable to SCIM-enabled applications. Applications such as ServiceNow and Salesforce are not integrated with Azure AD using SCIM, and therefore they don't require this specific namespace when adding a custom attribute.
 

articles/active-directory/authentication/active-directory-certificate-based-authentication-ios.md

@@ -1,32 +1,29 @@
 ---
 title: Certificate-based authentication on iOS - Azure Active Directory
-description: Learn about the supported scenarios and the requirements for configuring certificate-based authentication in solutions with iOS devices
+description: Learn about the supported scenarios and the requirements for configuring certificate-based authentication for Azure Active Directory in solutions with iOS devices
 
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 01/15/2018
+ms.date: 04/17/2020
 
 ms.author: iainfou
 author: iainfoulds
 manager: daveba
-ms.reviewer: annaba
 
 ms.collection: M365-identity-device-management
 ---
 # Azure Active Directory certificate-based authentication on iOS
 
-iOS devices can use certificate-based authentication (CBA) to authenticate to Azure Active Directory using a client certificate on their device when connecting to:
+To improve security, iOS devices can use certificate-based authentication (CBA) to authenticate to Azure Active Directory (Azure AD) using a client certificate on their device when connecting to the following applications or services:
 
 * Office mobile applications such as Microsoft Outlook and Microsoft Word
 * Exchange ActiveSync (EAS) clients
 
-Configuring this feature eliminates the need to enter a username and password combination into certain mail and Microsoft Office applications on your mobile device.
+Using certificates eliminates the need to enter a username and password combination into certain mail and Microsoft Office applications on your mobile device.
 
-This topic provides you with the requirements and the supported scenarios for configuring CBA on an iOS device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China, and Germany plans.
-
-This feature is available in preview in Office 365 US Government Defense and Federal plans.
+This article details the requirements and the supported scenarios for configuring CBA on an iOS device. CBA for iOS is available across Azure public clouds, Microsoft Government Cloud, Microsoft Cloud Germany, and Microsoft Azure China 21Vianet.
 
 ## Microsoft mobile applications support
 
@@ -45,40 +42,48 @@ This feature is available in preview in Office 365 US Government Defense and Fed
 
 ## Requirements
 
-The device OS version must be iOS 9 and above
+To use CBA with iOS, the following requirements and considerations apply:
+
+* The device OS version must be iOS 9 or above.
+* Microsoft Authenticator is required for Office applications on iOS.
+* An identity preference must be created in the macOS Keychain that include the authentication URL of the ADFS server. For more information, see [Create an identity preference in Keychain Access on Mac](https://support.apple.com/guide/keychain-access/create-an-identity-preference-kyca6343b6c9/mac).
 
-A federation server must be configured.
+The following Active Directory Federation Services (ADFS) requirements and considerations apply:
 
-Microsoft Authenticator is required for Office applications on iOS.
+* The ADFS server must be enabled for certificate authentication and use federated authentication.
+* The certificate needs to have to use Enhanced Key Usage (EKU) and contain the UPN of the user in the *Subject Alternative Name (NT Principal Name)*.
 
-For Azure Active Directory to revoke a client certificate, the ADFS token must have the following claims:
+## Configure ADFS
 
-* `http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber>`
-  (The serial number of the client certificate)
-* `http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer>`
-  (The string for the issuer of the client certificate)
+For Azure AD to revoke a client certificate, the ADFS token must have the following claims. Azure AD adds these claims to the refresh token if they're available in the ADFS token (or any other SAML token). When the refresh token needs to be validated, this information is used to check the revocation:
 
-Azure Active Directory adds these claims to the refresh token if they are available in the ADFS token (or any other SAML token). When the refresh token needs to be validated, this information is used to check the revocation.
+* `http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber>` - add the serial number of your client certificate
+* `http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer>` - add the string for the issuer of your client certificate
 
-As a best practice, you should update your organization's ADFS error pages with the following information:
+As a best practice, you also should update your organization's ADFS error pages with the following information:
 
-* The requirement for installing the Microsoft Authenticator on iOS
+* The requirement for installing the Microsoft Authenticator on iOS.
 * Instructions on how to get a user certificate.
 
-For more information, see [Customizing the AD FS Sign-in Pages](https://technet.microsoft.com/library/dn280950.aspx).
+For more information, see [Customizing the AD FS sign in page](https://technet.microsoft.com/library/dn280950.aspx).
+
+## Use modern authentication with Office apps
+
+Some Office apps with modern authentication enabled send `prompt=login` to Azure AD in their request. By default, Azure AD translates `prompt=login` in the request to ADFS as `wauth=usernamepassworduri` (asks ADFS to do U/P Auth) and `wfresh=0` (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, modify the default Azure AD behavior.
 
-Some Office apps (with modern authentication enabled) send '*prompt=login*' to Azure AD in their request. By default, Azure AD translates '*prompt=login*' in the request to ADFS as '*wauth=usernamepassworduri*' (asks ADFS to do U/P Auth) and '*wfresh=0*' (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.
-You can use the [MSOLDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0) cmdlet to perform this task:
+To update the default behavior, set the '*PromptLoginBehavior*' in your federated domain settings to *Disabled*. You can use the [MSOLDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0) cmdlet to perform this task, as shown in the following example:
 
-`Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled`
+```powershell
+Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
+```
 
-## Exchange ActiveSync clients support
+## Support for Exchange ActiveSync clients
 
-On iOS 9 or later, the native iOS mail client is supported. For all other Exchange ActiveSync applications, to determine if this feature is supported, contact your application developer.
+On iOS 9 or later, the native iOS mail client is supported. To determine if this feature is supported for all other Exchange ActiveSync applications, contact your application developer.
 
 ## Next steps
 
-If you want to configure certificate-based authentication in your environment, see [Get started with certificate-based authentication on Android](../authentication/active-directory-certificate-based-authentication-get-started.md) for instructions.
+To configure certificate-based authentication in your environment, see [Get started with certificate-based authentication](active-directory-certificate-based-authentication-get-started.md) for instructions.
 
 <!--Image references-->
 [1]: ./media/active-directory-certificate-based-authentication-ios/ic195031.png