We’ve all been there as a sysadmin. It’s 0845, you’ve not long walked in to the office, you’re making your morning tea and you’re approached by a manager … “Hi, this is Bob, they are starting with us today, they will need email, phone and a laptop ASAP” (if you’re lucky you get a please as well!). We’ve all been there. You fill with dread and maybe anger as you think about the fact you need to create an account in Active Directory, hopefully you have AAD connect to create your Office 365 mailbox account, then you need to do Slack, Workplace by Facebook, Salesforce and all the other systems that your company use. Best make a second cup of tea …. it’s going to be a long morning!
One of the best pieces of advice I was given was to automate yourself out of your job. You might think this is odd … if I automate myself out of a job then what do I do? Well, if you’re spending all morning setting up the accounts above, you’re not able to perform something more exciting (that shiny new server is giving you the eye after all), you’re not able to learn (you’re reading this blog to learn aren’t you?) and lets be honest, creating accounts is hardly exciting. So why not automate all of this?
Make HR the master of the Data
Microsoft have released provisioning connectors for Workday and others are coming including Oracle and SAP. These connectors use your Azure AD tenant to manage the attribute mapping and connector configuration. It does require a provisioning engine to be installed within your AD environment for it to work. Other options include using a providers ‘sync service’, where they have supplied some software to automate this task, or you could potentially use a custom PowerShell script to download the data from your HR system and automatically create users. With the data now being mastered in the HR system, any changes to the directory are done automatically, when someone changes job titles, departments or names the provisioning service will take care of it for you. Why make HR the holders of all this data? Well, they are the ones that will know of any hires, fires or changes. After all everyone wants their paycheck!
Whilst we’re on the subject of HR being the master of the data, I mentioned that they will know when someone leaves the business. This is a key aspect in securing your Active Directory environment. How many times have you, the admin, not been told that someone has left the business and their account is still active? Using provisioning services connected to a HR system means that those accounts can be automatically disabled when someone leaves the business.
If you don’t use Active Directory, you’re a cloud only company and you rely solely on Azure Active Directory, Workday can provision directly to AAD as well. You don’t have to miss out!
All together, this looks a little bit like this:
For more information on HR Cloud provisioning using Azure AD check out this Docs page.
Provisioning to AAD
Hopefully if you’re using Active Directory, you’ve already enabled Azure AD Connect, with password write-back and Password Hash Sync. If not, this is your next stage to enable automatic user creation and deletion based on changes to your AD environment.
SCIM Provisioning
Now, here comes the magic. Azure AD is able to make use of the SCIM protocol to automatically provision and most importantly deprovision users from SaaS Applications. The list of applications that support SCIM is growing constantly.
What is SCIM?
SCIM is the System for Cross-domain Identity Management. It’s a standard adopted by the IETF and is currently on version 2.0. It’s published under IETF RFCs 7643. It was originally called Simple Cloud Identity Management which is where it gets its name from, the name change occurred when the IETF took over.
Why use this service?
It’s simple, automation. I mentioned earlier in the post that I want to automate myself out of a job so that I can focus on learning, improving, mentoring, generally all the fun stuff. Making use of SCIM provisioning allows me to do this. Microsoft handily have a collection of tutorials available on the Docs site. On the left you can find a list of gallery apps that support User Provisioning, along with the important bit how to configure it. If your SaaS application isn’t listed on the tutorials, check with them, they might support it already. If they don’t, put a feature request in. After all, SCIM is a standard. It doesn’t just work with Azure AD, but Okta and others as well.
Making use of SCIM provisioning from Azure AD has another benefit. How many sync apps are you currently running in your environment? They all run on servers, servers which cost money to power, take administrative time up for patching and or upgrading. SCIM provisioning all occurs in the Azure cloud. Now, you no longer need to run those servers.
The bulk of this post has surrounded joiners and leavers, but those aren’t the only changes that need to be automated. What about your movers? When someone moves from Sales to Finance. This is where automating your JML process comes in to its own. How many times have you been told that someone moved, so you added the finance access but didn’t take away the sales access? Making use of the automation from your HR app, you can have a script that reviews job titles and makes sure that they have the correct access. If you’re in a pure Azure AD environment, why not make use of Identity Governance Entitlement Management? With Dynamic groups deciding what access packages are available based on Department, job title, office. Automatically revoking access when it’s no longer required.
And how do you know that SCIM provisioning is doing what you think it is? Well, you can manually check through the audit logs looking for provisioning events. But manually checking something isn’t automating myself out of a job. First, Aaron Smalser wrote a script that is on GitHub that you can run and produce a report of the actions performed. But now everything is moving to the Graph API from Microsoft. As a result, I am re-writing the script to make use of the new API. At the moment, paging isn’t supported on queries against the new Provisioning API so doing a daily report isn’t working however keep an eye on my GitHub repository for the update. I have written the script which can either output to a TXT file or send an email for you to review. Once paging is available via the Graph API, I will update the script in the repository.
Conclusion
So now I have painted the picture of utopia. Everything is automatically provisioning, updating and deprovisioning when someone leaves. In the morning you have a scan through your report for any errors/issues and all is good. That’s potentially one of your biggest most time consuming jobs automated. When the manager comes over with the new starter, you can say hello, lets reset your password and off you go! Now you can go look at the other cool stuff like Conditional Access to enforce MFA and block legacy authentication.
But Wait
I hear you cry …. I know, you’ve got to magic up a laptop/desktop from somewhere. You don’t use WDS or similar to deploy operating systems. You don’t have SCCM for deploying Office and all the other apps a user needs. My day is still ruined preparing last minute machines for people. Yeah I hear you. But after automating the user provisioning, I took time to learn Intune and set up everything using Autopilot 😉 but that’s another blog post in it’s own.
