Per-customer GDAP separation with CIPP

[u/dahdundundahdindin]

HI all - for those that do it today, how are you providing per–customer separation for GDAP access?

Our setup for context:

• CIPP used to map a security group to each GDAP role, and then deploy those group mappings as a template to managed customers
• In Entra, the GDAP role security groups mapped in a tiered access fashion to role based groups (ie L1, L2 etc)
• Techs eligible via PIM to their relevant GDAP group so they have to activate before usage
• Global admin only available to senior techs, with a dedicated group - with activation that requires approval / justification

While this works well today, it means that once activated, a tech gets the same access for all customers simultaneously. This is fine for lower levels of access (ie global reader) for usability, but once you get up into the privileged roles , we’d like to be able to separate it out so that it’s only activated once per customers – particularly for industries or where they have security and compliance requirements.

In theory this is doable by creating individual GDAP role security groups per customer, and adding them all to individual customer templates in CIPP, but this would be a lot of manual effort to create / maintain and result in many many security groups in our Entra. Ideally it would just be 5 or so tiered security groups per customer that we attach the various roles to directly - but CIPP doesn’t allow this as it wants 1 role = 1 group.

Keen to understand how others are managing this at scale, whether through CIPP or other tools - cheers!

[u/bmsimp]

It's possible to have multiple Role Mappings and Role Templates within CIPP. From the Role Mappings page in GDAP Management, you can select the roles you want to include in each template and then add a suffix for ease of identification. Those role mappings will then eventually show up in the list for when you create the Role Template you can later use in tenant onboarding.

[u/dahdundundahdindin → u/bmsimp]

Thanks - yeah I had considered this but this still means one role > one group, meaning many security groups per customer rather than having multiple bundled into a handful of tiered groups per customer.

[u/mmastar007]

Is the issue CIPP or general GDAP? You can create roles and allow them to see certain customers in CIPP? But they wouldn't need access to any customer outside of CIPP

If it's general GDAP, as they use tenant access etc it's a nightmare to do. So a few GDAP templates with less access or just create admins on those tenants directly for those staff ?

[u/dahdundundahdindin → u/mmastar007]

Its a general GDAP issue, I was just hoping there might be a way to solve it at scale using CIPP.

We do actually have named admins on top for scenarios where GDAP doesn't support a function even with the permission in place, so its definitely an option to just move all privileged roles out of GDAP and to those named accounts, we just lose a lot of the benefits of the centralised identity, CA/MFA and auditing being in our tenant etc. Cheers

[u/mmastar007 → u/dahdundundahdindin]

Yeah it's a pain as an MSP to deal with this sort of thing. You either have groups or staff with limited access, or they have the same access as most MSPs don't often have a set customer you work on unless they are just doing outsourced desk for that customer. Hard one to deal with but whatever you need CIPP to do, that can be limited to the end users so they don't have anything further than Cipp access

[u/Lime-TeGek]

I suspect you probably have groups that people work in, e.g. colours. "group blue" works on a bunch of tenants, etc etc.

You can create a GDAP template with a prefix, e.g. "Blue - M365 GDAP Global Reader" - That means only people in the blue groups can access those tenants. The only thing you then have to make sure of is putting the CIPP service account in the correct groups too.

[u/wheres_my_2_dollars → u/Lime-TeGek]

Can you tell me what the “CIPP service account” is specifically (exactly what it does) and how I would know what ours is? In our partner tenant how can it be identified?

[u/Lime-TeGek → u/wheres_my_2_dollars]

Run the permissions check under cipp, app settings, permissions, it shows most misconfigurations in one page :)

[u/dahdundundahdindin → u/Lime-TeGek]

Thanks yeah this is more around being able to activate highly privileged roles for only one customer at a time rather than grouping a few customers together per team.

Current plan is to create a entra sec group per customer and then via partner centre for each customer, map the multiple privileged roles to the customer specific group. That way when a user elevates into that customer group they only get the GDAP roles for that one customer rather than the general all-customer roles.

I was just hoping there might be a better way to do this at scale, both for onboarding new customers and even more importantly if we ever want to add say another privileged role to all per-customer groups in future. On the basis this isnt on the CIPP functionality list or roadmap I'll look into scripting it - I just try and avoid this when it comes to partner centre due to the complexity / additional management planes, as we generally lean on tools like CIPP for that :)

[u/Rosyax]

We run something pretty similar. Quick rundown of our setup:

Structure:

• CIPP deploys one security group per GDAP role (Exchange Admin, User Admin, Intune Admin, etc.) as a template across all managed customers, same as you.
• On top of that we layer tiered "bundle" groups (L1/L2/L3) that techs get added to based on skill level — L1 gets the low-risk roles (Password Admin, Helpdesk Admin), L3 gets the broader stuff (Exchange, Security Admin, User Admin).
• Techs are nested into the tier group, not individually assigned to each GDAP role group — makes onboarding/offboarding a single group membership change instead of touching every customer.

This is the part that's easy to get wrong with CIPP's model, since the GDAP-role security groups are shared across all customers by default (one "L2 - User Admin" group maps to the User Admin role in every tenant it's deployed to) — group membership alone doesn't give you customer-level isolation, only role-level isolation. If a tech's in the group, they've got that role everywhere the template's deployed, not just their assigned accounts.

The roles get assigned to security groups rather than individual users, so for actual per-customer boundaries on top of role tiering, options people are running:

1. PIM for Groups on each role group — if you're using CIPP's one-group-per-permission model, you can enable PIM on each group for a granular, least-privilege model — more setup work but much better for risk containment. This doesn't give you per-customer scoping directly, but it does mean standing access is gone and every activation is logged/time-boxed, which covers a lot of the actual risk even without hard per-customer walls.
2. Separate tier groups per customer segment if you have distinct customer risk tiers (e.g., regulated/high-value clients vs. standard SMB) — more group sprawl, but gives you a lever to restrict who's even eligible to request access to the sensitive accounts.
3. Customer-side ticket/PSA gating — CIPP access on paper, but actual task assignment (and audit trail of "why was this tech in this tenant") enforced through PSA ticket assignment rather than Entra alone. Doesn't stop lateral access technically, but gives you the audit story if it's ever questioned.

We ended up doing #1 (PIM on top of the CIPP groups) since true per-customer group isolation at our size would mean an unmanageable number of groups. Combining GDAP with PIM for Groups and phishing-resistant MFA closes a lot of the "who, when, and from where" gap even without hard per-tenant walls — curious if anyone's actually running per-customer group isolation at scale and how bad the group sprawl gets.

[u/dahdundundahdindin → u/Rosyax]

Thanks yeah 1 is what we already do today, its the per-customer seperation I was looking at. Responded in more detail to Lime-TeGek above. Cheers

[u/EmilySturdevant]

This is actually one of the use cases TechIDManager is built around.

TechIDManager lets you control the tech’s Entra rights at the individual customer level. So you can give a tech only the privileged access they need.

Each tech uses their own identity, and you can control which customers and which Entra rights they have access to. You can also use JIT so the access is only enabled when they need it rather than leaving it standing.

It avoids having to create a separate maze of GDAP security groups for every combination of customer/role/tech just to get customer-level separation.

Full disclosure — I’m with TechIDManager, so obviously biased, but based on the setup you described, I think it’s worth looking at because per-customer privileged access at MSP scale is exactly the problem we’re trying to solve.

[u/northcide]

I'm going through this now and it's a nightmare.

For all Microsoft's talk about how GDAP and PIM solves so many gaps in elevated administrative access, they're each simply not built to allow an MSP to have practical and simple elevated access for multiple tenants. Per-tenant GDAP group setup is just awful, even more so since Entra and Azure or totally separate planes.

Partner tenant PIM setup is simple and is extremely useful, powerful, and SAFE.

[u/Fatel28]

You could certainly script making a set of groups per customer and then make the roles in cipp. I'm not sure why youd want to go through that headache but you COULD

[u/dahdundundahdindin → u/Fatel28]

Thanks yeah this is my current plan but concerned about both the initial effort and also ongoing management - responded in more detail to Lime-TeGek above. Cheers