application assignments azure

The challenge

Preferably, role assignments are automated through privileged release pipelines.  The two PowerShell commands that can be used to automate this – New-AzureADServiceAppRoleAssignment and New-AzureADUserAppRoleAssignment – are not easy to use, as it is not always clear what the exact Ids are that you have to provide.

The solution

That’s why I prefer to automate this based on display names and let a script take care of fetching the required Ids. Lately, I have developed such a script to assign Azure AD application roles to users and applications.  Hereby, I share it with the community.  The script can be found in this gist .

Config file

The script is driven by a simple config file , that contains a JSON array of role assignments:

• description : free text field that describes the role assignment
• client_type : “user” or “application”
• client_principal_name:  the users’ UPN ([email protected]) or the display name of the service principal (enterprise application)
• server_app_registration_name : the display name of the app registration to which you want to grant the client access
• role_name the display name of the application role you want to assign to the configured client

You can use the script like this:

• Download the script and the config file.
• Update the config files to your needs
• Trigger the script via PowerShell

If you are interested, this is how the script looks like:

I hope that this script helps you to accelerate your security automation.

Cheers Toon

UPCOMING TRAININGS

CHECK OUT OUR TRAININGS

Azure Integration Services

Azure migration.

• Azure Governance

Azure Security

Azure foundations, recent posts.

• Looking back at INTEGRATE 2024
• Azure Service Bus vs Event Grid Pull Delivery
• Trying the new Microsoft Applied Skills
• Finally a correct way to configure RBAC for DevOps agents!
• What do the new API Management v2 tiers mean for you?
• Announcement
• API Management
• Architecture
• Azure App Service
• Azure Data Factory
• Azure DevOps
• Azure Event Grid
• Azure Functions
• Azure Kubernetes Service
• Azure Policy
• Azure Resource Graph
• Azure Resource Manager
• Azure Service Bus
• Azure Stream Analytics
• BizTalk Server
• Container Apps
• Geen categorie
• Home Automation
• Microsoft Learn
• Service Bus

MEET THE YOUR AZURE COACH TEAM

Your Azure Coach is specialized in organizing Azure trainings that are infused with real-life experience. All our coaches are active consultants, who are very passionate and who love to share their Azure expertise with you.

Toon Vanhoutte

Azure integration services & serverless.

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

What's lurking in your Microsoft Graph app role assignments?

Gain insights for security and compliance reasons by reporting on all service principals in entra id (former azure ad) having microsoft graph app role assignments..

I’ve earlier blogged about Building a comprehensive report on admin role assignments in Powershell , this time we’ll look at app role assignments instead.

Application permissions, often called app role assignments in Entra ID (former Azure AD), are permission sets that an app, service principal or managed identity can be assigned in another resource app, and that app’s identity can then access and utilize the resource app’s API without a signed-in user present.

Service principals by default have no access to enumerate other objects in Entra ID (former Azure AD). An example, if a service principal used in automated workflows requires read access to all user objects in Entra ID, it will need to be assigned the app role User.Read.All application permission (app role) in Microsoft Graph, consented by an admin, to be able to query Graph for any or all users.

The Microsoft Graph API is covering endpoints for most of Entra ID and Microsoft 365 services, and it has a wide range of app roles for providing specific API access. And let’s not forget the old and deprecated Azure AD Graph API which has not yet been fully been sunset. It’s critical for compliance and security hygiene of the tenant to audit and monitor app role assignments for these resources especially. Do note that there are a lot of other APIs with their own sets of app roles in Entra ID, some examples below, but for this blog post I will focus on Microsoft Graph and Azure AD Graph.

Some app roles can be abused for privilege escalation all the way up to Global Admin , as Andy Robbins (co-creator of BloodHound) points out in this blog post . A Global Admin can do whatever it wants in Entra ID, and it can also elevate its access for all Azure subscriptions in the tenant with the flip of a switch . This just proves how critical it is to have full control on any high-privilege app roles.

With these things in mind, let’s look at how to extract all app role assignments for Microsoft Graph and Azure AD Graph, including other valuable information for each service principal, using Powershell and the Graph Powershell SDK v2 module.

Identify highly privileged app roles

Required scopes in graph powershell sdk, app roles and assignments.

• Owner organizations and sign-in activities

Compiling the report

Full script on github.

I wish there was a list of all Microsoft Graph app roles with tiering information, identifying how privileged each app role is. Since there are none I’ve added some of the app roles that I know are highly privileged - they will be specifically flagged as Tier 0 in the report. There are many other privileged app roles, but let’s start with these as abusing them can lead to Global Admin access. You can easily add other roles and other tiers, depending on what you want to report on.

Update 2023-08-17 @ 11:00 (CEST): Removed ‘Application.ReadWrite.OwnedBy’ from the list as this permission isn’t Tier 0 at all: “Allows the app to create other applications, and fully manage those applications (read, update, update application secrets and delete), without a signed-in user. It cannot update any apps that it is not an owner of.”

When connecting to Microsoft Graph with the Graph Powershell SDK v2 module, the following delegated scopes are required:

• Application.Read.All (to enumerate service principals)
• AuditLog.Read.All (to pull out service principal sign-in activity)
• CrossTenantInformation.ReadBasic.All (to query app owner tenant information for 3.party apps)

Other than that, no special privileges are necessary for the user account connecting to Microsoft Graph - only read-access is used.

Extracting data

Now let’s start extracting the data we need from Microsoft Graph to create the report.

First we are querying for Microsoft Graph and Azure AD Graph’s service principal objects in the tenant - by filtering on their well-known Application IDs ( 00000003-0000-0000-c000-000000000000 and 00000002-0000-0000-c000-000000000000 ). Once the service principals have been found, we are extracting all app roles and app role assignments, creating hashtable for quick lookups, and lastly joining the app role assignments for both service principals.

We can now process each of the app role assignments in $joinedAppRolesAssignedTo to create a report, while enriching the data set even further.

Service principals, owner organizations and sign-in activities

The app role assignments in $joinedAppRolesAssignedTo does not contain all the information we need about the assigned service principals. So we will query Graph for the service principal objects, the owner organizations for multi-tenant apps, and sign-in activities. To optimize the script we’re utilizing cache and only querying each object one time even tho it has multiple app role assignments.

Note that looking up the app owner organization (for multi-tenant apps) uses Invoke-MgGraphRequest with a URI since I haven’t found a cmdlet for this in Graph Powershell SDK yet.

Let’s pull the sign-in activities for the service principals. This gives us information about the most recent service principal sign-in and delegated (user) sign-in, which can help us identify stale apps. Note that this newly released reporting endpoint in Graph is still in beta, which is why we need to utilize the Get-MgBetaReportServicePrincipalSignInActivity cmdlet.

And finally we can generate a PSCustomObject with the data we need for the report.

This will generate a list of all the app role assignments for Microsoft Graph and Azure AD Graph, enriched with additional data for the assigned service principals and any configured tier. Here’s an example.

I like to explain how the Powershell scripts I publish works, and this blog post does just that. I have also published the full Powershell script on GitHub so you don’t have to copy/paste from this page, feel free to check it out.

Thanks for reading!

Be sure to provide any feedback on X (former Twitter) or LinkedIn .

• ← Previous Post

A Cloud Guy

Azure, M365, AWS and IT in general

Azure AD – Assign Groups and Users to an application

Azure AD allows granting access to resources by providing access rights to a single user or to an entire Azure AD group. Using groups let the application or the resource owner to assign a set of permissions to all the members of a group. Management rights can be granted to other roles, like example., Helpdesk administrators to add or remove members from the group.

When a group is assigned to an application, only users in the group will have access. Also, if the application exposes role, roles can also be assigned to groups or users.

When I was working on integrating Salesforce with Azure AD for SSO, I needed to assign groups to the roles that Salesforce exposed and I figured I’d document the process I went though here.

Table of Contents

Bulk create Azure AD groups

This section describes how to create multiple groups in Azure AD. This is not needed if your organization already has groups created.

Use below script to create multiple Azure AD groups that are listed in a csv file,

csv file input,

PowerShell output,

Assign Groups and Users to an app using PowerShell

Assigning groups or users can be done from the Azure AD admin portal by clicking on the Users and groups tab in the application which you are granting access to.

My plan here is to create Azure AD groups that corresponds to the name of the role that Salesforce exposes and then add users to those groups which provides them with appropriate access to the application.

Determine the roles available for the application

To determine the roles that the application exposes, use the cmdlet below.

Assign Groups to Roles in Application

Use below script to assign the application’s roles to groups. If you notice the csv file, I’m using the groups created in the previous step to the roles. This way, it is easier to manage. The New-AzureADGroupAppRoleAssignment cmdlet can be used to achieve this.

This below is how the application looks like in the Azure AD admin portal after running the above script,

Assign Users to Roles in Application

Use below script to assign the application’s roles to users. This can be achieved using the New-AzureADUserAppRoleAssignment cmdlet. Use the below script,

Get all role assignments to an application using PowerShell

Get-AzureADServiceAppRoleAssignment cmdlet can be used to determine all role assignments to an application,

Remove All Groups and Users assigned to an application

To remove all assigned groups and users from an application, Remove-AzureADServiceAppRoleAssignment cmdlet can be used,

It should go without saying that removing all permissions will disable user’s access to the application. Don’t try this as a first step in a production environment, unless you are absolutely sure of it.

Thank you for stopping by.✌

1 thought on “Azure AD – Assign Groups and Users to an application”

• Pingback: Implement Azure AD SSO integration with Salesforce – A Cloud Guy

Leave a Comment Cancel reply

Save my name, email, and website in this browser for the next time I comment.

How to integrate Microsoft Entra External ID and Cerbos for authentication and authorization

Martin Gjoshevski

Alex Olivier

June 24th, 2024 0 4

This blog post has been co-authored by Martin Gjoshevski, Senior Customer Engineer at Microsoft and Alex Olivier, Chief Product Officer from Cerbos, a Microsoft Partner.

In this blog post, part two of a three-part series, we look at how you can use Microsoft Entra External ID and Cerbos to decouple authentication and authorization.

In part one , we looked at the role that authentication and authorization play and the benefits and considerations you need to take into account when designing systems. In this blog post, we are going to see how you can build a web application with decoupled authentication and authorization using Microsoft Entra External ID and Cerbos.

What you’ll build in this tutorial

In this tutorial, you are going to build a web application that uses Microsoft Entra External ID for user authentication, and leverages Cerbos for implementing fine-grained authorization. Our web application lets authenticated users create and update posts.

We have two roles in our application: User and Admin. These roles have different capabilities, as shown in the table below:

Table 1: Roles and Actions

Architecture

Our application relies on Microsoft Entra to authenticate users. All user information and data is stored in Microsoft Entra External ID, which enables you to leverage powerful CIAM features such as self-service registration, customized sign-in experiences, and customer account management. External ID builds upon the proven platform of Microsoft Entra, so you also get to reap the benefits of the platform, like improved security, compliance, and scalability.

The following diagram illustrates the design of the application:

Once users are authenticated, our application leverages Cerbos to evaluate authorization policies and allow only authorized users to perform specific actions.

Code sample

Explore the code sample and scripts to implement this application.

Prerequisites

Before getting started, make sure you have the following prerequisites:

• Node.js  installed on your machine.
• A code editor such as  Visual Studio Code .
• Docker , for running the  Cerbos Policy Decision Point (PDP) .
• An external tenant, if you don’t already have one, you can  sign up for a free trial  or  create a tenant with external configuration in the Microsoft Entra admin center .
• (Optional)  PowerShell  – You can either use the Microsoft Entra admin center to configure the app, or you can automate this using the PowerShell script in the GitHub repo, which will create and configure all the required resources in Microsoft Entra.

How to use Microsoft Entra External ID to add authentication to your external-facing apps

To enable your application to sign in users with Microsoft Entra, you must register your application. Creating an  app registration  establishes a trust relationship between the application and Microsoft Entra.

To create the app registration and apply the necessary configuration in Microsoft Entra, please choose one of the following options:

• A step-by-step guide using the Microsoft Entra admin center, can be found here .
• A PowerShell script, which will create and configure all the required resources in Microsoft Entra, can be found here .

After creating the app registration, creating and associating a user flow, and configuring the app roles, please proceed with the next steps.

Integrate your application with Microsoft Entra External ID using MSAL

If you haven’t cloned the GitHub repository, please do so. The source code for the application is in the App folder.

For a quick start, replace the values in the .env file .

• In your code editor, open the .env file in the App directory.
• TENANT_SUBDOMAIN  - replace it with the Directory (tenant) subdomain. For example, if your tenant’s primary domain is contoso.ciamlogin.com, use contoso. If you don’t have your tenant name, learn how to  read your tenant details .
• CLIENT_ID  - replace it with the Application (client) ID of the app you registered earlier.
• CLIENT_SECRET  - replace it with the app secret value you copied earlier.

Explore the implementation

We use the Microsoft Authentication Library (MSAL), which enables developers to acquire security tokens from the Microsoft identity platform to authenticate users and access secured web APIs.

MSAL supports a large set of platforms and frameworks. You can read more here .

The core integration using MSAL in our application can be found in the App/auth/AuthProvider.js file.

Note: For a detailed walkthrough on how to integrate an application with External ID using the Node.js MSAL library, please check our documentation which takes you through the process step-by-step.

Now, let’s leverage Cerbos to add authorization to the application.

Add Authorization to your application using Cerbos

Fine-grained authorization involves defining and enforcing policies that specify who can access what resources, under which conditions. The implementation process is broken into two separate stages— policy definition and policy enforcement .

Note: At this point, after having cloned the repo in following the instructions above, you should have all policies already defined. The next step you need to perform is to deploy a policy decision point (PDP) .

Policy Definition

When defining an authorization policy with Cerbos, you would begin by specifying the different resource types, such as a Post, Comment, Order, etc., and the actions which can be performed, such as create, read, update, delete, comment, flag, etc.

Then, for each of these actions, you would define under which condition they should be allowed or denied. This could be as simple as checking if a user has a role (performing RBAC), or more fine-grained where individual attributes of a resource or principal are checked.

In our sample application, we have defined one policy which can be found in the Cerbos/policies folder.

The posts.yaml file is a policy that represents a basic Post resource which has the actions of create, read, update, and delete. Our policy states:

• The read action can be performed by any user with the Posts.Admin or Posts.User roles.
• The create action can be performed by any user with the Posts.User role.
• The update or delete actions can be performed by any user with the Posts.Admin role for any article.
• The update or delete actions can be performed by any user with the Posts.Users role, ONLY if the authorId of the post is equal to the ID of the user making the request.

Note: With Cerbos, you can also write unit tests around these policies to test them in isolation.

Deploy a policy decision point (PDP)

Once a policy is defined, the next step is to deploy a policy decision point local to your application and then make authorization checks against it.

• To run the Cerbos PDP instance inside a docker locally, run the start.sh script located in the Cerbos directory.

Integrate the Cerbos SDK

To talk to the PDP from your application, you need to implement the SDK (or call the API directly). Our example application uses Node.js, but Cerbos publishes SDKs for most common languages.

The SDKs all work the same way by creating a client, pointing it to the PDP running in your infrastructure, and then issuing check calls against it.

• In the Node.js application, run “npm install @cerbos/grpc” to install the gRPC client (or @cerbos/http for HTTP) and import it into your application code:

Now, checks to Cerbos can be made from any part of the application.

Navigate to App/routes/posts.js , to see the example integration.

Make authorization checks

In our application, when a request makes it down to the request handler, we essentially know three things:

• Who is making the request (the principal – as it could be a user or a service account)
• The operation they are trying to perform (the action)
• The object they are performing the action on (the resource)

These are the three inputs to Cerbos which are required to make an authorization check against the policies.

Starting with the principal, in our application once a user is authenticated against Microsoft Entra, the token returned contains the user information which will be passed on to Cerbos as the principal object.

Unpacking an example token issued by Microsoft Entra, see that the user ID, name, roles, and other metadata is returned:

Taking the contents of this token, the fields map into the principal object in the request to Cerbos.

For the resource, based on the request, we need to query it out of the database and construct the resource object. In our demo application, the resource we are interacting with is a Post which we query out based on the ID in the request and structure the resource object as shown below:

The final piece is the action, which is known based on the request, e.g. a POST request will be the ‘create’ action, a GET will be a ‘read’ action, etc. This is open to be defined based on your application and doesn’t need to be tied to HTTP verbs.

Now, with these 3 bits of information, the principal, resource, and action, all that’s needed is a simple SDK call to check the permissions. The SDK makes a call out to the local PDP, the policies are evaluated, and what comes back is a simple boolean—allowed or denied:

Policy Evolution

With your application set up to carry out all authorization logic via calls to Cerbos, whenever the logic needs to change, be it to add a new role, change a condition, or something else, this only needs to be done once in your policy files. Once the change is rolled out, your application will handle requests based on the new logic without requiring a single code change or deployment.

Test the application

After configuring the Node.js web application and starting the Cerbos PDP, you can start the application and test it.

• Open a console window and navigate to the directory that contains the Node.js sample app. Install the dependencies and start the application.
• Open your browser and navigate to http://localhost:3000 . You should see a page like the screenshot below:

• Once the page has loaded, click Sign in . You will be prompted to sign in.

• On the sign-in page, enter your email address, click Next , enter your password, and then click Sign in . If you don’t have an account, you can click on the No account? Create one link to start the sign-up flow.
• If you choose the sign-up option, you will need to provide your email, one-time passcode, new password, and other account details to complete the sign-up flow.
• After signing in, you will be able to perform all of the regular user actions, Create, Edit (Publish), and Delete (only your own Posts, described in the “ Table 1: Roles and Actions ” above).

Assign Admin role

If you want to switch your role and get admin permissions, you need to change the role of your user by follow these steps:

• Sign in to the  Microsoft Entra admin center  as at least a  Cloud Application Administrator .
• Browse to Identity > Applications > Enterprise applications.
• Select  All applications  to view a list of all your applications and select the application that you created (such as  ciam-client-app ). If your application doesn’t appear in the list, use the filters at the top of the  All applications  list to restrict the list, or scroll down the list to locate your application.
• Select the application in which you want to assign users or security groups to roles.
• Under  Manage , select  Users and groups .
• Select  Add user  to open the  Add Assignment  pane.
• Select Users and groups  from the  Add Assignment  pane. A list of users and security groups should be displayed. You can search for a certain user or group and select multiple users and groups that appear in the list.
• Once you’ve selected users and groups, click Select to proceed.
• Click  Select a role  in the  Add assignment  pane. All the roles that you’ve defined for the application should be displayed. Choose  Admin .
• Choose a role and click  Select .
• Click  Assign  to finish.

Confirm that the users and groups you added appear in the  Users and groups  list.

After following all the steps above, you should see the Admin role assigned in the ID token.

This will allow you to perform the admin user actions described in the “ Table 1: Roles and Actions ”.

Recap, and what’s coming in part three

In this blog post, we walked you through the process of integrating Microsoft Entra External ID and Cerbos, looked at how External ID can be used to add sign in capabilities to your application, and explored how Cerbos enables applications to define and enforce fine-grained authorization policies.

We hope you enjoyed working through this tutorial. We encourage you to share your insights with the community to help others out. Or ask a question if you ran into any pain points along the way.

In part 3, we are going to dive deeper into the advanced capabilities and features that External ID and Cerbos offer for managing SaaS users.

To learn more or test out other features in the Microsoft Entra portfolio, visit our developer center . Sign up for email updates on the Identity blog for more insights and to keep up with the latest on all things Identity, and follow us on  YouTube for video overviews, tutorials, and deep dives.

Leave a comment Cancel reply

Log in to start the discussion.

Insert/edit link

Enter the destination URL

Or link to existing content

Entra ID Application Key Concepts & Background

Most of the content here is also represented at https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added . Because everyone learns information slightly differently, you may find one or the other easier to understand.

Terminology

Microsoft has a few terms which can be a bit confusing if you don’t understand what they mean:

• Entra ID Application : an identity intended to be used by an application with a bit of configuration about how that identity can be used. The fact that Azure is in the name does not designate where the software lives but that the application will only trust sign on tokens issued by Entra ID. The fact that application is in the name does not imply that this is a software platform for development or hosting.
• Application object : This is the single, definitive object with configuration details, and is only present in one Entra ID tenant. Think of it as the template by which many instances of this application might be created from.
• Service Principal object : This is a working instance of the application. This object will contain operational configuration information specific to this instance of the application and is linked to the application object.
• Enterprise application : This is a location in the Azure Portal where you can manage service principals. It is also the only location from which pre-integrated 3rd party SaaS applications in the Entra ID application gallery can be created (the application object does not exist in the UW tenant). The creation of service principals from this location can only be done by UW-IT.
• App registration : This is a location in the Azure Portal, where you can create and manage application objects (in the UW tenant). Anyone with a UW Microsoft account can create an application object, and a service principal is automatically created at the same time.

Entra ID Application Concepts

• There are many meanings of the word “application.” When we talk about an Entra ID Application, we are talking about something very specific. An Entra ID Application is a digital identity and some associated configuration which informs Entra ID about how to treat software which uses that digital identity. The software itself may be running anywhere, on any platform, written in any language. To be more specific, if software needs to request Entra ID logon tokens or consume Entra ID logon tokens, then it must be an Entra ID application. The software might have other digital identities it uses, but that topic isn’t covered here.
• An object of type application. This is the core digital identity with the basic required configuration details, and is only present in the Entra ID application’s home tenant.
• One or more objects of type service principal. This object will be present in each tenant which has an instantiation of the Entra ID application, except the Entra ID application’s home tenant. This object will have the specific role assignments and user consent permissions granted for that tenant. Note: An Entra ID application’s instantiation in a given tenant is the service principal object–but that service principal references the “primary” Entra ID object of type application that lives in one and only one tenant. You can read more about these Entra ID objects here .
• User consent. The end user is presented with a list of permissions the Entra ID application would like, if you agree to grant them. If the user does not consent, then they can not use the application.
• Admin consent. The tenant admin is presented with a list of permissions the Entra ID application would like. Admin consent is required if the required application permissions are broader in scope than what an individual user can grant for themselves. If admin consent is required, then no user can use the application until admin consent. Optionally a tenant admin can provide the user consent decision on behalf of all users. In this case, the end user never sees the user consent dialog.
• An Entra ID application instance will record all consent permissions granted within that tenant related to itself (on the service principal object).
• Application permissions are those which are used solely by the application identity itself. You use these type of permissions for a non-interactive application that is doing work without a human interacting with that application. Application permissions require admin consent because there is no user consent experience by design.
• Delegated permissions are those which require a user to interactively sign into the application. The user consents to the permissions, which authorizes the application to act on behalf of the user with the permissions which that user has consented to. If an admin consents to delegated permissions then users don’t consent.
• Entra ID Applications come in two fundamental flavors–confidential clients and public clients. Confidential clients need to authenticate as themselves, so must have credentials–these are typically web apps or code used to programmatically leverage the API of another Entra ID application. Public clients do not need to authenticate as themselves and typically represent native clients broadly distributed on many devices. So the key differentiator here is whether the application needs to get a logon token for itself–and that is usually dependent on whether it needs to access another Entra ID application. Most Entra ID Apps will be confidential clients. Note: public clients do not have a service principal in each tenant–they are only ever present in the developer’s tenant. If you’d like to explore public clients further, you might review the ‘Native Application to Web API’ section of https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ .
• If an Entra ID Application needs a credential, then it has two options–a password or a cert. See more here .
• An Entra ID application may define whether it is available to other tenants.
• An Entra ID application must define what permissions to other Entra ID applications it needs. To only authenticate other users, you do not need any permission, but if you need to include name or other basic data in the user experience, then you will likely need User.Read, i.e. the ability to read the profile of an Entra ID user who has logged into your application. You can read more about permission scopes, including the permission scopes that Entra ID itself has available at https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes .
• An Entra ID application may define permission scopes that can be granted to other Entra ID applications. This is optional.
• Each app may define roles which users can be assigned to. This is optional. Each Entra ID application instance will record any role assignments.
• Each Entra ID application instance may require assignment of users or groups to be able to access to the app. This is optional. Note that if assignment is required, a basic role is created even if the application doesn’t define any roles.
• Each app can have owners defined, but they are not represented in the roles property. Application Owners have a broad set of permissions.
• An Entra ID application records the URIs that tokens it requests are issued to. A given Entra ID application may have many valid URIs. You might imagine using the same Entra ID application for a production, pre-production, and development instance of the code behind your Entra ID application, each with their own distinct URI. Or you can create a separate Entra ID application for production, pre-production, and development purposes.

Sean Bulger

Speaker, Blogger, Consulting Engineer. Modern Endpoint Management enthusiast.

• Southeast Michigan, USA
• Custom Social Profile Link

Adding Filters to application assignments with PowerShell and Microsoft Graph

January 19, 2022 8 minute read

Wait a minute - this post isn’t the regularly scheduled post in my current series on automation in Microsoft Endpoint Manager with Microsoft Graph and the Admin Service - it’s cool, but where do I find the rest of that series? You can find the entire series here.

I know you were expecting a post on the building blocks needed to automate tasks in Azure, but sometimes I get distracted by shiny objects. I promise that post is on its way, but this was too good to pass up! The other day, John Marcum (@MEM_MVP) , asked a question on Twitter .

Does anyone know of an easy way to add filters to all active #MSIntune app deployments? @IntuneSuppTeam — John Marcum (@MEM_MVP) January 14, 2022

Most people may have simply passed on without giving it a second thought. Not me. It has been running through my head for the last few days, and I decided to take it as a personal challenge. This is an excellent practical application of my current blog series , so I wanted to take on the challenge to see if I could do it.

(Spoiler alert: Yes, I did it! That’s why you’re reading this post!)

The Challenge

To accomplish this task, we would need to be able to return a list of all the filters we have configured in Intune, a list of applications, and a list of application assignments. It seems like it should be relatively easy to update a simple value, but this one came with a few challenges:

• Only assigned apps can have filters applied, so we don’t want to return all devices
• Filters are tied to device types, so we only want to make sure we select the right filter for the applications we want to update
• There’s always an exception. The original ask was to apply a filter to all applications. I wanted to make sure we could select only the applications we wanted to update.
• It took me a while to realize this, but the body needed to update the assignments is complex. We would need to be able to dynamically create it based on the application type.
• We will need to pass in a parameter that sets the filter to either include or exclude devices

The Solution

Ultimately, updating a single application assignment requires four total API calls:

• A GET request that returns all filters created in Intune
• A GET request that returns all applications with assignments
• A GET request that returns all assignments on an application
• A POST request that delivers a payload to update application assignments

The Microsoft Authentication Library module (MSAL.ps) is required for the script to run. When I am running PowerShell scripts against Microsoft Graph, I always use some form of authentication with MSAL. In this case, I am using a Client Secret from an Azure App Registration. You can read more about using the MSAL library in PowerShell here.

The only required parameter to run the script is the filter mode. When running the script, use the -FilterMode parameter to set a value of either include or exclude .

To limit the number of required parameters and allow for an administrator to target only specific applications, I elected to pipe the results of the first two Get requests to Out-GridView . For those of you who aren’t familiar, Out-GridView displays an interactive box that allows you to select one or multiple objects from a list. Using the -PassThru parameter will pass the selected object back to a variable in your script.

I did elect not to prompt the user for input when selecting assignments on a specific application. The original ask was to be able to update all applications, so I didn’t want to prompt a user dozens of times to select specific assignments on different applications.

The heart of the script is the Invoke-MSGraphCall function that I created in my earlier blog post on working with JSON and splatting in PowerShell . Each time I call the function, I pass in the specific parameters needed for that API call.

The full text of this function is:

The first API call we make is to return the assignment filters we have configured in Endpoint Manager. We must use a filter type that matches the application whose assignments we wish to filter, so be careful to select the right filter for your device type.

The code to complete this task is as follows:

This will return the following output:

Select a filter and click OK to continue. This will set the value of $FilterId to the selected filter.

Next, we need to return a list of all applications with assignments. I accomplished that with this code:

This script block will return the following box. This supports multiple applications. Select one or more applications and click OK.

The rest of the script will run without any user input. Because of the ForEach loop, we need to clear the variables in case it had been previously run. Not all applications have the same properties and leaving the values from a previous run may cause the script to fail. We then iterate through each application in the list and return their assignments.

The next block of code will run through each individual assignment on a device. This will parse the results for the Target and Settings of each assignment. The target contains information about the group the assignment is being applied to and contains the information about any filters being applied. We are updated the filter values on the target. Settings contains specific information about the assignment. In this version of the script, we aren’t changing any settings. Both the target and the settings have to included in the JSON payload. Both the target and settings could vary by application type, so we need to parse the individual objects to make sure we include the correct properties in the correct format. We need to convert the hash table to JSON, and the JSON needs to have sufficient depth to account for different application and assignment types.

Finally, we make a POST request to update the application assignments. We pass in the JSON payload in the -body parameter.

If we check one of the applications we just updated, we can see that the filter has been applied.

The full script can be found in my GitHub repository.

Sure, this post wasn’t intended as part of my series on automation with Microsoft Graph, but it’s a natural fit! I’m going to include it in the list because it deserves to be here!

Follow the full series below:

• Everything I wanted to know about APIs but was afraid to ask
• Connecting to Microsoft Graph with PowerShell
• Troubleshooting Microsoft Graph App Registration Errors
• Defining a script and finding the Microsoft Graph Calls
• Splatting with Invoke-RestMethod in PowerShell
• Updating Device Management name in PowerShell with Microsoft Graph
• Surprise Post:Adding Filters to application assignments with PowerShell and Microsoft Graph
• Working with Azure Key Vault in PowerShell
• Creating an Azure Automation Account
• Setting up a Hybrid Worker on an Azure Arc Enabled Server
• Connecting an Azure Automation Account to the Configuration Manager AdminService
• Running an Azure Automation runbook to update MEMCM Primary User
• Using Power Automate to update MEMCM Device based on Intune User

You may also enjoy

Migrating AD Domain Joined Computer to Azure AD Cloud only join

November 5, 2022 12 minute read

Over the years, a lot of people have been looking for a solution to migrate on-premises Active Directory joined devices to Azure Active Directory cloud-only ...

Dynamically Update Primary Users on Intune Managed Devices

November 3, 2022 12 minute read

Intune is great at managing devices, especially when there is a primary user assigned. In most common use cases, the primary user is automatically assigned, ...

MMS Intune Management PowerApp Demo Part 3: Adding the buttons, gallery, and completing the app

June 9, 2022 9 minute read

In today’s post I will complete the app by adding a gallery and two buttons. Those buttons will call the Power Automate workflows that call Microsoft Graph ...

MMS Intune Management PowerApp Demo Part 2: Creating the PowerApp user lookup controls

May 25, 2022 8 minute read

This is a relatively simple app, but I will try to capture any of the details you may need to build your own copy. This app is designed to be a jumping off p...

• We offer customized cybersecurity solutions in security, identity & access, compliance, and mobility and DaaS to help you stay ahead of an ever-evolving threat landscape.
• GET STARTED WITH OUR AD HEALTH CHECK

• In Sync: Proper Time Configuration in AD
• Explore our resources for advice on boosting your organization's security.
• Stay up-to-date — read our experts' unique takes on trends in cybersecurity.

• Improving Entra ID B2B User Management with Cross-Tenant Synchronization
• Identity & Access
• Mobility & DaaS
• WHY WORK HERE
• We solve tough problems for organizations big and small. As a trusted partner to international brands, small firms, and colleges/universities, we need top-notch people to do what we do.

• Our experts are always ready to discuss your needs – whatever stage you’re at – and with no obligation.
• AD HEALTH CHECK
• We enhance your AD and improve its security with our holistic health assessment.

Connect with a Ravenswood expert using the form below.

How to Effectively Manage Microsoft Intune Application Assignments with PowerShell and the Microsoft Graph API

• May 6, 2021
• Blog , Security

Tony Brzoskowski

In large-scale Microsoft Intune deployments, you’ll typically find both production and development tenants. For effective application testing, you’ll need to assign your applications to test groups of devices or users. Performing this process manually can be time-consuming and repetitive. To simplify the mass addition of a group for application deployment, you can leverage the  Intune PowerShell SDK .  

Connecting to Intune PowerShell  

Download the  Intune PowerShell SDK  and follow the configuration steps in the “Getting started” section of the documentation. As of this writing, high-level steps for configuration are: 

• Install the Microsoft.Graph.Intune module. The module can be installed in a few different ways, but the easiest method is from the PowerShell Gallery via:
• Perform admin consent for the module. After installation, you’ll be prompted to consent to the tools to access your Azure and Intune environments. You’ll need an account with the appropriate roles to approve consent. 
• Run the Connect-MSGraph command. When connecting, you’ll be prompted for Intune administrator credentials. 

Scripting Application Assignments 

Next, you’ll need to retrieve a list of all Intune applications. If Win32 applications are part of your desired pool, you’ll need to connect to the MSGraph beta schema: 

To retrieve all applications: 

Next, define the group you want to apply: 

Once you have all the applications, you need to limit the scope of which applications you’ll be updating. In the lab environment, applications are assigned to groups of collections. 

The following code searches for a known group ID that will be the target modification pool. If you want to deploy to all applications, you can remove the  if  statement from the snippet. 

Similarly, if you need to remove a group from a set of applications, you can find the group that needs to be removed: 

Next, cycle through all the applications and remove that group: 

Note that the new group will retain the same “intent” as the referenced group (e.g., Required). 

Automate More Tasks 

The Microsoft Graph API and the Intune PowerShell SDK can be daunting to navigate. The number of tasks you can complete with the Graph API is growing almost daily. Managing application assignments with the Graph API is just one example. The Graph API is also a foundation for automating more tasks with Intune and Microsoft 365.  

Need help with your Intune deployment or using the Microsoft Graph API?  Contact  the experts at Ravenswood Technology today! 

[RELEVANT BLOG CONTENT]

Advanced Data Loss Prevention: An Overview of Insider Risk Management  

In today’s digital age, the complexity and connectivity of organizational ecosystems expose them to a myriad of security threats, with insider risks standing out as

Azure Automation and SQL Server

Microsoft Azure Automation is a service that is designed to automate operational tasks across Azure and on-premises environments. It provides a way to create, test,

Hiding Confidential Information in Active Directory, Part 1: Active Directory Confidentiality Bit 

Active Directory (AD) is widely adopted by many companies as the central identity and access management platform. It provides authentication and authorization services and includes

Highly Available, Secure, and Convenient: Leveraging Azure Blob Storage for your PKI Needs, Part 1

For as long as public key infrastructure (PKI) has existed, it has relied on certificate revocation lists (CRLs) and authority information access (AIA). CRLs are

Three Reasons to Use Azure Automation to Run Your Scripts 

Azure Automation is a cloud-based service that can help you run scripts; configure, update, and manage operating systems; and manage your IT asset inventory. This

An Introduction to Protected Actions in Conditional Access

The Microsoft Azure portal includes a subset of permissions called protected actions, which can be used to manage Conditional Access (CA) policies and cross-tenant access

Windows 365 Boot and Switch: Building a Solid Foundation

In the ever-evolving landscape of digital workspace solutions, Windows 365 emerges as a cloud-based PC deployment solution tailored for organizations seeking enhanced security and centralized

6 Tips to Harden Your Windows LAPS Deployment

In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important

Leave a Comment Cancel Reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Ravenswood Technology Group is based in Chicago, IL but with customers around the world. We help companies, universities, and other organizations with less than 100 employees to over 500,000 build secure, hybrid infrastructure that enable their users to work from anywhere. 

[What we do]

• Identity & Access

[Recent Blog Posts]

[Expertise]

• Active Directory Health Check
• Azure Government & Office 365 Government – GCC High
• Microsoft Entra ID
• Microsoft Sentinel

[Get in Touch]

© Ravenswood Technology Group, LLC

Good Workaround!

Full IGA using Azure AD – Getting app role assignments using PowerShell

In this post I will quickly demo how to use PowerShell to get app role assignments for all application using the Microsoft Graph.

You should have followed my previous post in order to have created an application, added some appRoles to the manifest and granted access to the Graph.

Let’s recap the important parts:

1 – Create an enterprise application in Azure AD

2 – Go to “app registrations”, find the app and add appRoles to the manifest

The following are provided by default, disable those and add some custom ones. See the below example roles.

3 – Go back to enterprise applications and assign users some roles

4 – Grant access to the required Graph resources

Go to app registrations, find the application and go to “API permissions”. Click “Add a permission”:

Select the Microsoft Graph:

Choose Application permissions, as we are doing things without a user context:

Add “User.Read.All” and “Group.Read.All” and click save.

You will see that the added permissions now have “Not granted for <Organization>” as status. Click “Grant admin consent for <Organization>” in order to enable these new permissions:

This is what it should look like:

5 – Request data with PowerShell

First, generate a secret under app registrations in Azure AD. This is the $secret variable in the below PowerShells.

Go the enterprise application and copy the “Application ID” – this is the $clientid variable in the below PowerShells.

Copy “Object ID” – this is the $servicePrincipalId variable in the below PowerShells.

The $tenant variable can be either any custom domain registered in the tenant, the default domain or the tenant id (you can find it here) found on the app registrations page on your application.

The first example PowerShell will return a simple grid view with a multi valued column containing the roles of each assigned object. The script will not dig into the group members.

And here is an example for you that also digs into the different assigned groups and fetches all transitive members of those:

That’s it, I have now gone through three ways of getting the application role assignments from Azure AD into your application:

• SCIM provisioning
• At sign in (OAuth ID Token or SAML Claim)
• Fetching by Graph calls

The next posts will focus on how to actually manage application role assignments, dynamically assigning, using Entitlement Management to allow both internal and invited users to request access and other means. Stay tuned!

Share this:

• Full IGA using Azure AD

Published by Marius Solbakken

View all posts by Marius Solbakken

One thought on “ Full IGA using Azure AD – Getting app role assignments using PowerShell ”

• Pingback: Full IGA using Azure AD – Entitlement Management – Good Workaround!

Leave a comment Cancel reply

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

You're signed out

Sign in to ask questions, follow content, and engage with the Community

• LearnPlatform
• LearnPlatform Guides

Configuring Single-Sign-On with Azure

• Subscribe to RSS Feed
• Mark as New
• Mark as Read
• Printer Friendly Page
• Report Inappropriate Content

in LearnPlatform Guides

Note: You can only embed guides in Canvas courses. Embedding on other sites is not supported.

Community Help

View our top guides and resources:.

To participate in the Instructurer Community, you need to sign up or log in:

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Azure Managed Applications overview

• 6 contributors

Azure Managed Applications enable you to offer cloud solutions that are easy for customers to deploy and operate. As a publisher, you implement the infrastructure and can provide ongoing support. To make a managed application available to all customers, publish it in Azure Marketplace. To make it available to only users in your organization, publish it to an internal service catalog.

A managed application is similar to a solution template in Azure Marketplace, with one key difference. In a managed application, the resources are deployed to a managed resource group that's managed by the application's publisher or by the customer. The managed resource group is present in the customer's subscription, but an identity in the publisher's tenant can be given access to the managed resource group. As the publisher, if you manage the application, you specify the cost for ongoing support of the solution.

The documentation for Azure Custom Providers used to be included with Managed Applications. That documentation was moved to Azure Custom Providers .

Publisher and customer permissions

For the managed resource group, the publisher's management access and the customer's deny assignment are optional. There are different permission scenarios available based on publisher and customer needs for a managed application.

• Publisher managed : Publisher has management access to resources in the managed resource group in the customer's Azure tenant. Customer access to the managed resource group is restricted by a deny assignment. Publisher managed is the default managed application permission scenario.
• Publisher and customer access : Publisher and customer have full access to the managed resource group. The deny assignment is removed.
• Locked mode : Publisher doesn't have any access to the customers deployed managed application or managed resource group. Customer access is restricted by deny assignment.
• Customer managed : Customer has full management access to the managed resource group and the publisher's access is removed. There's no deny assignment. Publisher develops the application and publishes on Azure Marketplace but doesn't manage the application. Publisher licenses the application for billing through Azure Marketplace.

Advantages of using permission scenarios:

• For security reasons, publishers don't want persistent management access to the managed resource group, customer's tenant, or data in managed resource group.
• Publishers want to remove the deny assignment so that customers manage the application. Publisher doesn't need to manage the deny assignment to enable or disable actions for the customer. For example, an action like rebooting a virtual machine in the managed application.
• Provide customers with full control to manage the application so that publishers don't have to be a service provider to manage the application.

Advantages of managed applications

Managed applications reduce barriers to customers using your solutions. They don't need expertise in cloud infrastructure to use your solution. Depending on the permissions configured by the publisher, customers might have limited access to the critical resources and don't need to worry about making a mistake when managing it.

Managed applications enable you to establish an ongoing relationship with your customers. You define terms for managing the application and all charges are handled through Azure billing.

Although customers deploy managed applications in their subscriptions, they don't have to maintain, update, or service them. But there are permissions that allow the customer to have full access to resources in the managed resource group. You can make sure that all customers are using approved versions. Customers don't have to develop application-specific domain knowledge to manage these applications. Customers automatically acquire application updates without the need to worry about troubleshooting and diagnosing issues with the applications.

For IT teams, managed applications enable you to offer preapproved solutions to users in the organization. You know these solutions are compliant with organizational standards.

Managed applications support managed identities for Azure resources .

Types of managed applications

You can publish your managed application either internally in the service catalog or externally in Azure Marketplace.

Service catalog

The service catalog is an internal catalog of approved solutions for users in an organization. You use the catalog to meet organizational standards and offer solutions for the organization. Employees use the service catalog to find applications that are recommended and approved by their IT departments. They can access the managed applications that other people in their organization share with them.

For information about publishing a managed application to a service catalog, see Quickstart: Create and publish a managed application definition .

Azure Marketplace

Vendors who want to bill for their services can make a managed application available through Azure Marketplace. After the vendor publishes an application, it's available to users outside their organization. With this approach, a managed service provider (MSP), independent software vendor (ISV), or system integrator (SI) can offer their solutions to all Azure customers.

For information about publishing a managed application to Azure Marketplace, see Create an Azure application offer .

Resource groups for managed applications

Typically, the resources for a managed application are in two resource groups. The customer manages one resource group, and the publisher manages the other resource group. When the managed application is defined, the publisher specifies the levels of access. The publisher can request either a permanent role assignment, or just-in-time access for an assignment that's constrained to a time period. Publishers can also configure the managed application so that there's no publisher access.

Restricting access for data operations is currently not supported for all data providers in Azure.

The following image shows the relationship between the customer's Azure subscription and the publisher's Azure subscription, which is the default publisher managed permission. The managed application and managed resource group are in the customer's subscription. The publisher has management access to the managed resource group to maintain the managed application's resources. The publisher places a read-only lock (deny assignment) on the managed resource group that limits the customer's access to manage resources. The publisher's identities that have access to the managed resource group are exempt from the lock.

The management access as shown in the image can be changed. The customer can be given full access to the managed resource group. And, the publisher access to the managed resource group can be removed.

Application resource group

This resource group holds the managed application instance. This resource group might only contain one resource. The resource type of the managed application is Microsoft.Solutions/applications .

The customer has full access to the resource group and uses it to manage the lifecycle of the managed application.

Managed resource group

This resource group holds all the resources required by the managed application. For example, an application's virtual machines, storage accounts, and virtual networks. The customer might have limited access to this resource group because unless permission options are changed, the customer doesn't manage the individual resources for the managed application. The publisher's access to this resource group corresponds to the role specified in the managed application definition. For example, the publisher might request the Owner or Contributor role for this resource group. The access is either permanent or limited to a specific time. The publisher can choose to not have access to the managed resource group.

When the managed application is published to the marketplace , the publisher can grant customers the ability to perform specific actions on resources in the managed resource group or be given full access. For example, the publisher can specify that customers can restart virtual machines. All other actions beyond read actions are still denied. Changes to resources in a managed resource group by a customer with granted actions are subject to the Azure Policy assignments within the customer's tenant scoped to include the managed resource group.

When the customer deletes the managed application, the managed resource group is also deleted.

Resource provider

Managed applications use the Microsoft.Solutions resource provider with ARM template JSON. For more information, see the resource types and API versions.

• Microsoft.Solutions/applicationDefinitions
• Microsoft.Solutions/applications
• Microsoft.Solutions/jitRequests

Azure Policy

You can apply an Azure Policy to audit your managed application. You apply policy definitions to make sure deployed instances of your managed application fulfill data and security requirements. If your application interacts with sensitive data, make sure you've evaluated how that should be protected. For example, if your application interacts with data from Microsoft 365, apply a policy definition to make sure data encryption is enabled.

In this article, you learned about benefits of using managed applications. Go to the next article to create a managed application definition.

Quickstart: Create and publish an Azure managed application definition

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

PowerShell script for returning groups assigned to application

Is there a better way to do this? I want to return the AD groups that are assigned to an Azure AD application. I can find a lot of information on looking at the assigned roles, but not the groups.

The code below, looks at all AD groups first and then ultimately checks the application to see if they are applied. Is there a way to check the application directly?

• azure-active-directory

• I've not needed to do this use case, so, unsure. However, if you can do it in the Azure GUI, then look at the property particulars and put that in your code. If it is not there, then that means an underlying API is needed, which MS may not have exposed. So, you need to research that or hit up your MS Azure rep. –  postanote Commented Mar 20, 2020 at 22:08
• Do you have a chance to look into my answer? If it is helpful for you, you can accept it as answer( click on the check mark beside the answer to toggle it from greyed out to filled in.). This can be beneficial to other community members. Thank you. –  Allen Wu Commented Mar 25, 2020 at 1:01

The cmdlet for checking a service principal application role assignment is Get-AzureADServiceAppRoleAssignment .

A sample here:

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged azure powershell azure-active-directory adgroup or ask your own question .

• Featured on Meta
• Upcoming sign-up experiments related to tags
• Policy: Generative AI (e.g., ChatGPT) is banned
• The [lib] tag is being burninated
• What makes a homepage useful for logged-in users

Hot Network Questions

• What’s the highest salary the greedy king can arrange for himself?
• Movie about a planet where seeds must be harvested just right in order to liberate a valuable crystal within
• Can you help me to identify the aircraft in a 1920s photograph?
• How to make D&D easier for kids?
• What is the translation of misgendering in French?
• Is it unfair to retroactively excuse a student for absences?
• Do known physical systems all have a unique time evolution?
• Viewport Shader Render different from 1 computer to another
• PWM Dimming of a Low-Voltage DC Incandescent Filament (Thermal Shock?)
• Is the zero vector necessary to do quantum mechanics?
• A 90s (maybe) made-for-TV movie (maybe) about a group of trainees on a spaceship. There is some kind of emergency and all experienced officers die
• Did the BBC censor a non-binary character in Transformers: EarthSpark?
• D&D 3.5 Shadow Magic / Shadow Conjuration: Can an illusionist create a quasi-real shadow of ANY monster? Or only those on the summon monster lists?
• Is it possible to complete a Phd on your own?
• Why is my GFCI tripping when i turn the breaker on?
• Were there engineers in airship nacelles, and why were they there?
• Do I need to indicate 'solo' for wind/brass instruments in shared staff?
• Event sourcing javascript implementation
• Do capacitor packages make a difference in MLCCs?
• What is a positive coinductive type and why are they so bad?
• Nesting two environments
• Examples of distribution for which first-order condition is not enough for MLE
• Why depreciation is considered a cost to own a car?
• Is the FOCAL syntax for Alphanumeric Numbers ("0XYZ") documented anywhere?