[AzureAD] SSPR writeback concepts freshness

Author: iainfoulds

articles/active-directory/authentication/TOC.yml

@@ -30,12 +30,12 @@
     items:
     - name: How password reset works
       href: concept-sspr-howitworks.md
+    - name: On-premises integration
+      href: concept-sspr-writeback.md
     - name: Policies
       href: concept-sspr-policy.md
     - name: Licenses
       href: concept-sspr-licensing.md
-    - name: On-premises integration
-      href: concept-sspr-writeback.md
   - name: Multi-Factor Authentication
     items:
     - name: How MFA works

articles/active-directory/authentication/concept-sspr-writeback.md

@@ -1,63 +1,39 @@
 ---
-title: On-premises password writeback integration with Azure AD SSPR - Azure Active Directory
-description: Get cloud passwords written back to on-premises AD infrastructure
+title: On-premises password writeback with self-service password reset - Azure Active Directory
+description: Learn how password change or reset events in Azure Active Directory can be written back to an on-premises directory environment
 
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 05/06/2019
+ms.date: 04/14/2020
 
 ms.author: iainfou
 author: iainfoulds
 manager: daveba
-ms.reviewer: sahenry
+ms.reviewer: rhicock
 ms.collection: M365-identity-device-management
 ---
-# What is password writeback?
+# How does self-service password reset writeback work in Azure Active Directory?
 
-Having a cloud-based password reset utility is great but most companies still have an on-premises directory where their users exist. How does Microsoft support keeping traditional on-premises Active Directory (AD) in sync with password changes in the cloud? Password writeback is a feature enabled with [Azure AD Connect](../hybrid/whatis-hybrid-identity.md) that allows password changes in the cloud to be written back to an existing on-premises directory in real time.
+Azure Active Directory (Azure AD) self-service password reset (SSPR) lets users reset their passwords in the cloud, but most companies also have an on-premises Active Directory Domain Services (AD DS) environment where their users exist. Password writeback is a feature enabled with [Azure AD Connect](../hybrid/whatis-hybrid-identity.md) that allows password changes in the cloud to be written back to an existing on-premises directory in real time. In this configuration, as users change or reset their passwords using SSPR in the cloud, the updated passwords also written back to the on-premises AD DS environment
 
-Password writeback is supported in environments that use:
+Password writeback is supported in environments that use the following hybrid identity models:
 
-* [Active Directory Federation Services](../hybrid/how-to-connect-fed-management.md)
 * [Password hash synchronization](../hybrid/how-to-connect-password-hash-synchronization.md)
 * [Pass-through authentication](../hybrid/how-to-connect-pta.md)
+* [Active Directory Federation Services](../hybrid/how-to-connect-fed-management.md)
 
-> [!WARNING]
-> Password writeback will stop working for customers who are using Azure AD Connect versions 1.0.8641.0 and older when the [Azure Access Control service (ACS) is retired on November 7th, 2018](../azuread-dev/active-directory-acs-migration.md). Azure AD Connect versions 1.0.8641.0 and older will no longer allow password writeback at that time because they depend on ACS for that functionality.
->
-> To avoid a disruption in service, upgrade from a previous version of Azure AD Connect to a newer version, see the article [Azure AD Connect: Upgrade from a previous version to the latest](../hybrid/how-to-upgrade-previous-version.md)
->
-
-Password writeback provides:
+Password writeback provides the following features:
 
-* **Enforcement of on-premises Active Directory password policies**: When a user resets their password, it is checked to ensure it meets your on-premises Active Directory policy before committing it to that directory. This review includes checking the history, complexity, age, password filters, and any other password restrictions that you have defined in local Active Directory.
-* **Zero-delay feedback**: Password writeback is a synchronous operation. Your users are notified immediately if their password did not meet the policy or could not be reset or changed for any reason.
-* **Supports password changes from the access panel and Office 365**: When federated or password hash synchronized users come to change their expired or non-expired passwords, those passwords are written back to your local Active Directory environment.
-* **Supports password writeback when an admin resets them from the Azure portal**: Whenever an admin resets a user’s password in the [Azure portal](https://portal.azure.com), if that user is federated or password hash synchronized, the password is written back to on-premises. This functionality is currently not supported in the Office admin portal.
-* **Doesn’t require any inbound firewall rules**: Password writeback uses an Azure Service Bus relay as an underlying communication channel. All communication is outbound over port 443.
+* **Enforcement of on-premises Active Directory Domain Services (AD DS) password policies**: When a user resets their password, it's checked to ensure it meets your on-premises AD DS policy before committing it to that directory. This review includes checking the history, complexity, age, password filters, and any other password restrictions that you define in AD DS.
+* **Zero-delay feedback**: Password writeback is a synchronous operation. Users are notified immediately if their password doesn't meet the policy or can't be reset or changed for any reason.
+* **Supports password changes from the access panel and Office 365**: When federated or password hash synchronized users come to change their expired or non-expired passwords, those passwords are written back to AD DS.
+* **Supports password writeback when an admin resets them from the Azure portal**: When an admin resets a user's password in the [Azure portal](https://portal.azure.com), if that user is federated or password hash synchronized, the password is written back to on-premises. This functionality is currently not supported in the Office admin portal.
+* **Doesn't require any inbound firewall rules**: Password writeback uses an Azure Service Bus relay as an underlying communication channel. All communication is outbound over port 443.
 
 > [!NOTE]
-> Administrator accounts that exist within protected groups in on-premises AD can be used with password writeback. Administrators can change their password in the cloud but cannot use password reset to reset a forgotten password. For more information about protected groups, see [Protected accounts and groups in Active Directory](https://docs.microsoft.com/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory).
-
-## Licensing requirements for password writeback
-
-**Self-Service Password Reset/Change/Unlock with on-premises writeback is a premium feature of Azure AD**. For more information about licensing, see the [Azure Active Directory pricing site](https://azure.microsoft.com/pricing/details/active-directory/).
-
-To use password writeback, you must have one of the following licenses assigned on your tenant:
-
-* Azure AD Premium P1
-* Azure AD Premium P2
-* Enterprise Mobility + Security E3 or A3
-* Enterprise Mobility + Security E5 or A5
-* Microsoft 365 E3 or A3
-* Microsoft 365 E5 or A5
-* Microsoft 365 F1
-* Microsoft 365 Business
-
-> [!WARNING]
-> Standalone Office 365 licensing plans *don't support "Self-Service Password Reset/Change/Unlock with on-premises writeback"* and require that you have one of the preceding plans for this functionality to work.
+> Administrator accounts that exist within protected groups in on-premises AD can be used with password writeback. Administrators can change their password in the cloud but can't use password reset to reset a forgotten password. For more information about protected groups, see [Protected accounts and groups in Active Directory](/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory).
 
 ## How password writeback works
 
@@ -71,38 +47,39 @@ When a federated or password hash synchronized user attempts to reset or change
 1. When the user selects **Submit**, the plaintext password is encrypted with a symmetric key created during the writeback setup process.
 1. The encrypted password is included in a payload that gets sent over an HTTPS channel to your tenant-specific service bus relay (that is set up for you during the writeback setup process). This relay is protected by a randomly generated password that only your on-premises installation knows.
 1. After the message reaches the service bus, the password-reset endpoint automatically wakes up and sees that it has a reset request pending.
-1. The service then looks for the user by using the cloud anchor attribute. For this lookup to succeed:
+1. The service then looks for the user by using the cloud anchor attribute. For this lookup to succeed, the following conditions must be met:
 
    * The user object must exist in the Active Directory connector space.
    * The user object must be linked to the corresponding metaverse (MV) object.
    * The user object must be linked to the corresponding Azure Active Directory connector object.
    * The link from the Active Directory connector object to the MV must have the synchronization rule `Microsoft.InfromADUserAccountEnabled.xxx` on the link.
-   
+
    When the call comes in from the cloud, the synchronization engine uses the **cloudAnchor** attribute to look up the Azure Active Directory connector space object. It then follows the link back to the MV object, and then follows the link back to the Active Directory object. Because there can be multiple Active Directory objects (multi-forest) for the same user, the sync engine relies on the `Microsoft.InfromADUserAccountEnabled.xxx` link to pick the correct one.
 
 1. After the user account is found, an attempt to reset the password directly in the appropriate Active Directory forest is made.
 1. If the password set operation is successful, the user is told their password has been changed.
+
    > [!NOTE]
-   > If the user's password hash is synchronized to Azure AD by using password hash synchronization, there is a chance that the on-premises password policy is weaker than the cloud password policy. In this case, the on-premises policy is enforced. This policy ensures that your on-premises policy is enforced in the cloud, no matter if you use password hash synchronization or federation to provide single sign-on.
+   > If the user's password hash is synchronized to Azure AD by using password hash synchronization, there's a chance that the on-premises password policy is weaker than the cloud password policy. In this case, the on-premises policy is enforced. This policy ensures that your on-premises policy is enforced in the cloud, no matter if you use password hash synchronization or federation to provide single sign-on.
 
-1. If the password set operation fails, an error prompts the user to try again. The operation might fail because:
+1. If the password set operation fails, an error prompts the user to try again. The operation might fail because of the following reasons:
     * The service was down.
-    * The password they selected did not meet the organization's policies.
+    * The password they selected doesn't meet the organization's policies.
     * Unable to find the user in local Active Directory.
 
-      The error messages provide guidance to users so they can attempt to resolve without administrator intervention.
+   The error messages provide guidance to users so they can attempt to resolve without administrator intervention.
 
 ## Password writeback security
 
-Password writeback is a highly secure service. To ensure your information is protected, a four-tiered security model is enabled as the following describes:
+Password writeback is a highly secure service. To ensure your information is protected, a four-tiered security model is enabled as follows:
 
 * **Tenant-specific service-bus relay**
    * When you set up the service, a tenant-specific service bus relay is set up that's protected by a randomly generated strong password that Microsoft never has access to.
 * **Locked down, cryptographically strong, password encryption key**
-   * After the service bus relay is created, a strong symmetric key is created that is used to encrypt the password as it comes over the wire. This key only lives in your company's secret store in the cloud, which is heavily locked down and audited, just like any other password in the directory.
+   * After the service bus relay is created, a strong symmetric key is created that'is used to encrypt the password as it comes over the wire. This key only lives in your company's secret store in the cloud, which is heavily locked down and audited, just like any other password in the directory.
 * **Industry standard Transport Layer Security (TLS)**
    1. When a password reset or change operation occurs in the cloud, the plaintext password is encrypted with your public key.
-   1. The encrypted password is placed into an HTTPS message that is sent over an encrypted channel by using Microsoft TLS/SSL certs to your service bus relay.
+   1. The encrypted password is placed into an HTTPS message that's sent over an encrypted channel by using Microsoft TLS/SSL certs to your service bus relay.
    1. After the message arrives in the service bus, your on-premises agent wakes up and authenticates to the service bus by using the strong password that was previously generated.
    1. The on-premises agent picks up the encrypted message and decrypts it by using the private key.
    1. The on-premises agent attempts to set the password through the AD DS SetPassword API. This step is what allows enforcement of your Active Directory on-premises password policy (such as the complexity, age, history, and filters) in the cloud.
@@ -113,10 +90,10 @@ Password writeback is a highly secure service. To ensure your information is pro
 
 After a user submits a password reset, the reset request goes through several encryption steps before it arrives in your on-premises environment. These encryption steps ensure maximum service reliability and security. They are described as follows:
 
-* **Step 1: Password encryption with 2048-bit RSA Key**: After a user submits a password to be written back to on-premises, the submitted password itself is encrypted with a 2048-bit RSA key.
-* **Step 2: Package-level encryption with AES-GCM**: The entire package, the password plus the required metadata, is encrypted by using AES-GCM. This encryption prevents anyone with direct access to the underlying ServiceBus channel from viewing or tampering with the contents.
-* **Step 3: All communication occurs over TLS/SSL**: All the communication with ServiceBus happens in an SSL/TLS channel. This encryption secures the contents from unauthorized third parties.
-* **Automatic key roll over every six months**: All keys roll over every six months, or every time password writeback is disabled and then re-enabled on Azure AD Connect, to ensure maximum service security and safety.
+1. **Password encryption with 2048-bit RSA Key**: After a user submits a password to be written back to on-premises, the submitted password itself is encrypted with a 2048-bit RSA key.
+1. **Package-level encryption with AES-GCM**: The entire package, the password plus the required metadata, is encrypted by using AES-GCM. This encryption prevents anyone with direct access to the underlying ServiceBus channel from viewing or tampering with the contents.
+1. **All communication occurs over TLS/SSL**: All the communication with ServiceBus happens in an SSL/TLS channel. This encryption secures the contents from unauthorized third parties.
+1. **Automatic key roll over every six months**: All keys roll over every six months, or every time password writeback is disabled and then re-enabled on Azure AD Connect, to ensure maximum service security and safety.
 
 ### Password writeback bandwidth usage
 
@@ -140,28 +117,32 @@ The size of each of the message described previously is typically under 1 KB. Ev
 Passwords are written back in all the following situations:
 
 * **Supported end-user operations**
-   * Any end-user self-service voluntary change password operation
-   * Any end-user self-service force change password operation, for example, password expiration
-   * Any end-user self-service password reset that originates from the [password reset portal](https://passwordreset.microsoftonline.com)
+   * Any end-user self-service voluntary change password operation.
+   * Any end-user self-service force change password operation, for example, password expiration.
+   * Any end-user self-service password reset that originates from the [password reset portal](https://passwordreset.microsoftonline.com).
+
 * **Supported administrator operations**
-   * Any administrator self-service voluntary change password operation
-   * Any administrator self-service force change password operation, for example, password expiration
-   * Any administrator self-service password reset that originates from the [password reset portal](https://passwordreset.microsoftonline.com)
-   * Any administrator-initiated end-user password reset from the [Azure portal](https://portal.azure.com)
+   * Any administrator self-service voluntary change password operation.
+   * Any administrator self-service force change password operation, for example, password expiration.
+   * Any administrator self-service password reset that originates from the [password reset portal](https://passwordreset.microsoftonline.com).
+   * Any administrator-initiated end-user password reset from the [Azure portal](https://portal.azure.com).
 
 ## Unsupported writeback operations
 
-Passwords are *not* written back in any of the following situations:
+Passwords aren't written back in any of the following situations:
 
 * **Unsupported end-user operations**
-   * Any end user resetting their own password by using PowerShell version 1, version 2, or the Microsoft Graph API
+   * Any end user resetting their own password by using PowerShell version 1, version 2, or the Microsoft Graph API.
 * **Unsupported administrator operations**
-   * Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Microsoft Graph API
-   * Any administrator-initiated end-user password reset from the [Microsoft 365 admin center](https://admin.microsoft.com)
+   * Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Microsoft Graph API.
+   * Any administrator-initiated end-user password reset from the [Microsoft 365 admin center](https://admin.microsoft.com).
 
 > [!WARNING]
-> Use of the checkbox "User must change password at next logon" in on-premises Active Directory administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is supported as a preview feature of Azure AD Connect. For more information, see the article, [Implement password hash synchronization with Azure AD Connect sync](../hybrid/how-to-connect-password-hash-synchronization.md).
+> Use of the checkbox "User must change password at next logon" in on-premises AD DS administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is supported as a preview feature of Azure AD Connect. For more information, see [Implement password hash synchronization with Azure AD Connect sync](../hybrid/how-to-connect-password-hash-synchronization.md).
 
 ## Next steps
 
-Enable password writeback using the Tutorial: [Enabling password writeback](tutorial-enable-writeback.md)
+To get started with SSPR writeback, complete the following tutorial:
+
+> [!div class="nextstepaction"]
+> [Tutorial: Enable self-service password reset (SSPR) writeback](tutorial-enable-writeback.md)