How do I ensure that two permission groups don't contain overlapping individuals?

Anyone have a slick way to make sure that two permission groups don’t contain overlapping individuals? I’m having to add in an audit to make sure two different pull request approval teams don’t contain the same person and create a scenario where one person could approve a specific PR scenario on their own

I have multiple approval groups in certain scenarios (as well as the submitter not being able to approve their own PR), so I need an approval from the Dev Leads and from QA to let code move out of a Feature branch… Dev leads approving it is code complete and reviewed, QA approving that it is feature complete and tested. I need to be able to show an auditor that I at least have a process in place to detect if someone got put in to both groups

Audits are fun.
Are there any assumptions you can make, such as everyone in ADO is assigned through AAD? For example, could a previous process already have flagged any users directly assigned an ADO group?

Can a dump of users in each group be sufficient evidence that someone is monitoring the condition?

Short of writing a script that pulls both groups and runs a diff, I’m not sure of a way. Depending on what you’re allowed to assume, the script may be very simple or may need to pull from the Azure DevOps API.

<https://ravingroo.com/1030/powershell-compare-membership-of-two-active-directory-groups/|Here’s an article> with a PowerShell command that compares AAD groups.

I wish they were all AAD, but with contractors that’s not the case. I think I’ll need to just query both ADO groups and see if anyone is in both

And I’ll put that check in to the PR build and annoy everyone by failing PR builds if the PR approver groups are in an invalid state

It’s easier to prove you have the 'cant approve own changer’s policy set.

It’s not about approving their own changes, they already can’t do that

Bob makes the PR from FeatureA to Development. We require someone from the DevLeads group and the QA group to approve that. DevLeads for code review, QA to approve that that Feature branch was QA approved before it’s merged to the Development branch

If Bob is a DevLead, he can’t approve that PR and another DevLead has to approve it.

I’m trying to make sure that Steve isn’t put in bot the DevLead and QA groups and one persons’s PR approval satisfies both rules

I like adding it as part of the PR rules! It’s like failing a build due to a style cop, except for admins. Someone needs to clean that up before anything moves forward.

That’s my plan, I just need to write a script that does that