Table of Contents
Intro
Microsoft has released a big update to its Azure AD group writeback feature. The most significant change is that security groups can now be provisioned directly into AD from the cloud and managed via the Azure Portal.
With multiple ways of managing group membership in Azure, this opens lots of possibilities for controlling access on-premises, so I was keen to test some scenarios.
The only requirements are an up-to-date Azure AD Connect (anything newer than December 2021 / 2.0.89.0 onwards) and an Azure Premium licence.
Setting Up
First things first, I had to enable group writeback in the Azure AD Connect config wizard:
And set the destination for newly provisioned groups. This can’t be changed afterwards without disabling and reenabling the feature, but you can move groups out of this OU after they’ve been created by AAD Connect. A feature I found useful was to enable the display name -> DN feature, otherwise the groups would have had unhelpful names like Group_{guid}. It is possible to create a sync rule to do this, but it’s handy to have an option to handle it for you.
After enabling group writeback, I found some inbound and outbound sync rules had been added to handle the provisioning.
Inbound:
Outbound:
With the configuration complete, it was on to the testing!
Scenarios
Dynamic AD Security Groups
Security groups with static/assigned memberships are perfectly possible, but a more interesting example of what can be done would be to drive membership in AD with criteria, as you might with Microsoft Identity Manager.
So, I created a new security group in Azure called ‘All Synced Users’:
And set the membership rules to (user.dirSyncEnabled -eq true) :
In other words, every on-prem AD user is within scope.
Lastly, I had to go into the group properties after creation and set the ‘Group writeback state’ to ‘Security’:
I assume that setting this option exposes the group via Graph, as I couldn’t see anything in the inbound scoping filter of AAD Connect to differentiate groups that had this enabled from those that don’t.
One sync cycle later, and a new AD group had been provisioned in my writeback OU containing all users within scope!
AD Group Access Reviews
Another interesting possibility is using Azure’s Access Review feature to control membership of an on-premises group. This group could provide access to something downstream, and to ensure membership doesn’t get out of control, a selection of reviewers could be asked periodically to verify that everyone who has access, should. This is something that can be done in the MIM Portal with Management Policy Rules (MPRs) and workflows, but it requires experience and development time as it’s not OOTB functionality.
I started out again with a new security group in Azure, but this time I put my AD-synced test users into an assigned membership (dynamic membership overrules the Access Review rendering it pointless). I added myself as the owner, although it’s not required.
Again, I had to expose the group to AAD Connect by setting the ‘Group writeback state’:
And here was my group in AD, membership populated as expected:
On to the access review! There are a bunch of ways to get to the Access Reviews page, but I went in through the link on the group page itself. I selected ‘All users’ as the scope, the reviewer as the group owner (I could have just as easily stated the reviewer explicitly), the duration as one day – shame there were no smaller periods for test purposes – and set the recurrence as ‘one time’; for real-world applications a monthly review might be useful.
Finally, I set the results to automatically apply to the resource – in other words, strip users of membership if I didn’t approve them in the review. Not that it mattered for my test, but I chose ‘No change’ for non-responses. In production, a harder line could be taken if required.
I gave the review a name and hit create.
Testing
Logging on to myaccess.microsoft.com as the owner, I could see the new review:
I chose to deny all my test users to strip them of their memberships, but I wouldn’t find out if it worked until the following day…
…And it did work! The audit logs in the Azure Portal showed that ‘MS-PIM’ had removed the five test users from group, and following a sync in AAD Connect, the group in AD reflected that. Great!
Hybrid PIM/PAM?
Azure has Privileged Identity Management (PIM) to enable users to request elevated Azure permissions for a short period of time. If you want to do something similar in AD you need something like Microsoft’s Privileged Access Management (PAM) via MIM, or a third-party solution. Could something similar be achieved with Privileged Access Group (part of PIM and currently in preview) and Group Writeback?
To find out, I needed to create a new security group in Azure AD with the option to allow Azure AD Roles to be assigned to it. This was an important step, as it can only be applied on creation of the group. It should be noted that I’m not actually interested in assigning any roles to it – I’m just leveraging this feature to allow users to request membership. For security reasons, membership type is limited to ‘Assigned’ for Privileged Access Groups:
Next, I had to enable group writeback as before, but also ‘privileged access’:
I added an assignment to make test user Dave Smith eligible to submit requests for membership:
If you’re familiar with PIM, you’ll know that the assignment end date is not how long they gain access, but rather the period within which they can submit requests for short term access.
Testing
So, my test group was empty as expected, and I needed to see if I could request access as the test user and have the membership pushed down to on-premises AD. I opened a new InPrivate window and logged on to Azure Portal with the test user’s credentials.
Under Privileged Identity Management is the Privileged Access Groups (Preview) link, and sure enough, the test group was there:
Opening the group gave the option to activate, just like any other eligible PIM assignment:
Activation duration could be anywhere from half an hour to 8 hours, although the assignment options can be tweaked to allow up to 24 hours:
I activated for half an hour then kicked off a sync. The test user was now in the group in AD!
To complete the test, I’d need to wait until the activation expired or deactivate it manually. As the wait time was so little and I was keen to see the automation in full effect, I decided to let it run its course. 30 minutes later and as if by magic, the user had disappeared from the AD group.
Imagine the possibilities!
Comments