Password sync in the age of COVID-19
This is something I have been seeing and hearing a lot from customers. So I thought it would be a good time to address the age-old topic of Directory Synchronization.
Azure AD Connect is usually the best way to get up and running quickly in the Microsoft 365 cloud, especially when you are migrating from traditional on-premises infrastructure. This is the basis of having a hybrid environment that spans your data center and the cloud–from here we get some nice benefits:
- Ease of migration from traditional Exchange servers — the hybrid connection with Exchange Online will give you the smoothest possible migration experience, where end-users receive a prompt to close and reopen Outlook (and they should remove/re-add their email profile to their mobile device as well).
- Synchronization of identities and passwords, so if you make a change on-premises, it syncs back up to the cloud
- If you have Azure AD Premium plans, you can also enable password write-back so that users can self-service reset their own passwords from the cloud
But there are drawbacks to this as well. To begin, most small business orgs never set up the password write-back feature, especially if they had a traditional Office 365 license (before the more comprehensive Microsoft 365 bundles were a thing). As well, you are required to keep your old Exchange server around for the lifetime of your Azure AD Connect installation–it is not officially supported to retire it, until you have also removed the Directory Synchronization from the picture. And of course, there is the other issue of remembering what to update when and where–many changes need to be made on-premises and cannot be done via the cloud, as long as you have that connection in place.
So the hybrid setup is not without complexity.
Password resets keep IT in business!
Now that we live in a semi-post-apocalyptic existence, and so many folks are still working from home after a few months of lockdown, we are seeing a new request hit our helpdesks–at a much higher rate than what is typical: Good ol’ fashioned password resets.
Usually this problem will present itself as the user losing access to their cloud resources. Why? Because the password has expired on-prem and the account is locked. Nobody has been in the office, and so they have not been seeing the prompts about changing that expiring password.
I have heard that several affected companies have elected to just remove the password rotation requirement in response to this issue–and that may be okay according to the latest password guidance to come out of security think-tanks, but you have to realize that the advice about moving away from traditional password policies that required complexity and rotation are always suggesting that you REPLACE this strategy with something better: Multi-factor authentication.
But I want to propose something beyond just turning off your password expiry (which you should not necessarily do on-premises if you haven’t yet moved to stronger authentication controls such as MFA).
Removing your Directory Synchronization
This option may not be for everyone. But in the SMB space–honestly, why not just shut down the hybrid and remove Azure AD Connect? Most of the customers who still have on-premises infrastructure are working to pare what remains down to zero anyway, and this is one step closer to that goal. To be clear, I recommend that you do all of the following to make this transition:
- Uninstall Azure AD Connect and also disable synchronization
- Enable Combined Security Information Registration so that users will be able to register for Multi-factor authentication as well as Self-Service Password Reset at the same time
- Enable Self-Service Password Reset (SSPR) features
- Enable Multi-Factor Authentication (MFA), if it is not yet enabled
- Remove password expiry option, if it is enabled in the cloud
- Provide end-users with instruction for registering their security information
Now, at the end of this process, you will have non-expiring passwords in the cloud that have MFA enabled, and users can self-service reset the password if they need to, using their second factor of auth. Plus you eliminated the dependencies and tie-backs to on-prem at the same time–no more updating in AD and waiting for a delta sync to the cloud, etc.! This is a win-win for many SMB’s, AND it brings them one step closer to “cloud-only”–which is their ultimate destination anyway.
Comments (9)
Microsoft will bring Azure AD P1 license to Microsoft 365 Business, which will allow use to use password-writeback even for smb customers.
Correct, and in fact, this is already done. But hardly anyone uses it still. I think most SMB’s are better off severing their on-premises ties unless there is a really compelling reason…
Silly question but does this not require another step for most SMBs – getting computer logins to use the Azure version of username and password and not their local domain controller?
If you want to disjoin computers from the local domain and rejoin them to Azure AD yes, that is another step. Many have moved to joining Azure AD anyway, rather than the legacy domain. In a hybrid environment the Azure AD joined device will still be able to access local network resources, but policy is controlled from Intune rather than GPO. If you are still on the domain, and are not coming into contact with it much because of COVID absence from HQ, you also run the risk of losing the machine’s trust with the domain (might have to disjoin/rejoin when you do eventually come back into the office). Separate issue though.
We’re trying to move away from hybrid sometime, and we’re trying the ‘AAD devices can access internal resources’ thing but it requires AD Connect sync, as best I can tell; certainly the instructions I have do. Most of our users are cloud-only except HQ and our first branch office which still have internal resources (files, printers). I’m now torn between severing AD connect and having a sort of split-brain thing going on where users have to have an internal AD and external AAD/365 account, unsynced, but keep AD hybrid-joined devices – or to keep the sync and migrate the devices to AAD until we have no internal resources… it’s hurting my head. Definitely wanting to follow your advice and get off the hybrid though. Our pure AAD machines and users are way easier to manage in every way.
Yes, excuse my comment, I was just wondering what proportion of SMBs have moved away from domain controller, network drives and group policy etc,
I do not have stats but every customer I have been consulting with this last year or so is looking to move away from on-prem. Most of them are happy to hear that getting rid of their server(s) is an option. The thing that usually delays this the most are LOB apps which rely on Windows Server infra.
In this scenario is it realistic to move these servers from the on-prem environment and into Azure? Or is this not a feasible option? Is it fast enough?
I might be misunderstanding the question–which servers are you referring to? This particular post was not a question about moving on-premises servers or services to the cloud, but rather breaking the connection between local AD and Azure AD. For an SMB this may not deliver enough value for the additional complexity it brings to the table. Plus many SMB’s may not have that many steps to go 100% cloud, without any servers in Azure. Files = SharePoint/Teams/OneDrive, local AD = Azure AD, GPO’s = Intune, LOB apps = SaaS replacements or alternatives.