Having an Azure AD as your additional or main directory is a good thing. Unlike AD DS, which is built having primarily on-premises environments in mind, Azure AD is much more flexible and more adoptable to today’s hybrid environments. As most of us probably know, Azure AD serves as a directory and as authentication/authorization mechanism for most of services running on Azure. Most commonly, it is used by Office 365. However, it is even more interesting when you use it together with your local AD DS environment. Synchronization between AD DS and Azure AD is very easy to setup – if you don’t need much customization, you can do it in literally few clicks. On the other hand, if you want to customize it or do some fine tuning – you have plenty of options for that.
In this post, I want to emphasize some less known things and facts regarding passwords and attributes of user accounts when using Azure AD in hybrid environment, with locally deployed AD DS.
One of the things that are so desperately missing from AD DS is self-service password reset. Sure, you can implement it on the AD DS if you deploy Microsoft Identity Manager, but usually it’s not worth so much. Azure AD provides you with this functionality out-of-the-box. However, in hybrid, if you use Azure AD Premium P1 or P2, you can use this functionality even for your local AD DS. All you have to do is to configure self-service password reset in Azure AD admin portal, while having password-write back enabled by Azure AD Connect (followed by few PS commands executed locally to set appropriate permissions to write passwords).
Self-service password reset functionality gives users the option to reset their own password without requiring intervention by an administrator. To reset a password, users must do additional authentication of their identity. The following alternative authentication methods are available – Email, Mobile phone, Office phone, Security questions. These alternative authentication methods must be setup by user before actually using this functionality. You can find very good resources on SSPR here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-passwords-overview and for password write back, see here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-writeback
Users can change their passwords via the login page or user settings in Office 365, and have them written back to on-premises AD DS, when you deploy Office 365 in hybrid scenario.
Let’s see few more useful things about user accounts when used in hybrid environment:
- If you accidentally delete a user account and a directory synchronization cycle runs, this action will delete the user in Office 365. However, if you have the recycle bin feature enabled in AD DS, you can recover the account from the recycle bin, and the link between accounts is re-established. If you do not have the recycle bin enabled, you might need to create another account with a new GUID.
- Synchronized user accounts that you delete from your local AD DS will also appear in Deleted users section in Office 365 admin center. However, if you restore this type of deleted user account, it will reappear as account created in cloud and will not be synchronized with local AD DS anymore.
- Password policy that you configure in the Office 365 applies to user accounts created in Office 365. However, if you synchronize user accounts from your local AD DS, these accounts will be affected by password policy that you configure by using Group Policy in your local domain. Password settings from your local AD DS override password settings in Office 365, for synchronized accounts.
- You should be aware that for synchronized user accounts with password hash sync, their corresponding cloud account password is set to Never Expire. This means that a user can continue to sign in to Office 365 by using a synchronized password that is expired in your on-premises AD DS. Cloud password for such user is updated when a user changes the password in the on-premises environment.
- If you have user accounts in your local AD DS that are set to expire at some time, as part of user account management, you should know that accountExpires attribute is not synchronized to Office 365. Because of this, an expired account in your local AD DS, configured for password hash synchronization will still be active in Office 365. It is recommended in this scenario that you have a workflow action that runs a PowerShell script that disables the user’s account in the Office 365.
