☁️
Tminus365 Docs
  • πŸš€Welcome to Tminus365 Docs
  • πŸ”Security
    • Azure AD (Entra)
      • MFA Shall Be Required for All Users
      • MFA is enforced on accounts with Highly Privileged Roles
      • MFA is enforced for Azure Management
      • MFA registration and usage shall be periodically reviewed
      • Legacy Authentication shall be blocked
      • High Risk Users Shall Be Blocked
      • High Risk Sign-Ins Shall Be Blocked
      • Browser Sessions shall not be persistent for privileged users
      • MFA shall be required to enroll devices to Azure AD
      • Managed Devices shall be required for authentication
      • Guest User Access Shall be restricted
      • The number of users with highly privileged roles shall be limited
      • Users assigned highly privileged roles shall not have permanent permissions
      • Activation of privileged roles should be monitored and require approval
      • Highly privileged accounts shall be cloud-only
      • Highly privileged role assignments shall be periodically reviewed
      • Passwords shall not expire
      • Azure AD Logs shall be collected
      • Only Admins shall be allowed to register 3rd party applications
      • Non-admin users shall be prevented from providing consent to 3rd party applications
      • Authorized Applications shall be configured for Single Sign-On
      • Inactive accounts shall be blocked or deleted
    • Teams
      • Private Channels shall be utilized to restrict access to sensitive information
      • External Participants SHOULD NOT Be Enabled to Request Control of Shared Desktops or Windows in Meet
      • Anonymous Users SHALL NOT Be Enabled to Start Meetings
      • Automatic Admittance to Meetings SHOULD Be Restricted
      • External User Access SHALL Be Restricted
      • Unmanaged User Access SHALL Be Restricted
      • Contact with Skype Users SHALL Be Blocked
      • Teams Email Integration SHALL Be Disabled
      • Only Approved Apps SHOULD Be Installed
      • File Sharing and File Storage Options shall be blocked
      • Only the Meeting Organizer SHOULD Be Able to Record Live Events
      • Attachments SHOULD Be Scanned for Malware
      • Link Protection SHOULD Be Enabled
      • Restrict Users who can Create Teams Channels
      • Teams Channels shall have an expiration policy
      • Data Loss Prevention Solutions SHALL Be Enabled
    • Exchange
      • Automatic Forwarding to External Domains SHALL Be Disabled
      • Sender Policy Framework SHALL Be Enabled
      • DomainKeys Identified Mail SHOULD Be Enabled
      • Domain-Based Message Authentication, Reporting, and Conformance SHALL Be Enabled
      • Enable Email Encryption
      • Simple Mail Transfer Protocol Authentication SHALL Be Disabled
      • Calendar and Contact Sharing SHALL Be Restricted
      • External Sender Warnings SHALL Be Implemented
      • Data Loss Prevention Solutions SHALL Be Enabled
      • Emails SHALL Be Filtered by Attachment File Type
      • Zero-Hour Auto Purge for Malware SHOULD Be Enabled
      • Phishing Protections SHOULD Be Enabled
      • Inbound Anti-Spam Protections SHALL Be Enabled
      • Safe Link Policies SHOULD Be Enabled
      • Safe Attachments SHALL Be Enabled
      • IP Allow Lists SHOULD NOT be Implemented
      • Mailbox Auditing SHALL Be Enabled
      • Alerts SHALL Be Enabled
      • Audit Logging SHALL Be Enabled
      • Enhanced Filtering Shall be configured if a 3rd party email filtering tool is being used
    • SharePoint
      • File and Folder Links Default Sharing Settings SHALL Be Set to Specific People
      • External Sharing SHOULD be Set to β€œNew and Existing Guests”
      • Sensitive SharePoint Sites SHOULD Adjust Their Default Sharing Settings
      • Expiration Times for Guest Access to a Site SHOULD Be Determined by specific needs
      • Users SHALL Be Prevented from Running Custom Scripts
    • OneDrive
      • Anyone Links SHOULD Be Turned Off
      • Expiration Date SHOULD Be Set for Anyone Links
      • Link Permissions SHOULD Be Set to Enabled Anyone Links to View
      • Windows and MacOS devices should be prevented from syncing the OneDrive Client on personal devices
      • Legacy Authentication SHALL Be Blocked
    • Intune
      • Personal Devices should be restricted from enrolling into the MDM solution
      • Devices shall be deleted that haven’t checked in for over 30 days
      • Devices compliance policies shall be configured for every supported device platform
      • Noncompliant devices shall be blocked from accessing corporate resources
      • MFA Shall be required for Intune Enrollment
      • Security Baselines should be configured for Windows Devices
      • Windows Update Rings shall be configured for Windows Devices
      • Update Policies shall be configured for Apple Devices
      • App Protection policies should be created for mobile devices
      • Mobile devices shall only be able to access corporate data through approved client apps
      • Lockout screen and password settings shall be configured for each device
      • Encryption shall be required on all devices
      • Windows Hello for Business should be configured where applicable
      • Authorized Applications should be deployed to managed devices
      • Device Use Shall be restricted until required applications are installed
      • Devices and Applications shall be wiped when a user leaves the organization or reports a lost/stolen
  • βš™οΈConfigurations
    • GDAP
      • My Automations Break with GDAP: The Fix!
      • Vendor Integrations Break with GDAP: The Fix!
      • Adding GDAP Relationships
      • Leveraging PIM with GDAP
      • GDAP Migration with Microsoft 365 Lighthouse
    • GoDaddy
      • Defederating GoDaddy 365
  • πŸ›‘οΈCIS Controls
    • CIS Mapped to M365
  • πŸ”ŒVendor Integrations
    • Pax8
      • Automating NCE subscription renewal notices
      • Leveraging the Pax8 API in Power Automate
    • IT Glue
      • Automating Intune Device Documentation in IT Glue
      • Automating Microsoft Documentation
    • Huntress
      • Leveraging the Huntress API in Power Automate
    • Syncro
      • Automating Microsoft 365 Documentation in Syncro
      • Custom Connector in Power Automate
      • Creating Tickets for Azure AD Risky Users
Powered by GitBook
On this page
  • Why do my integration break?
  • MSP/Partner Prerequisite Steps
  • Vendor Action Items
  • Security Considerations
  • Consent on behalf: Pros and Cons
  • Helpful Resources
  1. Configurations
  2. GDAP

Vendor Integrations Break with GDAP: The Fix!

PreviousMy Automations Break with GDAP: The Fix!NextAdding GDAP Relationships

Last updated 1 year ago

In October of last year, I published an article explaining how GDAP breaks vendor integrations:

This is specifically for Vendors using an integration that leverages delegated access into downstream customer tenants. If you are a vendor that requires consent to your integration at a per tenant level, this article does not apply to you. This article will have many similar prerequisite steps that I outlined here:

This previous article outlines how an MSP can continue to leverage internal automations with GDAP. In this article, I will be outlining the steps for a Microsoft CSP Partner/MSP and vendor to take in order for integrations to work with GDAP. Note that if these steps are not taken, your integration will break.

Timelines As of the writing of this article 5/4/2023, Microsoft states that will begin auto-transitioning relationships to GDAP starting May 22, 2023. If this timeline holds true, this is when I believe many people will be reading this article, as their automations will stop working. Get ahead of this now!

Consulting If you would like some more targeted consulting as it relates to these changes, please reach out to me at msp4msps@tminus365.com

Why do my integration break?

Accessing tenants as a Microsoft partner has traditionally been done with Delegated Access Permissions or DAP. DAP provides you Global Administrator access to all of the downstream tenants. Whenever you set up an app registration using the Secure Application model, you would add that service principal to the Admin Agents group in Partner Center. By doing so, you were able to generate refresh tokens and access tokens into all of your customer environments. We have been leveraging this model for years now to create automation workflows. This model of consent is known as a β€œpre-consent” since there were no additional steps you needed to take in order to leverage the app registration in these tenants.

Shifting to GDAP, the core benefit is the additional layers of security provided to help protect yourself and your downstream customers against supply chain attacks. As part of the shift to this new model, the β€œpre-consent” concept is no longer in play. We now need to take additional steps to consent for applications in our downstream customer tenants. The good news is that this can still be done in bulk using an β€œon-behalf of” consent model, meaning you do not need to grant consent to your application registration on a per customer basis. The bad news is that it now requires many more additional steps and gets confusing. Hence this article 😊

MSP/Partner Prerequisite Steps

Here I will outline what you need to direct the MSP/Partner to do in their own environment in order for your integration to support GDAP.

Create a Service Account for the Integration

The first thing to do is set up a new service account for your integration. The format could be something like <YourCompany>@mspdomain.com. I think it is important to have a dedicated account here so that nothing breaks over time if you have users leaving the partner organization. As a best practice, do not use a regular user account for your integrations. Here are some requirements for this service account:

  1. They need to be a Global Administrator initially. We will need this service account to have the GA role when we acquire access tokens in future steps. This user does not need to have perpetual GA rights so it is recommended to leverage so that you can make this user eligible for the role when you need it and reduce your attack surface.

  2. This user requires MFA. This can be enforced through Conditional Access or Per User MFA settings. This MFA has to be with Microsoft and cannot be from a 3rd party like Duo

  3. This user needs to be added to the Admin Agents group in Azure AD

Important! If possible, direct the MSP to leverage a documentation tool like IT Glue or Hudu to store the MFA token and password for this user so that it can be accessed by more than one person if needed.

Configuring GDAP Relationships

Another prerequisite is that the partner has added a GDAP relationship for all of their customers.

If you are not familiar with GDAP, check out my other blog post:

The roles scoped as part of those relationships is very important. There are two major concepts that you have to consider:

  1. In order to leverage the on-behalf consent model to grant your application rights to downstream customer environments, we need the relationship to have one of the following Azure AD roles:

    1. Global Admin

    2. Privilege Role Admin

    3. Cloud Application Admin

  2. Additionally, in order to make specific API calls, the GDAP relationship needs to include roles that would encompass those permissions. i.e. if you added a permission for your integration to read configuration profiles in Intune, you would need the Intune Administrator role as part of the GDAP relationship.

This means you need to direct the MSP/Partner for the roles that they need to have as part of their GDAP relationships with customers.

The other key step partners need to take with GDAP relationships is to assign a Security group for the GDAP relationship that includes the service account we created in the first step as a member. The partner could create a Security group specific to your integration or they could leverage an existing security group. In my use case, I created a group called GDAP_SG1 and added my service account as a member:

In Partner Center, the partner will need to ensure that this security group is assigned to each GDAP relationship and has at least one of the following permissions:

  1. Global Admin

  2. Privilege Role Admin

  3. Cloud Application Admin

Vendor Action Items

Whether you have an existing integration or are creating a new one, you will need the MSP/Partner to follow the steps above. Your steps are as follows:

  1. Build a workflow that leverages the Secure Application Model to acquire access tokens for the MSP/Partners environment.

  2. Leverage the consent API to consent to your integration for the partner’s downstream customers.

Secure Application Model Flow

During this flow you will want to programmatically do the following:

  • Create an App Registration in the Partners Tenant

  • Create and store the app registration Secret Key, Client ID, and Partner Tenant ID

  • Generate and store a refresh token

In this flow, the partner will be using the service account created in the previous section. The permissions you add should be everything that your integrations need to work.

Get Downstream Customers

Consent On-behalf

Microsoft has created an API to consent on-behalf of downstream customers vs needing to consent to an application one customer at a time.

You will use an access token generated from the application registration created in the Partners tenant with the Secure Application model. In the body, you will pass in the application ID, Application Name, and a list of all of the application grants part of your integration. Ex:

Each enterprise applciation ID represents a particular workload in Microsoft. Its likely you will mostly be interacting with the Graph API workload. Here are the workload IDs:

Once this is complete, you will be able to acquire access tokens into downstream customer environments and make API calls for that tenants information. (Like you might already be doing today).

Updating Permissions

Additional Considerations

Security Considerations

If you are a vendor (not providing any self-hosting capabilities), it is extremely important that you manage the secrets for the application in a very secure fashion. Encryption at rest and in transit are table stakes. If these secrets or refresh tokens were to get breached, an attacker could leverage the same workflow you use for your integration to cause damage in downstream customer environments. Their access would be limited to the permissions scoped by your integration and what GDAP roles the service account has access to so its not as much of a widespread security concern as what we have today with DAP but still warrants the highest levels of attention in my opinion.

Consent on behalf: Pros and Cons

I think as a vendor and as an MSP, you need to strongly consider the Pros and Cons of using the on behalf of consent model I described in this article vs consenting on a per tenant level

Pros:

  • As a vendor and MSP, your onboarding time for getting all customers integrated is significantly reduced. We are talking about having to login with each customer you want to integrate (per tenant) vs having all of that automated through a setup wizard and only having to sign in with one account.

  • As a vendor, if you ever updated your permissions, you can automate the consent across customers vs having to ask the partner to reconsent across all customers again.

Cons:

  • As a vendor and MSP, you have to perform all of the prerequisite steps for GDAP that I outlined here and make sure that the GDAP relationship includes permissions needed for the integration. If you just did per tenant consent, you do not have to worry about GDAP at all. At the end of the day, this could provide a much better customer experience and less helpdesk calls.

  • As a vendor, you have a lot more overhead to worry about to support this configuration. This includes storing many more secrets, creating a specific workflow to set up the secure application model, refreshing tokens, and having a job that can run the consent API.

Helpful Resources

Your app will need to support a front-end that can walk an MSP/Partner through the Secure Application Model Process.

βš™οΈ
Vendor Integrations will Break with GDAP – (tminus365.com)
My Automations Break with GDAP: The Fix! – (tminus365.com)
Privileged Identity Management (PIM)
What is GDAP
GDAP Checklist
Leveraging PIM with GDAP
Enable secure application model – Partner app developer | Microsoft Learn
Control Panel Vendor APIs for customer consent – Partner app developer | Microsoft Learn