Microsoft has supported password write-back in Azure AD Connect for just over a year, and we were super excited when it was first announced, but a question that ran through the office was "yeah but what ports will you have to punch open in the firewall?" A variant of that question had doubters predicting Azure AD Connect installations in DMZ's, which seemed like a terrifying idea.
What happened next was one of my favorite experiences of working with a bunch of nerdy people: every single technical employee of the company began to research the question independently. How does password write-back work? Over the next 2 hours, I must have heard at least 6 or 7 "aha's" and "oooh's". It took longer than anybody had thought, but we solved the riddle, each on our own, and each through different avenues.
So we get this question fairly regularly out in the wild. We pitch the idea of reducing helpdesk calls by as much as 30% by simply enabling self-service password resets, but how does it work? What infrastructure changes do I have to make to accommodate this? Because nothing comes without compromise.
The answer is surprisingly simple, frankly: no infrastructure changes are required because password write-back is packaged into communications that are initiated by the Azure AD Connect server on-premises. You don't have to punch open ports because nothing is reaching in. As long as the AAD Connect server has (relatively unrestricted) access to the Internet, configuration is a snap! A simple checkbox to enable it, a user license that supports it, and a flip of a switch in Azure AD, and you're done.
But that level of simplicity raises questions, too. How is the timing orchestrated? Is there a lag between password changes in the cloud and on-prem? Well it does get a bit clunky here, but the long & short of it is no: there is no significant lag. Think seconds, not minutes.
In order to drive down that time and eliminate infrastructure changes, checking the box in AAD Connect to enable write-back forces the replication window down to a few seconds. Yup: you're smacking the Internet connection pretty hard now because in ye olde days it was 30 minutes for everything except password changes, which were "immediate" +/-20 seconds.
So with that constant outbound polling taking place, if a user initiates a password change in Azure (or Exchange Online, or whatever connected Office365-related service), there's now a portion of the connection where AAD Connect asks "and do you have anything for me?" If the answer is no, the connection drops. If the answer is yes, Azure AD holds the connection open and attempts to push the data through. Azure AD Connect then holds the connection open while it communicates the change to a domain controller. Once the DC signals that the change has taken, AAD Connect sends the 'all-clear' back to Azure AD, which then notifies the user that their password reset has succeeded. At that point, the connection is closed, and the user is able to use their new password both on-prem and in the cloud. Pretty simple, yes?
Comments