I am really excited to share this solution! We have had an internal password reset portal that was designed a decade ago, doesn’t scale, can’t be easily accessed, is not mobile friendly, and doesn’t natively support MFA. As we started school this year, thousands of students needed passwords reset, and our existing solution did not hold up well…
MyStaff seemed like a perfect solution, and I was able to get it up and running in just a few hours. The app is a little slow (but getting better), and I ran into issues getting automation to work the way I wanted. After quite a bit of trial and error, I’m happy to report my automation is processing more than 200K entries (many users are in multiple groups/AU’s) in under 10 minutes!
What is MyStaff?
Microsoft MyStaff is a solution designed for retail and other businesses that have non-technical users (like store managers) managing passwords, MFA, and things like phone numbers for their employees, often remotely or from mobile devices. This model lines up really well for school librarians and other staff who often reset student passwords, especially during remote learning.
This app is in Preview, and you will need to enable the feature in Azure and have the appropriate licenses for your users. The admin documentation will show you how to do this along with all of the other features and setup requirements. My solution simply automates most of this using Powershell 😉
The end user documentation is quite simple, and the experience looks great on a mobile device (and not as great on a full desktop). Also, note the icon I put red around is multi-tenant support!
How does MyStaff work?
To condense content from the documentation, we create an Administrative Unit (AU) in Azure AD, add users as members of that AU (kind of like a group), and then we add administrative users to various roles of that AU, such as Password Administrator, which gives them permission to reset the password for any user that is a member of that Administrative Unit.
When the password administrator resets a password, it prompts for a temporary password which the admin gives to the user, and then the user sets a new password at their next logon. If the user is synchronized from on-premise AD, you’ll have to enable password write-back in Azure AD Connect to sync that password back down to AD.
My automation solution
The solution I created helps automate setup and synchronization processes and provides a base for you to extend if you’d like to add more functionality, such as the ability to manage MFA, phone numbers, group membership, etc. I did not automate licensing as part of this…
The way it works is that you provide a list of group names you would like to essentially turn into AUs, the prereqs script will create the AU and a password administrator security group for each group, the members script will keep the membership of the group in sync with the AU, and the admins script will keep the password administrator role membership in sync with the password administrator security group.
You can access the scripts here: https://github.com/nathanmcnulty/nathanmcnulty/tree/master/Azure/MyStaff
Nitty Gritty Details
OK, so you’ve made it this far! 🙂
Here’s the list of steps needed, and if you are edu/gov feel free to join us on the Opsecedu Slack if you have questions (email firstname.lastname@example.org)
First, you need to enable password-writeback if you are using Active Directory. It’s also highly recommended the admins have at least Azure AD Premium P1 and enforce MFA and other policies via Conditional Access for the MyStaff app: Documentation!
- Security groups populated with users that you intend to allow admins to reset passwords for
- Create the list of these group names and select a prefix you’d like to use for this solution
- Modify the prereqs script as needed, drop the list in however you want, and it should create AU’s and new security groups in the OU you specified.
- Populate the new admin security groups with the users you want to have password reset permissions for
- Run the Update- scripts which will read group memberships from Azure (way faster than AD) and populate the membership and roles
These update scripts can be run automatically in three different ways. The first, and wrong way (which I’m currently doing…), is to do a “Get-Credential | Export-CliXml -Path <script path>\creds.xml” and then uncomment the code and reference the XML file. The two issues are that this doesn’t method doesn’t support MFA and the credential file must be created by whatever account will be running the scheduled task.
There other two ways are Azure Automation (which may incur a very small cost) or running Powershell using application tokens. I am working on both of these methods so that I can at least document them, and I will post a follow up once a few other things are taken care of 🙂