Azure AD Group Writeback

Table of Contents

  1. Intro

  2. Setting Up

  3. Dynamic AD Security Groups

  4. AD Group Access Reviews

  5. Hybrid PIM/PAM?



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 / 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.



With the configuration complete, it was on to the testing!



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.


Logging on to 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!