We’ve recently been asked about, and wanted to implement internally, self-service password resets via Office 365. Not only do we want to enable password resets, we also want to enable writeback to on-premises Active Directory. That’s a little more tricky.
Mirazon has been using Office 365 and a subset of the applications therein for quite some time. We’ve recently been maturing some of those processes and wanted to implement self-service password reset for our consulting engineering staff. Below is how some of the larger pieces shook out for us. This is not a complete walkthrough; it is more of the useful “bigger items” that we came across and how they look for you.
First of all, it’s important to understand that Azure AD is at the heart of this and that there are four flavors of Azure AD (AAD) today: Free, Basic, Premium 1 and Premium 2. Microsoft page has a really handy page with matrix/chart for your reference.
Next, it’s important to know that password reset in and of itself is managed via AAD – either using the classic portal or the new hotness preview portal. We chose to use the new hotness preview portal. You can access the portal from several places, but, if you’re familiar with Office 365 administration, then just getting to AAD from the Office 365 admin portal is probably the easiest. It’s at the bottom left.
Once you navigate from there into the Azure preview portal, you’ll need to begin the process of creating your password reset policies.
We’re locking this down to the engineers for now – that’s one of our groups.
Next we have to discuss some of the authentication methods by which we’ll allow engineers to self-service the reset of their password. You’ll notice we allow either mobile phone (text or call) verification or the more ubiquitous “security questions” model as well.
From there we can make changes based on how users register for self-service password reset using the setup portal.
Great. Now we have policies. Next we need to get on-premises Azure Active Directory Connect properly configured and set up to allow for the two-way password reset writeback capabilities that we desire. From the AAD computer, we can handle this via PowerShell.
After we populate an environmental variable, we can then use that to handle things like password reset notification and writeback. You can see the order of operations below.
We get the information to make sure it’s not currently enabled, then we set it to be enabled, then we get it again to verify it. That’s it there.
So now we have policies, and have AAD doing its thing, but we still need to handle some on-premises Active Directory permission to make sure the writeback happens. Inside your AAD computer, there is a service account with a funky name. That account needs a specific subset of Active Directory permissions. They aren’t easy to find and don’t fit on a single page, so I have not provided a screenshot. If you’re unsure of which account needs these changes, it’s the one that’s used to synchronize your directory and usually starts with “MSOL_,” as you can see below.
Almost there. Now we need to make sure our engineers are licensed with Azure AD Premium 1.
Great. All the pieces are in play. Now we need to send our engineers to the password reset portal.
And, how about we test a password reset?
Excellent! I realize these are only the high-level steps. A proper combination of your Office 365 licensing and usages of Azure Active Directory can do a lot of things for your organization. Maybe an easy first step is considering a self-service password reset portal.