On September 30th, 2022, Pim Jacobs and I did a session on the brand new Lifecycle Workflows feature in Azure AD Identity Governance. During that session, I did a demo showing the integration with Logic Apps. Using this extension, I could use the Graph API to create a new Temporary Access Pass for a new hire, 7 days before the first workday. This post will describe the steps to build the solution.
Introduction to LifeCycle Workflows
First, let us quickly talk about the new feature. Lifecycle Workflows in Azure AD Identity Governance will bring automation capabilities to the Joiner-Mover-Leaver processes in your organization.
Workflows can have one or more tasks that can be scheduled or run on demand. All scheduled runs are based on the EmployeeHireDate and EmployeLeaveDateTime attributes in Azure AD. To give you an idea, here is an example of a workflow.
Task: enable the account, send welcome mail, and add the user to the corporate team in Teams.
When (trigger): Seven days before the NewEmployeeHireDate attribute value.
Who (scope): new hires in the Sales department.
Lifecycle Workflows can be extended to Logic Apps using the Custom extensions feature. In this blog post we are taking a look at one of the use cases that we can solve with Logic Apps.
If you want to learn more about this new feature, please check: What are lifecycle workflows? – Azure Active Directory – Microsoft Entra | Microsoft Learn
Let’s have a look at the overview of the workflow that we are building today. 7 days prior to the EmployeeHireData, a new Temporary Access pass will be created using a Logic App. Next, an email will be sent to the new hire and their manager. The Temporary Access Pass itself, will be sent using SMS to the new hire.
Built-in tasks v.s. custom tasks
In this demo, I will use a custom extension to provide the Temporary Access Pass directly to the user. There is, however, a built-in task that might be sufficient for most organizations. Note that this does not require any Logic App or delegation of permissions and has some additional security checks in it. The default task will send the TAP to the manager instead of the new hire, which might be good enough for most organizations.
The default task allows you to do some customization as well so that works really intuitively.
My advice would be to start out with the templates and built-in tasks first.
This scenario has some important requirements. To start off, we need an Azure AD Premium P2 license because Lifecycle Workflows is part of Azure AD Identity Governance. We also need access to an Azure subscription to create a new Logic App.
Next, we need a couple of attributes in place:
- userPrincipalName. This will be part of the welcome email.
- mobilePhone. This is where we will send the new Temporary Access Pass.
- EmployeeHireDate. This is needed to schedule the workflow.
- otherMails. This is the private email of the new hire. This is used to send the welcome email.***
***You might want to use an extension attribute for this field in a hybrid scenario, as the otherMails attribute can not be synced with Azure AD Connect Sync.
Next, we need the manager attribute to be filled in. Some tasks will rely on the manager’s property, at least in this case, it does.
For this demo, I prepped Debra’s account with the required attributes. Note that this account is a cloud-only account. If you want to test this on a hybrid account, please make sure you have synced the employeeHireDate with Azure AD Connect Sync or Cloud Sync.
To use Temporary Access Pass, it must be enabled on your Azure AD tenant. To do this, sign in to the Azure portal as an Authentication administrator and select Azure Active Directory > Security > Authentication methods > Temporary Access Pass to enable the policy for all or selected users.
Create new Custom extension (Logic App)
When you use the wizard to create a new custom extension (recommended), the following items will be created for you automatically:
- The Logic App itself.
- The Trigger and Callback action.
- System-managed identity.
- Authorization policy.
If you want to use existing Logic Apps, please read more here: Configure a Logic App for Lifecycle Workflow use – Microsoft Entra | Microsoft Learn
In the Azure portal, head over to Identity Governance -> Lifecycle Workflows -> Custom extensions to create a new one.
Configure the new extension to the following settings, and select your Azure subscription to create the new Logic App. I picked the Launch and wait option, to also get familiar with the callback option. You can also pick the Launch and continue option, but that will consider the task done when the Logic App is launched.
After the wizard is done, you can check the new Logic App, and its settings. Note that it will only have two steps, the trigger, and callback URI. The wizard also created a new system-managed identity and configured the authorization policy.
Adding permissions to the system-managed identity
Now that our Logic App is created let’s focus on the permissions. Since the Logic App needs to create new Temporary Access Passes (amongst other tasks), we will add the Authentication Administrator role to the managed identity to grant these permissions. This role will have enough permissions to get information about the subject and create a new Temporary Access Pass. We could also grant specific Graph API permissions like UserAuthenticationMethod.ReadWrite.All, but adding the role is less privileged for this use case.
First, grab the object ID from the managed identity. You need this in the next step.
Then, find the app in Enterprise Applications, and add the Authentication Administrator role to the service principal (system managed identity).
Building the Logic App
Now that we have our Logic App created and have the permissions in place, we can start building our solution in Logic Apps designer. I won’t go into detail here, but you can find the expanded capture here, or download the template from GitHub.
- Setting the variable Audience to https://graph.microsoft.com so I can re-use it in the HTTP actions.
- I use the ID to grab a few more attributes from the subject (new hire) to use have attributes like givenName and mobilePhone.
- Grabbing the private email addresses from Graph API.
- Since step 4 gives me an array, I use this step to grab the first item of the list.
- Creating a new Temporary Access Pass using Graph API.
- Send a text using the Twilio connector. Feel free to use any other connector, or sign up for a free trial.
- Send an email to the private email of the new hire, and add the manager in cc.
Building the workflow
Now that we have all the pieces in place, we can create the workflow. The easiest way is to start with one of the templates. In the Azure portal, head over to Identity Governance -> Lifecycle Workflows -> Workflows, and select + Create workflow to get started.
Select the first template: Onboard pre-hire employee.
You can leave the displayname and description as is, or give it a custom name. Adjust the trigger details if you want, or go with the default of 7 days. We will not enable the schedule, and only run the flow on demand, so it does not matter for now.
Next, leave the scope details as is, or adjust the expression to your needs. For now, we leave this to run for new hires in the Marketing department only.
On the workflow task tab, delete or disable the default task, and add a new one.
After the task is added, click on the “Run a Custom Task Extension“, next to the amber icon, and select the custom extension that we created earlier.
At the final page of the wizard, review your settings and hit “Create” to build the workflow.
When the workflow is created, select the new workflow, and click “Run on demand” on the overview page.
Select your prepped testuser, and click “Run workflow“
You can review the status in both the Workflow history, and the Logic App runs history.
If all goes well, Debra will receive both the email and SMS with the information about her new Temporary Access Pass.
Let’s wrap up
Lifecycle Workflows in Azure AD Identity Governance are definitely a great asset to Azure AD. Administrators can now automate most common tasks that are often done manually for new hires, movers, or leavers. In this demo, we discussed the custom extensions, but I want to point out that the built-in tasks are also a great starting point for most processes. Think about adding users to groups or teams.
Please check out this documentation about the attributes needed for Lifecycle Workflows: How to synchronize attributes for Lifecycle workflows – Microsoft Entra | Microsoft Learn
Stay tuned for more posts about this topic.
Plan a Lifecycle Workflow deployment – Microsoft Entra | Microsoft Learn
Configure a Logic App for Lifecycle Workflow use – Microsoft Entra | Microsoft Learn
Lifecycle workflows FAQs – Azure AD (preview) – Microsoft Entra | Microsoft Learn
Thanks this is great. This is timely as we’re currently deploying a new onboarding process with user data flowing in from Workday so I can’t wait to try this out.
However, otherMails isn’t an on-prem field that can be synced with AzureAD Connect. Guess the best way is to dump it in an extensionattribute then write some other automation or script to write that into otherMails.
Thanks, that is great feedback. I will add that as additional note.
Looking into this further, it looks like OtherEmails is what the user provides in SSPR, so I’m not even sure I’d want to sync this with on prem AD anyway. I’m thinking that using an extension attribute is the way to go here anyway.
Pingback: Endpoint Manager Newsletter - 7th October 2022 - Andrew Taylor
Pingback: Synchronize attributes for Lifecycle workflows - Azure AD Connect Sync - JanBakker.tech
Thanks for sharing! I modified this slightly, so it gets the SSPR email address. This is also a bit more secure as it can prevent a potential lateral movement attack as User Administrator can for instance change the otheremails attribute but only Auth Admins can change the SSPR email.
Pingback: Azure AD Access reviews and the power of Machine learning – Set-AzWebApp -name "Anything Microsoft and other stuff on the side"
Great share, thanks a lot!
The only point I feel a little uncomfortable security-wise with is to send a TAP (:= stong auth) to the user. Don’t matter if this is by SMS (correct phone number) or by (private) mail address. I am thinking more about using the initial user password provided on one channel (private mail?) and an “exchange” code for TAP on another one (SMS?). The initial password can be used to sign-in to a “TAP” web app where the exchange code is then be required to generate a TAP on-the-fly. This way the initial auth process always requires two factors. You can even consider to hand-over the exchange code by the manager, who can’t do anything in delegation with the exchange code alone.
Agree, it might be a better idea to send the TAP to the manager (this is also in the template)
See this as a proof of concept for LA integration with LCW, rather than security best practices.