"Number four?" <spoken in the deli counter attendant's dead-pan voice>
For a loooong time, you and I have been waiting for the ability to sync ‘cloud-born-and-managed’ security groups (and their memberships) back into on-premises AD. This takes us further on our journey of moving "the management plane" from on-prem AD to the cloud - and provides you the ability to create/manage groups in the cloud to manage resource access in Active Directory.
BLINKING CAUTION LIGHT:
- This V2 Group Writeback feature is in public preview.
- You're playing with Directory Services fire here.
- This is a helpful feature BUT it has the potential to make big (possibly massive) changes to your on-prem AD.
- Be sure you fully understand what the default options are AND what you have set in your environment.
- It is entirely possible that all M365 Groups from your M365 tenant will be back-sync'd into your on-prem AD.
- Don't mess with this in isolation/by yourself - get a peer on your team to work with you so you can double check one another.
- Test, test, test again.
Okay, now that I've gotten your attention, here are some details:
- Top of mind for me was 'where will they end up in AD?' You configure the target OU and the way the Groups will be named when they’re written back:
- NOTE: If you don't select the checkbox to name the group from the Display Name, it's ugly:
- Once you’ve enabled the capability, then it’s just an option for your cloud groups:
NOTE: The security groups from the cloud are written back/created in AD as Universal Security Groups
NOTE: Cloud-only users who are members of the cloud group won't be back-sync'd into AD; this won't create new AD users
- In my environment, I use a naming prefix of '- CG - ' to indicate 'Cloud Group' and a prefix of '- OPG - ' to indicate 'On-Prem Group.'
To Retrofit ... or not?
If you're like me, I bet you're asking/wondering if an existing on-prem group can be transitioned to cloud-managed. The answer (for now, at least) is "No."
So, you may need to do some work in the on-prem environment to use the 'new' back-sync'd groups instead of existing on-prem AD groups.
If you name the new cloud groups to align with your existing on-prem AD group naming standards, it will be easier to 'find' them in the various AD object picker/permissions UIs. Then, you could just add the new group to the ACL for the resource and at some point, remove the old one. This naming standardization effort could also aid you if you go down the route of scripting to replace groups.
Another idea I had - but have not tested yet - would be to simply 'nest' the new back-sync'd group into the existing AD group that provides access to a given on-prem resource. It probably would work but we all know group nesting can sometimes be "an adventure."
STILL-BLINKING CAUTION LIGHT: Re-read the cautions at the top of this post. I love to reminisce about IT horror stories but don't be 'the star' of a new one here. FYI, manual member adds from AD into the back-sync'd group will get wiped out upon 'next sync.' There is a non-default option that an ‘on-prem’ back-sync’d group in AD will be deleted if you disable the write-back option for the source group in the cloud (that may be something you want - but it may be a painful surprise).
For more information:
A series recap (so far):
- The Twelve Days of Blog-mas: No.1 - A Creative Use for Intune Remediations - Microsoft Community Hub
- The Twelve Days of Blog-mas: No.2 - Windows Web Sign in and Passwordless - Microsoft Community Hub
- The Twelve Days of Blog-mas: No.3 - Windows Local Admin Password Solution (LAPS) - Microsoft Community Hub
Cheerio!
Hilde
Microsoft
