Overview

A quick post to remind me how to call a Python script via PowerShell, passing in an argument and saving the output of the script to a variable in PowerShell using a couple of demo scripts that do nothing more than pass a string to the Python script and return it with text added.

Test machine specs:

Ubuntu 20.04.5 LTS
PSVersion 7.3.2
Python 3.10.5 

This should work as is with Python 3.6+ (uses f-string formatting).

I have a virtual environment created with the required Python packages installed. The Python script simply outputs the text I need via the print function and exits.

Here is the Python script that takes an argument and prints it out.

The output can be saved to a variable in PowerShell by calling the script like so.

The PythonProgramPath can either point to the main install of Python (or just Python if it is added to the Path environment variable) or a virtual environment if extra packages are required / installed for the script to run.

I was using this method to work with JWTs. I was struggling to so with PowerShell and already had the Python scripts written so I only had to grab the output of the script to use the JWT values in my PowerShell script.

Overview

Something that I’ve had to do more of recently is create JSON Web Key Sets commonly known as JWKS -private and public keys in JSON format for Terraform to authenticate to Okta via OAuth service applications. There are plenty of online options out there but when running in production, you’ll want to create them locally and not rely on a third party solution. This works for Okta service accounts but the JWKS can be used for other applications and the script updated to create keys with other algorithms and settings.

The script below shows how to achieve this with Python and OpenSSL running on Ubuntu and can be used as a starting point for other operating systems to generate keys locally.

Because the keys are being used in automation (with Terraform to provision Okta resources) they are not protected with a password. These keys should be moved to secure storage such as a password manager / key vault for automation ASAP.

Tested with:

• Python 3.8.10
• Ubuntu 20.04.5 LTS

In a virtual environment - install the jwcrypto module if not already installed.

pip install jwcrypto

Copy the contents of main.py to a local main.py file.

python main.py

4 keys will be created in the ‘keys’ directory.

The keys are now ready to be used and can be setup to authenticate Terraform with Okta. Terraform requires the private key in RSA format so use the key service_app_keys_rsa.pem for any Terraform scripts.

Overview

Quick guide on how to authenticate and query the Airthings consumer API to pull data from the air quality monitoring devices registered with the account.

Code

Here’s the code to authenticate and pull sensor data to get going.

Script details

Requires Python 3.6 and above due to use of f-strings.

The requests package is a requirement and should be installed in a virtual environment or container with pip install requests. The script calls the authentication server to request a bearer token to authenticate the calls to the API, using the client credentials Oauth2 flow.

You’ll need the API token and client id which can be created: https://dashboard.airthings.com/integrations/api-integration with the scopes ‘'’read:device:current_values’’’ checked.

Before running the script, the secret should be exported to an environment variable. That can be done by:

# Linux and Mac
 export secret="secret-key"
# Windows
 $Env:secret = 'secret-key'

Update the client_id and device_id variable values - these can be viewed in the Airthings website.

python main.py

That should then pull the latest data from the API for that particular device. Individual values can be accessed via the dictionary returned from the API as demonstrated in the script with the co2 value.

Overview

I have spent the last 2 days attempting and finally succeeding in querying the Workday API for a user by their ID using Python and Zeep and couldn’t find a solid example so have recorded here the solution and the process of getting to it. I am by no means a Python expert and definitely not a Workday expert having only used it as an employee in the past, this is what I came up with and worked.

Script

If you came here just to see how to get going, check out the below script. Details are further down if you’re interested.

Requires the Zeep package to be installed.

pip install zeep

Process

Having not had the ‘joy’ of using a SOAP based API in a long long time, I set off Googling ways to do this with Python. I found the Zeep package so started there then I came across the Workday package but found that it caused an error for me and the project is now archived in GitHub. Going back to Zeep I read this tutorial that got me on my way. I was able to return a list of workers however was still stuck on how to actually specify a particular user.

Reading those posts, and this question on Stack Overflow that shows the required xml and going back to the documentation a lot, I finally managed to figure out what was required to send the request to the SOAP endpoint and get back the correct worker data.

Dumping the wdsl

First thing to do was dump the wdsl using Zeep

workday_url = 'https://<hostname>.workday.com/ccx/service/<tenant>/Human_Resources/v36.2?wsdl' 
python -m zeep  $workday_url >> hr.txt

Then referencing the Workday API docs and the hr.txt I found that Worker_Request_References is used “to retrieve a specific instance(s) of Worker and its associated data.” The parameter name is Worker_Reference and takes the type WorkerObjectID.

Following along with the Zeep docs on datastructures I found we can use the get_type method of the client to create a query. “Most of the times you need to pass nested data to the soap client. These Complex types can be retrieved using the client.get_type() method.”

Referencing the hr.txt wdsl dump I searched for ‘Worker_Request’ and found ‘ns0:Worker_Request_ReferencesType’. Inspecting the object looked like I was on the right track so I added the ID I was looking for as per the docs and tried that but got an exception.

ref_type = client.get_type('ns0:Worker_Request_ReferencesType')
request = ref_type(Worker_Reference='1234')
client.service.Get_Workers(request)

zeep.exceptions.Fault: Validation error occurred. Invalid ID 'type'  attribute: NotSet.  Valid Types: WID 

Inspecting the request object I could see that it was kind of right but also missing the type as mentioned in the docs and also in the xml example on the Stack Overflow post and what I had be shown in Workday Studio.

Further down in the Zeep datastructures docs and mentioned in one of the blog posts it shows how to set a nest value so after using the request object as a starting point and some trial and error creating the dictionary that finally worked.

request_dict = { 
    'Worker_Reference': { 
        'ID': { 
            'type': 'Employee_ID', 
            '_value_1': employee_id 
        }, 
        'Descriptor': None 
    }, 
    'Skip_Non_Existing_Instances': None, 
    'Ignore_Invalid_References': None 
}

client.service.Get_Workers(request_dict) 

This returned the data for my user in the test instance.

Summary

Hopefully this will help someone who is struggling querying the Workday API like I was.

Overview

Below are the details of Microsoft Graph permissions including IDs which are required when using Terraform, PowerShell or Azure CLI.

Update April 2024

Thanks to this GitHub issue raised by jan-swiecki, I have updated this article with an example of how to find the ID of the MS Graph permissions using Terraform with the azuread_service_principal resource. This functionality was introduced just after I had written the original article. The below Terraform file demonstrates outputing the IDs via variables and also how to use the permission IDs to create an application.

Thanks again to jan-swiecki for taking the time to share this knowledge.

Original article continues

In my previous article on using Terraform to deploy to Azure AD, I used the required_resource_access argument in the Terraform azuread_application resource to set the Microsoft Graph API permissions for the app being created. One thing that stumped me for a bit was how to get the ID of the permission. This wasn’t available on the Microsoft Graph API permissions documentation at the time of writing.

Searching showed that you can see the current API grants of an application by the Azure CLI by running:

 az ad app show --id 

This outputs the following section:

  "requiredResourceAccess": [
    {
      "additionalProperties": null,
      "resourceAccess": [
        {
          "additionalProperties": null,
          "id": "7ab1d382-f21e-4acd-a863-ba3e13f7da61",
          "type": "Role"
        }
      ],
      "resourceAppId": "00000003-0000-0000-c000-000000000000"
    }
  ],

The resourceAppId in the above snippet is for the Microsoft Graph. This post has details of the other application IDs for Microsoft resources. The resourceAccess ID is for the role Directory.Read.All and this is what is displayed in the Azure portal. This was a start but I wanted to know other IDs and this method only showed what was already granted to that app. I couldn’t find a way to do this via the Azure CLI or PowerShell.

I ended up finding this comment on a GitHub issue that showed how to retrieve the information from the MS Graph by the following query: https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '00000003-0000-0000-c000-000000000000'&$select=appRoles, oauth2PermissionScopes.

I created a basic python cli script to get this information, format it and output it in a markdown table which is what is below to be used for future reference.

Note: Role permissions display as Application and scope permissions display as Delegated in the Azure portal.

Role permissions

Scope permissions

Overview

In this post I will cover setting up Terraform and Azure blob storage to save state files for Terraform. State files allow Terraform to track the current resources provisioned and can calculate the changes that updates to the Terraform file will make to your infrastructure.

Azure blob storage is an object store similar to AWS S3. The advantages of storing state in an Azure blob storage container is you get locking on the blob by default - this means that two people can’t update the infrastructure at the same time. You can set up the same for S3 using a DynamoDB table to track the locking state but I find the Azure blob storage way much easier to implement.

In my previous post, I detailed the steps required to provision an Azure AD application via Terraform and this post will build on that.

It requires that the service principal is still available from the previous post to deploy the application and the details are set in environment variables as before.

export ARM_SUBSCRIPTION_ID='abcde'
export ARM_TENANT_ID="abcde"
export ARM_CLIENT_ID="abcde"
 export ARM_CLIENT_SECRET="abcde"

There is a charge for using storage accounts (including storage, transfer and read/write operations), see the Azure Storage Blob pricing for details.

Azure Storage account

Create with the Azure CLI

az login

rg=terraform-state-demo
sa=tfstate$RANDOM
container=tfstate

# Resource group
az group create --name $rg --location eastus2 --tags 'Project=Terraform' 'Env=Demo'

# account
az storage account create --resource-group $rg --name $sa --sku Standard_LRS --encryption-services blob

# container
az storage container create --name $container --account-name $sa

# Get the storage account name
echo $sa

This creates a new storage account in the resource group and a container that is set to private access (you do not want your Terraform state files public access because they can contain secrets).

SAS Token

To authenticate to the blob storage container, a 2 year SAS token is created. After creation this is set as an environment variable for Terraform to use. This should also be securely saved somewhere such as a password manager and or a secrets manager solution such as Azure Key Vault or Hashicorp Vault for use in a CI/CD pipeline. You could also use one of the storage account [access keys], however I would advise to use a SAS token that is ony scoped to that particular storage account and container - just enough privilege!

accountKey=$(az storage account keys list --resource-group $rg --account-name $sa --query '[0].value' -o tsv)
end=`date -u -d "2 years" '+%Y-%m-%dT%H:%MZ'`
sas=`az storage container generate-sas -n $container --account-key $accountKey --account-name $sa --https-only --permissions dlrw --expiry $end -o tsv`

 export ARM_SAS_TOKEN=$sas

 az logout

Terraform Azure backend configuration

Now we can access the blob storage via the SAS token, the Terraform configuration should be updated with the details of where to store the state. This is done in the ‘backend’ section. See the full main.tf file below for complete example.

terraform {
  required_providers {
    azuread = {
      version = "=1.6.0"
    }
  }
  backend "azurerm" {
    key = "msgraphapp.tfstate"
    resource_group_name   = "terraform-state-demo"
    storage_account_name  = "tfstate13069"
    container_name        = "tfstate"
  }
}

If you want to keep the details for the storage account out of the main file, you can use a partial configuration. For example you could create a file called backend.conf (which you can also add to the .gitignore file) and have the following values.

resource_group_name   = "terraform-state-demo"
storage_account_name  = "tfstate13069"
container_name        = "tfstate"

The start of the main.tf would look like the following (I like to keep the name of the state file in main.tf):

terraform {
  required_providers {
    azuread = {
      version = "=1.5.0"
    }
  }
  backend "azurerm" {
    key = "msmsgraphapp.tfstate"
  }
}

Then you can run the initialisation to specify the backend file:

terraform init -backend-config=backend.conf

This solution would allow you to keep some or all of the configuration of of source control if desired.

Terraform

Here is the updated main.tf file from my previous post.

Copy the contents to a main.tf file - don’t forget to update the storage_account_name value with the output of echo $sa.

The terraform.tfvars file is the same as before.

Init

Running the initialisation command will create the state file in the blob container. If you are still using the state file from the previous post, then the state file will be copied from the local computer storage to Azure blob storage - pretty neat.

terraform init

Here you can see the blob created with the name we specified (msmsgraphapp.tfstate) and the lease state is available.

If you download the state file and take a look you’ll see a state file with no details.

Plan and apply

Running a plan and apply will update the state with the details of the application - including the client secret. That is why it is important to protect the access to the blob storage and only allow those who would need to access. Don’t forget to set the service principal credentials in the environment variables (see the overview of this post).

terraform plan -out deployment.tfplan

terraform apply -auto-approve deployment.tfplan

If the apply takes along time, you can go to the blob details and you’ll see the lease status as Locked and the lease state as Leased which will prevent anyone else being able to update the infrastructure until you have finished and released the lock.

Clean up

Delete the resources created by Terraform:

terraform destroy

Delete just the state file or delete everything:

# Add the variables in again for container, sa and rg if in a new session.
az login
accountKey=$(az storage account keys list --resource-group $rg --account-name $sa --query '[0].value' -o tsv)
az storage blob delete -c $container --account-name $sa --account-key $accountKey -n msgraphapp.tfstate

az login
# To delete everything
az group delete --name  terraform-state-demo

Summary

That’s it, now the remote state can be shared with others in the team (that have a SAS token) or can be used in a CI/CD pipeline.

Overview

This post will cover how to deploy an Azure AD application using Terraform and assign it permissions to the Microsoft Graph with User.Read scope. I’m using the latest version of Terraform (currently 1.0.3), latest version of the AzureAD provider (currently 1.0.6) and running on Ubuntu 18.04. Although this was carried out on a Ubuntu machine, it should be very similar for Windows or Mac.

The current AzureAD Terraform provider (1.0.6) uses the legacy Azure Active Directory Graph to interact with the API by default. Version 2 of the provider will be updated to use the Microsoft Graph API. For this post I’ve decided to use the Microsoft Graph which is currently in Beta support for this provider version but is not advised for production use.

This isn’t a beginners guide to Terraform or AzureAD, more of a post of how I have deployed to AzureAD with Terraform so a basic understanding of both would be beneficial.

Create application with permissions to deploy applications

The first step is we need to authenticate to be able to perform actions such as create, update and remove resources.

The easiest way to create a service principal is the Azure CLI. The Azure CLI can be installed locally or you can use it from the Azure cloud shell from the browser.

az login
az ad sp create-for-rbac --skip-assignment --name 'test-terraform-ad'

After running the above command, appID and password are displayed, keep a note of these somewhere secure such as a password manager.

Alternatively there is the guide on creating a service principal in the portal, however the Azure CLI is much quicker and easier.

Now a service principal will be created in Azure AD. You can view this by going to the AzureAD portal, selecting the Enterprise applications blade, changing the Application type to All Applications then searching tor the test-terraform-ad service principal.

Note: Because we authenticate interactively with az login, Terraform would be authenticated in that session but I want to demonstrate how to do this with Service Principal credentials so they can be used in a CI/CD pipeline in the future.

Required permissions

Assign the application administrator role to the service principal previously created test-terrafrom-ad.

You can use the Microsoft Graph API to set the role or via the portal as per screen shot below.

Go to Azure Active Directory then the Roles and administrators blade. Click on the Application administrator role, then the + Add assignments button and then Select Members link. Search for test-terrafrom-ad and confirm.

Set up Terraform

Create a new directory locally, and change directory to it.

mkdir azure-tf-demo
cd azure-tf-demo
touch main.tf
touch terraform.tfvars

Copy the contents of the following files.

Main file (main.tf).

Variable values file (terraform.tfvars).

Setting the credentials

Set the credentials of the Service Principal in authentication environment variables:

export ARM_SUBSCRIPTION_ID='abcde'
export ARM_TENANT_ID="abcde"
export ARM_CLIENT_ID="abcde"
 export ARM_CLIENT_SECRET="abcde"

To initialize Terraform run the following:

terraform init

This will store the state locally on your machine in the same directory.

Validate everything is good by running:

terraform validate

The secret line is intentionally indented to keep it out of the bash history.

Plan the deployment

Now it’s time to run a plan to see what is going to be created. The plan is save to a file locally and the will be used to deploy the resources.

terraform plan -out deployment.tfplan

Deploying the application

If all looks good, it can be deployed using the output from the above plan command.

terraform apply -auto-approve deployment.tfplan

In the AzureAD portal under Azure Active Directory blade App registrations blade and All applications search for the created app.

Select the app then the API permissions blade to see the User.Read scope granted to the app.

The application password

Previously with the legacy Azure API you could specify the application secret however with the Microsoft Graph API, the secret is generated. To find the generated value, look in the terraform.tfstate file. Under the “type”: “azuread_service_principal_password” you’ll see “attributes” and then “value” which has the password. This is why it is very important to protect the Terraform state file (it can contain sensitive information), especially when working with a remote backend, it should be encrypted at rest and limited access applied to the backend.

Update the application

Now the deployment has been made, the plan is stale and needs updating.

terraform plan -out deployment.tfplan

Running an apply command again will result in nothing being changed.

Change the name of the value in the tfvariables.tf file to something else and run:

terraform plan -out deployment.tfplan

A change will be displayed.

Run the apply command to update the application.

terraform apply -auto-approve deployment.tfplan

Refresh the Overview page and you’ll see the new Application name.

Destroy the application

Clean up the application and service principal using the destroy command.

terraform destroy

Because the auto-approve option is not specified, a prompt will ask to confirm.

The resources managed by Terraform will be deleted.

I’ve created another post on how to configure Azure blob storage to save the state file remotely so it can be used in a team environment so if you want to follow along with that, keep the service principal otherwise it can be removed by running the Azure CLI:

az ad sp delete --id id-of-sp-created-earlier

Now all the resources for this post will be removed.

Overview

I wanted to get a list of users assigned to the Global Administrators and User Administrator roles for an audit report and decided to use the PowerShell Microsoft Graph module to achieve this so the report could be automated to run periodically.

Getting the information

Installing the graph module is straight forward. Finding the correct command to do what I wanted wasn’t! The Graph module is a ‘meta module’ and installs numerous other modules that contain the Cmdlets so that took a bit of getting used to. I also found the graph module Cmdlets lacking in help details I’m used to in other PowerShell modules.

My first action was to search the graph module for cmdlets that looked like they would return the information I wanted.

First I had a look at all the modules, then narrowed down the search to just the Identity ones.

Get-Module Microsoft.Graph* -ListAvailable
Get-Command -Module Microsoft.Graph.Identity* -Verb Get -Noun "*role*"

I found a promising Cmdlet: Get-MgPrivilegedRole but when I ran it, the following error was returned.

Get-MgPrivilegedRole_List: {"error":{"code":"TenantEnabledInAadRoleMigration","message":"The current endpoints of AAD roles have been disabled for the tenantfor migration purpose. Please use the new Azure AD RBAC roles. Please refer to https://aka.ms/PIMFeatureUpdateDoc for new PIM features; https://aka.ms/PIMAPIUpdateDoc for API and PowerShell changes because of migration."}}

After some more searching of the module, I discovered Get-MgDirectoryRole and this returned the information I needed.

Get-MgDirectoryRole
Get-MgDirectoryRole | Select-Object -Property DisplayName, Description | Sort-Object -Property DisplayName

I found that to filter for a specific role, you can do the following:

Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'"
Get-MgDirectoryRole -Filter "DisplayName eq 'User Administrator'"

Now that I can find the roles and their IDs, I created the script to get the user User Principal Names that belonged to the Global Administrators group I needed to report on.

$memberList = [System.Collections.Generic.List[string]]::new()
$roleId = (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
$userList = Get-MgDirectoryRoleMember -DirectoryRoleId $roleId

foreach ($user in $userList) {
    $upn = (Get-MgUser -UserId $user.id).UserPrincipalName
    $memberList.Add($upn)
}

Update on getting all the roles

After raising an issue on GitHub, it turns out that Get-MgDirectoryRole only returns activated roles. A role is activated via the AAD portal when a user or group is added to the role. It can also be activated via the Graph API.

Below is a screenshot after I added a user to the Security Operator role and a group to the Conditional Access Administrator roles.

Getting all of the roles

Use the following Cmdlet to get all of the roles in Azure AD including those that have not been activated.

Get-MgDirectoryRoleTemplate | Select-Object DisplayName, Description | Sort-Object DisplayName

You can also find a full list of roles on the official docs.

Complete Script

Summary

The Microsoft Graph PowerShell module is far from finished and is definitely lacking in help and examples at the moment which looks to be being worked on at the moment. This task took some time to figure out but because going forward this is the module that will be invested in for PowerShell interaction with the Microsoft Graph it was a good opportunity to use it more. There is still a lot to be done to add functionality. For example currently you can add members to a group via this module but you can’t remove them currently without a workaround, however I will start using this module more in automation in the future.

Overview

I recently passed the Azure SC-300 Microsoft Identity and Access Administrator certification exam and wrote this post to list some of the useful resources I came across that help me pass.

Microsoft are updating their exams more regularly to meet the ever changing services and practices that the cloud brings. It is always best to download the exam objectives from the official site and go through them to build a plan to pass the exam.

When I took the exam it was broken down into the following sections:

• Implement an identity management solution (25-30%)
• Implement an authentication and access management solution (25-30%)
• Implement access management for apps (10-15%)
• Plan and implement an identity governance strategy (25-30%)

Microsoft Learning

First stop should be the Microsoft Learning path which is a free online learning platform created by Microsoft that has a lot of good information covering the topics covered in the exam.

The learning path is broken down into 4 modules (this may change in the future):

SC-300 part 1: Implement an identity management solution SC-300 part 3: Implement Access Management for Apps

At time of writing there were no 3rd party courses available. Keep an eye on Pluralsight, Udemy, A cloud guru, [cloudskill.io] and other learning platforms because I’m sure there will be courses created in the future.

YouTube

By John Savill

John’s videos on YouTube are great, complex topics are explained clearly along with detailed examples. Highly recommended watching for all things Azure, PowerShell and more. Check out his channel.

• Azure Master Class Part 2 - Identity
• Azure AD Privileged Identity Management (PIM) - AZ-500, SC-300 Deep Dive Topic
• Azure AD App Registrations, Enterprise Apps and Service Principals
• Access Reviews Deep Dive - AZ-500/SC-300

By Mark Grimes

I found Mark’s videos the night before the exam. They are nice and concise with lots of good points and tips. Recommend to check them out sooner because he has lots of links and tips to dig deeper into the exam topics.

• SC-300 Module 1 Implement an Identity Management Solution
• SC-300 Module 2 Implement an Authentication and Access Management Solution
• SC-300 Module 3 Implement Access Management for Apps
• SC-300 Module 4 Plan and implement an Identity Governance Strategy

Pluralsight

If you have access to Pluralsight, the following courses are worth a watch.

• Design Authorization for Microsoft Azure
• Design Authentication for Microsoft Azure
• Design Auditing for Microsoft Azure
• Design Governance and Identity Management in Microsoft Azure
• Microsoft Azure Administrator: Preparing for the AZ-104 Exam (Useful tips for exam day).

Documentation

Azure AD concepts

Reading through the documentation is a great way to prepare for the exam and helps get comfortable with how the services work, different options that can be configured and how to implement and monitor. The Microsoft Learn modules have links to relevant documentation throughout the course. Below are direct links to documentation I read through a couple of times to help me pass, this is not a complete list of documents to read through and this site and this site have links that directly link to the documentation for some of the individual exam objectives.

• Main Azure AD documentation
• MFA
• Privilege Identity Management
• Azure AD Service limits (Good to review how nested groups work with certain services in Azure AD)
• What is Azure AD connect?
• Connect Azure AD to Sentinel
• Administrative Units
• Conditional Access
• Security Defaults
• Seamless Single Sign-On
• Access Packages
• Visual of services and licenses

Azure PowerShell

I recommend knowing some PowerShell for the exam and how the different Azure Modules work, enough so you can understand what is going on in a basic script. I had questions that had output from the older MSOL module and the newer Azure module.

• Azure PowerShell
• Older MSOL module
• MSGraph PowerShell module

General concepts

• The four pillars of identity management
• How SAML authentication works
• What’s the Difference Between OAuth, OpenID Connect, and SAML?
• An Illustrated Guide to OAuth and OpenID Connect

Hands on learning

This is the way I love to cement what I learned via watching and reading and I highly recommend signing up for a free Azure subscription (credit card is required) to get hands on with the services. Once you have your free subscription, you can activate a 90 day trial for P2 licenses and then another 90 day trial for EMS E5 from within the portal. This will enable the premium features of Azure AD that will feature in the exam. I have had my Azure AD and Azure subscription a number of years now but had not activated the trial until studying for the exam and that gave me the chance to configure conditional access, PIM and all the other nice features you get with a P2 license.

It is possible to get hands on and not pay a penny but with everything cloud, please review what is covered in the free tiers and understand what services will cost you money. I always have a spending limit implemented on my pay as you go account to stop any unexpected costs.

I set up an Active Directory Domain Services environment to mimic an on-premises deployment in my Azure subscription and configured an Azure AD connect server to go over the different hybrid scenarios and felt this exercise is not only worth while for the exam but also for real world experience where you are likely to come across hybrid deployments in organisations.

My GitHub repository contains the code I used to set up my demo tenant. It uses [Terraform] to create users, groups, applications and the Active Directory Domain Services and Azure AD connect along with some PowerShell configuration scripts.

A fun hands on exercise I completed was creating a basic dotnet core application following this tutorial that published to an [Azure App Service] (free tier). Then I create an App Registration so Azure AD could be used to authenticate with the application. After that I setup the app for self service, included it in access packages and set various conditional access polices to see how they affected signing into the app. It also helped me verify that I had configured Seamless Single Sign On for a domain joined machine correctly.

Practice tests

There wasn’t much in the way of practice tests available at the time I took the test. I did sign up for Wizlabs because they had a free 20 questions test for the SC-300 with a full practice exam coming soon. I advise to have a look around at the time to see if there are any available.

Exam experience

I found the exam experience smooth and well done. Day before the exam I ran the system test to make sure my laptop was OK to complete the exam and also read through tips on taking the exam including the environment to take the exam in. My workspace at home met the requirements and I just had to move my notepads and second monitor to another room while I took the exam.

Check-in was opened up 30 minutes before the exam start time and a link was sent to my mobile phone that allowed me to take a head shot and pictures of the my ID and room where I was taking the test. After a brief wait, this was all verified and I started the test.

The test itself was definitely challenging with 2 case studies and a number of questions on a broad range of topics from the skills measured sections of the exam objectives document and I was pleased with the pass result.

Hopefully this has been helpful and good luck for the exam if you’re taking it!

Overview

Today I was looking at the Microsoft Graph PowerShell module to find out if any users had incorrect licences applied (dynamic groups are used but the numbers looked a bit off). I had covered querying the Microsoft Graph with PowerShell in a previous post but thought this would be a good opportunity to give the official module a go now. Below is a quick summary on how to connect to the MS Graph with the PowerShell module and get all users using a specific licence type.

Set up and connect

Install-Module microsoft.graph

Set the module to use the Graph beta endpoint (otherwise licence data is not returned).

Select-MgProfile -Name "beta" 

Connect to the graph with the required permissions (scopes)

Connect-MgGraph -Scopes "User.Read.All"

Open the link and authenticate and authorise the PowerShell session to interact with the graph. Note I found this would not work with my Microsoft account sourced user and needed to be done by a user created in my Azure Active Directory.

Filtering by licence type

You can find the licence guids in the official documentation and these are used to filter the user results directly from the graph.

$ems = Get-MgUser -Filter "assignedLicenses/any(x:x/skuId eq efccb6f7-5641-4e0e-bd10-b4976e1bf68e)" -All # ENTERPRISE MOBILITY + SECURITY E3
$p1 = Get-MgUser -Filter "assignedLicenses/any(x:x/skuId eq 078d2b04-f1bd-4111-bbd4-b4b1b354cef4)" -All # AZURE ACTIVE DIRECTORY PREMIUM P1 
$p2 = Get-MgUser -Filter "assignedLicenses/any(x:x/skuId eq 84a661c4-e949-4bd2-a560-ed7766fcaf2b)" -All # AZURE ACTIVE DIRECTORY PREMIUM P2

The above will only return a maximum of 200 users with the All property and 999 users with 999 value set in the PageSize property.

A work around if there are more than 999 users per licence type is to get all users in the tenant, then assign them into variables depending on licence type.

$userList = Get-MgUser -All

$ems = $userList | Where-Object {$_.AssignedLicenses.SkuId -eq 'efccb6f7-5641-4e0e-bd10-b4976e1bf68e'} | Select-Object  UserPrincipalName 

$p1 = $userList | Where-Object {$_.AssignedLicenses.SkuId -eq '078d2b04-f1bd-4111-bbd4-b4b1b354cef4'} | Select-Object UserPrincipalName 

$p2 = $userList | Where-Object {$_.AssignedLicenses.SkuId -eq '84a661c4-e949-4bd2-a560-ed7766fcaf2b'} | Select-Object UserPrincipalName 

Now you have a list of users you could create reports and discover which users are assigned to multiple licences which may could up adjusted to free up licences.

Find users with two different licences

Compare-Object -ReferenceObject $ems.userprincipalname -DifferenceObject $p1.userprincipalname -IncludeEqual -ExcludeDifferent