Microsoft Partner Center Secure App Model and the challenges of automating Powershell in the modern Microsoft 365 world…
Microsoft 365 encompasses a wide range of features across many products, each has one or more individual management portals and one or more Powershell modules. The fun starts when you want to try and write a script to execute without human interaction. To achieve anything beyond a simplistic level of interactive automation you will quickly realise this is not an easy task. There is not a lot of information, guidance is complex and there are very few good sources to work from. Checking the Microsoft documentation will lead you to believe that most things are not supported or possible, yet with some wizardry and hard work, much can be achieved.
Our goal is to simplify and automate the common administrative tasks needed to deliver IT services to end-users. Our platform (Atria) securely executes prescriptive processes without requiring direct user interaction. Users of Atria can now perform powerful administrative tasks safely without needing administrative permissions, or more importantly needing to understand Powershell! This enables more self-service, empowering the frontline service desk and means less low value work being completed by expensive resources. Processes are also simpler and quicker to execute.
With the growth of Microsoft 365 we have enabled Microsoft CSP Partners to create new tenants, manage users in Azure AD, we create subscriptions, assign licenses to users and have features to manage core Exchange Online features.
The Secure App Model
The Secure App Model was introduced approx. a year ago. For more information on the Secure App Model, the Microsoft page Enabling the Secure Application Model Framework is a good place to start. This is mainly relevant to Microsoft CSP Partners, as it is very much focused on how to enable a trusted third party (the partner) to administer on behalf of their end-customers. It’s primary purpose is to enable the procurement and resale of Microsoft services into end-customers.
The model uses Azure AD as the foundation for Access Control. An Azure AD application is created and configured, then “granted” access to a number of well known security principals, the customer/partner relationship then allows the CSP partner to perform tasks on behalf of the end customer (tenant).
The Azure AD Application is initially configured interactively by an MFA enabled administrative account, the application operates on behalf of this user and handles authentication by exchanging a “refresh token”. The Refresh token is refreshed on a regular basis. The combination of ApplicationID, Application Secret and refresh token secure the connection.
Why is it hard?
it’s possible to follow the Microsoft guides and get this all working. The challenges are faced when you need to go beyond creating subscriptions or tenants. As you work to use different APIs you may find challenges in:
(a) Changing your powershell scripts to use the secure app model.
(b) Granting your application the correct “consents” needed to access the right resources.
(c) Making your automation scripts authenticate correctly and then function as designed.
When you think you’re making progress, you’ll likely arrive at needing to use a different Powershell module which either doesn’t support the secure app model, or there is no clearly documented solution.
What have we done to help?
As a CSP provider, you will likely have a need for configuration changes via the many API’s available but the complexity and problems with the Secure Application Model has made this difficult to implement.
Atria now includes out of the box capability which handles baseline consents and the authentication needed for your scripts. You can use this to extend our standard processes or you can create your own. It sets your Powershell connection up with the right security context needed to perform actions for the tenant or user, this automatically creates the right context for each of your customers.
Key Benefits
- Enables execution of custom powershell scripts when provisioning tenants or users
- Connection to Powershell providers handled seamlessly by Atria using secure application model.
There are two actions provided for your use – one for Customer/Tenant context (MSOL Run Customer Script) and one for user context (MSOL Run User Script)
Both are similar – the latter adds the user specific parameters. Currently we can provide the correct context for executing the following:
API Connections Supported
| Connection | Provider | Use for |
| AzureAD | Azure Active Directory Powershell 2.0 | Azure AD management |
| Exchange | Exchange Online Powershell | Exchange configuration (uses Exchange online v1 Powershell) |
| Graph | Microsoft Graph Manage Microsoft 365 with Windows PowerShell for Delegated Access Permissions (DAP) partners | Provides graph token variable with an access token to allow you to send https requests to Microsoft Graph. |
| MSOnline | MS Online V1 Powershell module for Azure Active Directory | Older Powershell library for managing AzureAD and Office 365 |
| PartnerCenter | Microsoft PartnerCenter Powershell | For managing subscriptions, billing, customer details within PartnerCenter |
| SecurityCenter | Office 365 Security and Compliance | Security and Compliance Configuration. |
Variables available to use within your script
The following variables are available for use within your script by default – you do not need to pass them in as optional parameters.
| Variable Name | Available | Description |
| $CustomerID | Always | A reference to the Atria CustomerID (primary key of customers table) |
| $TenantId | When tenant exists in Azure AD | The Microsoft AzureAD globally unique tenantID (GUID) |
| $UserAzureID | When user exists in Azure AD | The GUID of the user in Azure AD |
| $Session | When Exchange has been specified as a connect option | Holds the connection to the Exchange Remote Powershell session. |
| $GraphToken | When Graph has been specified as a connect option | Holds an access token for Microsoft Graph. |
| $SecurityCenterSession | When SecurityCenter has been specified as a connect option | Holds the PowerShell Session connection to the Security and Compliance Endpoint. |
For existing Atria customers, we have more documentation available and can help you get started. If you are not an Atria customer but want more information, feel free to get in touch – keen to understand your challenges and to see if we can help, we will not attempt to sell you our software if it is not a good fit for your business.
If you want more information on how the Secure App Model works for the different Microsoft 365 components, then the following places are relevant sources of knowledge.
Microsoft Links:
Microsoft guidance on how to Manage Microsoft 365 with Windows PowerShell for Delegated Access Permissions (DAP) partners. This covers how you can run powershell in the context of a tenant for common tasks, but is more for interactive administration. Useful if you are new to M365 Automation from a CSP Partner perspective.
The Partner Documentation on the Secure App Model is in the Partner Center Powershell section of the Microsoft docs site. This article explains what you need to do as a CSP or CPV (Control Panel Vendor) working to automate Microsoft services.
Other Sources
A few talented individuals interested in automation from a Microsoft CSP partner perspective have invested a lot of time and effort and have thankfully also shared their knowledge with the world.
The Cyberdrain blog has continued research and updates from Kelvin Tegalaar who must have spent many hours of effort researching and solving problems around this topic. We recommend looking at this thread Using the secure app model to connect to Microsoft Partner Resources
CGITS have also published a good article : Connect to delegated Office 365 tenants via PowerShell using the Secure App Model
Paul O’Brien has written several articles providing useful information for anyone wanting to work this stuff out. Checkout his article on Secure App Model Authentication
