GDAP is the latest Microsoft change that is having many MSPs working overtime to figure out. I’ve been blogging about GDAP for some time so if you are not familiar, please go check out my overview articles before diving in here.

Our company, Summit Technology (an MSP out of Salt Lake), recently went through the process of moving to GDAP internally, so I wanted to document and share our findings. Hopefully this will provide you more guidance and allow you to spend less time on doing some of the investigations we went through.

Our Checklist:

1. Educate

The first thing I wanted to accomplish was a general education around GDAP. I am the SME in our organization, but I wanted everyone to have a basic understanding of the benefits to GDAP along with transition timelines and overall functionality. I wanted our team to start brainstorming ways in which our processes would change from GDAP. I also wanted to communicate timelines so we could coordinate a proper project plan for converting our customers. We know from experience that Microsoft is known to change timelines multiple times (NCE cough cough) but this was a project that does provide useful security benefits immediately so it’s a higher priority because of that reason.

Action Items:

  • Assign a SME for GDAP
  • Hold a working session/session(s) to educate your techs on GDAP. (They will be the ones most affected)
2. Discover

I wanted to have concrete data on what techs were accessing today and what frequency. Ultimately, I wanted to use this information to help us determine how we might partition the various Azure AD roles across security groups and also decide if those groups should require additional security controls (i.e. PIM). I thought about having the techs manually document what they were accessing for a certain period of time but I wanted it to be more specific. Like most MSPs, we had also created Global Admins in customer tenants specifically for accessing resources that weren’t available via Partner Center like the security admin center. I wanted to know the frequency of us leveraging those accounts as well.

For that reason, I created this PowerShell script that captured the Sign In Logs from Azure AD in every customer tenant. It looks for both our delegated sign ins along with the GA accounts we have in the customer environments. Note that to pull the sign in logs, you do need an Azure AD P1 license in the tenant. We have at least M365 BP in all customers, so we did not have any limitations here.

From there, I created a simple PowerBI dashboard that allows me to see what areas of M365 we are accessing the most along with the access on a per technician basis. We added some splicers to see by customer as well.

Lastly, I also reviewed and exported data from the Admin Relationships Dashboard in Partner Center. This allowed me to see tenants in which we hadn’t accessed in some time (30-90+ days). I added this info to the Power BI report and shared with the team.

There were other investigation items that we defined at this time (which I cover later)

  • What are the minimum roles we need to support our customers?
  • How will GDAP affect our competencies?
  • Will this affect anything with 3rd party integrations?
  • How will this affect our access to Azure subscriptions?
  • What is our distributor doing for GDAP?

Action Items:

  • Get a better understanding of the resources your technicians are interacting with to better understand what GDAP roles you want to use
3. Define

After reviewing the discovery information with the team, we developed a proposed structure for our Security Groups and associated Azure AD roles. We ended up using a couple of support articles from Microsoft as well to help us make these decisions:

Just to note here we have a smaller team (>5) so there was not a need to get more granular than what you will see below. If you have a larger team, were certain techs are doing specific work, I recommend breaking the groups up even further. 
 

Here is our distribution of roles:

 

SG1

  • This is the list of roles our techs access the most. We wanted to give reader privileges where applicable and not inhibit their day-to-day work.

SG2

  • This group has roles that are more privileged but are accessed on a lesser frequency. 

SG3

  • While the GA role is not recommended with GDAP, we discovered we needed this role in customer tenants to perform on-behalf consent for App registrations. (I get to this later in the article)

At first, I only wanted to make SG2 and SG3 PIM enabled groups. After further consideration, we decided to make all SGs PIM enabled. This might seem counterintuitive to productivity at first but we considered it the right move because:

  • Techs can PIM during the day for up to 8 hours
  • SG1 still included some sensitive permissions like being able to reset passwords, delete users, etc.
  • PIM allows us to not have these roles active in after hours
  • We could apply additional PIM level controls on higher level SGs like enforcing MFA to activate
  • SG1 => PIM enabled 
  • SG2 => PIM enabled + Justification Reason
  • SG3 => PIM enabled + Justification Reason + MFA Push + Approver

Action Items:

  • Determine which roles you need access to within your customer environments
  • Partition the roles to various security groups
  • Leverage PIM enabled groups for high level roles (No reason you shouldn’t, Microsoft is giving Azure AD P2 for free for 2 years to indirect resellers)
  • Define the Naming convention you want to use for GDAP relationships
  • Define the duration of the relationships (max 2 years)
4. Review

After we came up with proposed roles based on the data, we reviewed the groups and structure with all technicians. The goal here was to establish alignment and to move more roles into the higher level SGs where possible.

Action Items:

  • Get you techs to sign off on the proposed roles
5. Test

After we had established our proposed groups/roles, we decided to test with one customer. This was a customer that had a medium level of support request so we see how it impacted the techs job on doing work. We created a GDAP relationship in Partner Center and manually accepted in the customer environment. Ultimately, we were looking to capture the following:

  • What notifications does the customer get?
  • Are we blocked from portals that we need access to?
  • Can we still access our Azure subscriptions?
  • Is there any functionality we weren’t expecting?

We documented this along with any other general findings. Overall, this went well, outside of Partner Center not loading sometimes (go figure).

Action Items:

  • Create a GDAP relationship with a customer to test the changes
  • Understand that the GDAP relationship can be terminated as a roll back
    • Do not remove the existing DAP relationship with the customer yet (GDAP takes precedence over DAP while the two coexist)

 

6. Modify/Prepare

In this stage, we determined if we needed to make any modifications to our Security Groups or roles after testing. Additionally, we did the following:

  • Defined a date that we would move all customers to GDAP using the bulk migration tool
  • Determined what notifications customers would get and set up communications to let them know of this change.
  • Determined our break glass GA account in all customer tenants:
    • Since you will have to renew GDAP relationships at least every 2 years you will likely want a GA account in the customer environment to get that done.
    • We used PIM in all customer tenants to leverage an MFA enabled Global Admin eligible account. This means that this user does not have perpetual GA rights.
      • We have some customers on E5 so this was included. We purchased 1 Azure AD P2 licenses in customers who did not have this licensing. Its $9/month so its not too expensive, especially for the security benefit it derives.
    • Define a date we would remove DAP relationships (Microsoft states they will do this for you at a certain point in time)

Action Items:

  • All of the above
7. Bulk Migrate

After we had successful testing, we decided to use the bulk migration tool from Microsoft to move all eligible customers to GDAP. This tool is only available till end of November at the time of this blog post. I showed how to use that tool here.

Action Items:

  • Leverage the bulk migration tool or CIPP to move to GDAP across customers

Things we learned:

Customer Notifications

When a GDAP relationship is accepted, all Global admins in the customer tenant will get the following email:

From Microsoft’s support docs there is also a termination notification email as well: 

Who receives a GDAP relationship termination notification email?

  • Within a partner organization, people with the Admin agent role receive a termination notification.
  • Within a customer organization, people with the Global admin role receive a termination notification.
  • proactive email notifications 30 days, seven days, and one day before the GDAP expiration date.
Vendor Integrations/App Registrations

If you have a vendor that leverages an app registration or are using an app registration to perform some automation across your customers, the integration will break when moving to GDAP (removing DAP). See the full details on this here.

Competencies

Competencies aren’t affected with the change to GDAP. As long as you have a reseller relationship with the customer, you will continue to get competencies. If you work with a distributor, they are the one associating your MPNID (Now known as the PartnerID) to the customer and establishing you as that customers reseller.

Azure Subscriptions

Azure Subscriptions still require that you are at least a contributor level role on the Azure subscription itself to get PECs. Access to Azure subscriptions is still dictated by the roles assigned to the subscription itself. GDAP really didn’t change anything for us here. We still leverage Azure Lighthouse to manage all of our customers Azure subscriptions.

Distributors

Distributors should be communicating with you about their plans for GDAP and timelines. You should be asking them what roles they plan to provide as default along with any tools they may be using to help migrate. Remember that all the security you are establishing means almost nothing if the distributor is not taking the right actions for GDAP.

Overall Experience/Conclusion

I’ll be honest in saying that this experience has been frustrating at times mostly because of the performance of Microsoft’s APIs. Partner Center pages taking minutes to load, GDAP relationships sometimes not showing up, SG assignments staying stuck in pending. This seems to be better now but there was a full week where we didn’t get much work done because of the APIs.

I hate that Microsoft built a migration tool that isn’t built into Partner Center. I get that the dev work to do this is a bit of a sunk cost as it will be for a limited period of time but if your goal is to get compliance on people moving to GDAP, why not make it easier to understand and do? Why not take this time as a large investment on educating the community on the benefits via Partner Center?

All that aside I believe GDAP is going to be amazing for the community. Supply chain risk is a huge threat and GDAP is giving us a great way to manage that. It pains me to see MSPs in forums talking about GDAP and saying “well I just am going to add all of the AD roles because I do not want to lose the levels of access I have today.” This completely defeats the purpose and overall value of GDAP. This is not like NCE where you are doing massive amounts of work to get negative benefits. This is actually a great change for your practice.

I hope this provides more of a checklist when it comes to moving to GDAP that you can use at your MSP today. Feel free to hit me up at msp4msps@tminus365.com if you have any questions.

Helpful Resources

Share with the Community