What is Azure Active Directory Password Writeback?
This is where users are able to reset their Office 365 account passwords. This provides users with easy access to be able to manage and change their passwords from any device that they are authorised to use. Currently the password writeback feature is a part of Azure Active Directory Connect which can only be accessed if you are subscribed to Azure Active Directory Editions.
What are the benefits of using Azure Active Directory Password Writeback?
- No delays on giving feedback when resetting passwords: This ensures that if a user is trying to reset their password and it doesn’t meet your organisations complexity requirements then they will get notified almost instantly. This will save confusion when the user would next try to log into Office 365 if the password wasn’t strong enough.
- Matches up with your on-premise Active Directory password policy: If you have password policy’s set up for users for your on-premise Active Directory for example user’s having to have at least one number and one capital letter in the password, these will be enforced when users go to change their passwords using Password Writeback.
- Doesn’t require firewall changes: No changes to inbound firewall ports need changing due to Password Writeback due to it using Azure Service Bus relay.
- Can also be used with ADFS and other federation services: As long as your organisation’s user accounts are synced with your Azure AD tenant all on-prem Active directory passwords can be managed from Azure AD Password Writeback.
- Supports Admin’s being able to reset users AD passwords from the Azure portal: If an administrator resets a user password the same password will be then set in the on-prem Active Directory.
- This supports Azure AD Pass-Through Authentication: If your organisations accounts are synced with your Azure AD tenant they can manage their on-prem AD passwords from Azure.
How does Azure Active Directory Password Writeback work?
Firstly Password writeback checks to see the type of password the user has and if its seen they have a password that is managed on-prem then it will then begin the checks. The checks consist of making sure that the Writeback service is actually running. This service can usually be found on whichever server you have dedicated as your Azure AD Connect server. If for any reason it is having issues or isn’t running the user then gets notified that they are unable to reset their password at that time. The user will then be asked to authenticate with MFA which will be set to the same details as set up when you first sign into Office 365 with MFA enforced. The user will now have the option to reset/change their password.
Azure will then encrypt the password with a Symmetric key which would have been created back when Writeback was set up in your organisation. This will then get sent via the Azure bus relay which I mentioned earlier in the blog, this is secured by a randomly generated password that can only be identified by your organisation’s on-prem Active Directory. When it reaches your on-prem Active Directory the password reset endpoint will then see that it has a pending request. The service will then need to look for the user by using the cloud anchor attribute, this will require three things to succeed:
- The user object must exist in the Active Directory connector space.
- The user object must be linked to the corresponding metaverse 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 request comes from Writeback the Sync engine will use then ‘CloudAnchor’ attribute to look up the Azure AD connector space object. After the user account is found Writeback will try to reset the password in the organisations Active Directory forest. The operation should then be successful which in turn will trigger Writeback to then inform the user that the password has been changed successfully.
Troubleshooting issues with Azure Active Directory Password Writeback
Sometimes you may encounter issues with using Azure AD Password Writeback. One of the most common is when a user tries to reset their password and is then greeted by the following error message:
One potential fix for this by restarting the ‘Microsoft Azure AD Sync’ service, this will force the connection between the AD connect server and the online Writeback service to fix connection issues. The only risk to restarting this is that if it is only one user experiencing issues then other users trying to reset their passwords at the same time will then also have the same error. If however this error is effecting all users in your organisation then you can go ahead and start this without any risks.
Another troubleshooting step is to try and install the latest version of Azure AD Connect, this is fairly simple and can be done by first simply downloading the latest version of this from the Microsoft Download Centre onto your AD Connect server. From here you then need to simply follow the installation wizard this will then refresh your connection between the server and the online Writeback service.
One more thing that you can try is making sure that Azure AD connect has the right level of permissions, the main permission that it requires is the ‘password reset’ permission. To achieve this you will need to go to Synchronisation service manger and click onto the connectors tab, from here you will need to highlight the Active Directory connector and go into the properties. You should now have a pop up window that shows the Active Directory Domain Sync account used by Azure AD Connect to perform the Active directory synchronization. With the account name you will need to then search this in your on-prem Active Directory console and double click/right click and select properties. The tab ‘Security’ should now be available to select, simply select this and click on the ‘Effective Access’ tab which should be the third one across. Now you will need to select the option ‘select a user’ to select the account used for AD DS that you found earlier and finally hit the ‘view effective access’. You will now be presented with a list of permissions with ticks or crosses next to them depending on if the account has the permission, the permission you will be looking for is the ‘password reset’ one. If the account has that permission ticked then you can rule out permissions being an issue.
