13 min read
Mastering Changelog Management with PowerShell
Changelogs keep your software updates clear and organized. Learn the best practices for creating and managing them in...
ScriptRunner Blog
Azure AD, M365 services such as Exchange Online, Teams and others as well as Azure Cloud are increasingly used in many companies. Besides the basic management of users and services, the use of Azure AD accounts as well as targeted searches using the available graph queries are also significant.
ScriptRunner integrates all these capabilities under one roof and supports IT Pros optimally in IT Infrastructure & Operations Automation.
The basic concept (fig. 1) of ScriptRunner follows the principle of “separation of powers” for access to systems and services. Users have roles in ScriptRunner and are granted access rights to functions depending on their role.
ScriptRunner Server handles access to central systems and services completely independently of user access. As an automation platform, it executes PowerShell scripts in the necessary and configured rights context. This prevents direct, uncontrolled access to IT systems and cloud services by users, regardless of their role.
Fig. 1: Basic concept of ScriptRunner and the main components
The main components working together are:
In this context, Active Directory including certificate authorities etc. is a private Identity Provider and provides all resources for the identification of users, devices, systems, services and applications.
In the age of the cloud, “public” identity providers play an increasing role. These are provided by large vendors such as Microsoft, Amazon, Google and others. In addition to these vendors, there are also independent specialty meta-identity providers.
Microsoft’s identity provider for M365 and Azure Cloud is Azure Active Directory (AAD). Simply put, it has the task of identifying users, devices, systems, services and applications and regulating roles, access rights and functions.
As a result, there is no user login and no access to M365 and Azure Cloud services without the AAD. The AAD is therefore a necessary core component for the use and management of Microsoft Cloud services.
Since many companies already operate a private identity provider with their own AD, this can be coupled and synchronized with the AAD. Active Directory Federation Services is most commonly used for this purpose. The advantage: Users can access both internal and cloud services with a synchronized account. In the future, logging in with the AAD account will probably become the norm.
Before ScriptRunner can interact directly with the identity provider AAD, it must be made known to it. Subsequently, the system can be configured so that all users can log in to ScriptRunner Portal with their AAD account. To do this, use the App Registration.
The ScriptRunner Service registration makes the ScriptRunner Service known in the AAD, controls connection access by the service to the AAD, authorizes access by the service to the AAD via certificate and allows read access to the AAD by default. Upon registration, the built-in target “Azure AD Home Tenant” in ScriptRunner Server is automatically configured for AAD access.
In addition, AAD accounts and AAD security groups can now be used within ScriptRunner and assigned to application roles in ScriptRunner.
Note: the configuration allows ScriptRunner Server to access AAD information for configuring application roles in ScriptRunner and for Azure queries. This does not include management access to various services and resources via PowerShell!
ScriptRunner Portal registration switches user login from internal AD to the company’s AAD. Users can now log in using only their AAD user account.
Finally, test the connection from ScriptRunner Server to AAD Endpoint by connecting in PowerShell and displaying the domains.
The AAD login window opens. After the login, a more extensive script processing takes place. At the end, a lengthy enrollment completion notice appears.
You can now check the app registrations in the Azure Portal, under the “App registrations” tab (Fig. 3).
You can also check the Application ID and Thumbprint for certificate-based access in the Built-in Target “Azure AD Home Tenant” in the ScriptRunner Admin App in the main menu “Targets” (Fig. 4).
Fig. 4: In the ScriptRunner Admin App, you can check the tenant ID, application ID, and thumbprint for certificate-based access for the Azure AD target
If you want to continue using classic AD accounts for user login, run the following command:
In this case, the registration is complete.
If you want to use AAD accounts for user login, the following steps must be completed:
In the manifest of the ScriptRunner service, the authentication method is manually switched to the latest method. This means that corresponding access tokens are now used (Fig. 5).
In the ScriptRunner Portal manifest (Fig. 6), the web application is switched to SPA mode
From this point on, when your users access the ScriptRunner Portal or Admin App in their web browser, they will be redirected to logging into Azure AD. After successful authentication, users are now authorized to use ScriptRunner. You can identify logging in using Azure AD Account by the JWT label on the top right of the login name.
Please note that the rights and functions in the ScriptRunner Portal and the ScriptRunner Admin App are managed by the application roles within ScriptRunner.
Direct Azure queries use Microsoft Graph, Azure Resource Graph, or Azure Data Explorer to query the data objects and pass them as JSON objects to the PowerShell scripts.
Scripted queries use a PowerShell script to query the data objects. The result in each case is a data set that is displayed in the Portal and from which the user can select.
A small example shall illustrate this: You want to let the help desk employee select from a list of users from Azure AD with their properties. You assign an Azure Query to the parameter in the main script.
The Azure Query itself uses its home tenant, but can also use other tenant configurations, which is especially interesting for MSPs.
For Azure Queries, there are a few pre-configured elements for simplicity: Users, Groups, Group Members, Member of etc. In the example, we use Users (Figure 10).
As ParameterValue, JSON is suitable because multiple user properties can be queried in one request. As DisplayValue we use the Azure AD property DisplayName.
A test run shows us the list of Users, the parameter Value is coded. Using mouse-over, we can display the actual values in JSON. To use these values in the main script, the Splatting feature is used.
This is done by defining a hash table whose parameters use the same names as in the JSON object. The actual values are automatically assigned and can be further processed in the script.
With the use of pattern filters, you can specifically restrict the data query. The example in Figure 11 queries all groups that are “Mail enabled”.
Cascading of Azure queries is also possible. This way, use cases like the following can be implemented: A help desk employee queries the AAD groups and selects one. Then, all members of that group are displayed, and they can select one or more members. The members are removed from the group via PowerShell script.
Azure queries can also directly target Microsoft Graph. Microsoft Graph Explorer can be used to create and test Graph queries. The Graph queries tested there can be used 1:1 in ScriptRunner by copying the created Graph URI into the ScriptRunner Azure query (Fig. 12).
GET queries do not have a JSON body. POST queries on the other hand, require a JSON body with the parameters to be queried.
Attention when using POST: The service principal of the registered “ScriptRunner Service App” is by default set to read only. You can change this setting in the Azure Portal on the app directly in the API permissions.
Another variant is the direct use of Azure Resource queries. This makes it possible to access all Azure Cloud resources and manage them via PowerShell. The queries are coded using Kusto.
ScriptRunner users can now primarily use their Azure AD account to log in. Role capabilities can be controlled with Azure AD security groups.
Azure Queries in ScriptRunner are a powerful tool to query objects and resources from Azure AD, Azure Cloud and M365 and use the data in your own PowerShell scripts.
Jan 28, 2025 by Jeffery Hicks
Changelogs keep your software updates clear and organized. Learn the best practices for creating and managing them in...
Dec 19, 2024 by Jeffery Hicks
Boost IT efficiency with Winget and PowerShell! Learn how to automate app installations, updates, and management...
Dec 17, 2024 by Sonny Jamwal
Extend PowerShell with .NET for powerful event automation. Learn how to monitor and handle system events like a pro!...
Frank Kresse is Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.