Workload Identity Federation (let’s just call this WIF) allows app principals not residing within Azure to request short lived access tokens. This removes the need of storing client secrets or certificates within GitHub as Action secrets. One drawback ist that currently only the Azure modules support the usage of WIF.
How it works # WIF relies on trust. This trust is directly configured on the Azure AD app registration and scoped to an individual GitHub repository and optionally fine grained by limiting the usage to single git refs, specifically branches and tags. By trusting GitHub as external identity provider (IdP), a GitHub Action can request an identity token from the GitHub IdP and exchange this one against an access token within Azure AD.
A GitHub IdP issued token (decoded) contains the following information:
{ "jti": "1a9fe224-c936-46f6-a38b-3300e76251b0", "sub": "repo:nicolonsky/musical-octo-telegram:ref:refs/heads/main", "aud": "api://AzureADTokenExchange", "ref": "refs/heads/main", "sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "repository": "nicolonsky/musical-octo-telegram", "repository_owner": "nicolonsky", "repository_owner_id": "32899754", "run_id": "3986560796", "run_number": "2", "run_attempt": "2", "repository_visibility": "private", "repository_id": "592303002", "actor_id": "32899754", "actor": "nicolonsky", "workflow": ".github/workflows/wif.yaml", "head_ref": "", "base_ref": "", "event_name": "push", "ref_type": "branch", "workflow_ref": "nicolonsky/musical-octo-telegram/.github/workflows/wif.yaml@refs/heads/main", "workflow_sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "job_workflow_ref": "nicolonsky/musical-octo-telegram/.github/workflows/wif.yaml@refs/heads/main", "job_workflow_sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "iss": "https://token.actions.githubusercontent.com", "nbf": 1674486850, "exp": 1674487750, "iat": 1674487450 } Did you recognize the matching sub attribute within the GitHub issued token and the Azure AD configuration? For a successful authentication the:
Windows Package Manager (winget) provides exciting features to install and upgrade apps on Windows devices. But how does winget actually work and how are new packages integrated? Within this post I want to elaborate on some questions I had when having a closer look into winget.
How does winget find sources? # By default, winget has the following sources configured:
msstore: Microsoft Store (public) winget: Winget Content Delivery Network (CDN) When searching for a particular package, e.g: winget search wireshark all configured sources are searched for a match.
lesson learned: winget can install packages from the public Microsoft store and the winget CDN.
How are winget CDN packages provided? # Winget CDN packages reside within a public git repository hosted on GitHub. The repository contains an alphabetic folder structure by vendor and product name holding manifests in YAML format that describe the app details.
The manifests folder within the repo is grouped by the app vendor and app name and YAML contents of a manifest look like this:
A common pitfall in environments where Windows server is used for radius authentication is that Microsoft network policy server (NPS) does currently not support device based authentication for Azure AD joined devices. NPS always checks for the existence of a corresponding computer object in AD. For my home setup and lab I wanted to build a radius solution to enable 802.1x authentication on my Wi-Fi network.
Disclaimer # This post describes my setup and does not cover prerequisites like certification authority, certificate revocation and client certificate deployment via SCEP. Furthermore you should be familiar with docker, network topics, dns and Intune.
Available solutions # Well known commercial Network Access Control (NAC) solutions like CISCO ISE or Aruba Clearpass often ship with an integrated RADIUS server and the possibility to configure wheter LDAP lookups for computer accounts should happen. Important is, that the solution supports certificate revocation checks either via CRLs or OCSP to ensure network access is blocked when a client certificate is revoked.
For my home and lab setup I wanted to leverage a free or open source solution and decided to use freeRADIUS, probably the most popular open source radius server. freeRADIUS supports EAP-TLS for 802.1x authentication out of the box and is well documented. Additionally, I was looking for a solution that can be deployed to both locallly in my network (e.g. on a raspberry pi) and also to PaaS offerings like Azure.
If you are using the “AzureAD” PowerShell module (also applies to the AzureADPreview) you have probably noticed that the Connect-AzureAD Cmdlet ignores existing access tokens and initiates a new sign in to Azure AD even if you are already signed in.
Prompt you get when calling the "Connect-AzureAD" cmdlet Long story short, I got annoyed every time when I accidentally recalled Connect-AzureAD (mostly when working with Scripts) until I found this amazing hint on technet and now I want to (re-)share it with you.
In your PowerShell scripts simply use the following snippet to connect with Azure AD / check your connection and you wont get any sign-in prompts if you are already connected!
Reusing the access token for the MsOnline module # The Azure AD PowerShell access token which gets stored can also be used to connect to the MsOnline resources (because certain attributes like strong authentication details are not available with the AzureAD modules):
$token = [Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens Connect-MsolService -AccessToken $token.AccessToken.AccessToken
The Azure AD portal does not really provide an overview about all directory role assignments in your tenant. If you want to review existing Azure AD Directory roles a csv report will probably better server your needs. Therefore I created a PowerShell script to export the role assignments.
The Azure AD Portal only displays limited information about the assignments ### PowerShell Script Find the PowerShell script in my techblog GitHub Repository.
Make sure that you have the AzureAD PowerShell module installed before running the script. You can install it by running “Install-Module AzureAD”.
PowerShell script output Report # The report contains three columns:
Role (name of the directory role) Note that the Global Administrator Role is represented as Company Administrator Member If the role is assigned to a user its the UserPrincipalName If the role is assigned to a service principal its the display name with the Azure AD application ID in the brackets ObjectType Indicates whether the role is assigned to user account or a service principal CSV file containing all assigned directory roles Comparing reports # You can compare two reports with the following PowerShell code:
An account in your Azure Active Directory got deleted and you want to examine who initiated the delete action? Sounds very simple but if you do not want to search your logs manually things become a little bit trickier.
The challenge # When a user gets deleted and you only remember it’s userPrincipalName you wont be able to to search for a match. And I doubt that you memorized the Azure AD object id of that user.
Here’s what the Azure AD Audit log shows us:
The userPrincipalName attribute will get the Azure AD object ID as prefix:
userPrincipalName before deletion: jane.doe@nicolonsky.ch userPrincipalName after deletion: f5d7e17347594a658d124329b9b025abjane.doe@nicolonsky.ch By having a closer look to the Azure Active Directory Audit logs you will notice that the filtering or search capabilities are limited in terms of searching for a specific target:
Search is case-sensitive and only supports ‘starts with’ operator
Which means we cannot search for the userPrincipalName. The only option in the Azure AD Audit Logs would be to download the logs and perform a search within a text editor which is not really feasible nor efficient.
Recently I needed to assign a lot of Microsoft licenses to different Azure AD groups. Unfortunately Microsoft does currently not offer a solution to do this (yet). Instead of giving up on this I decided to analyze what actually happens when you assign a license to a group in the Azure portal and found some actions going on within the hidden portal API. As an outcome I built a PowerShell module to manage Azure AD group based licensing assignments.
Full functionality for group-based licensing is available through the Azure portal, and currently PowerShell and Microsoft Graph support is limited to read-only operations.
PowerShell and Graph examples for group-based licensing in Azure AD
The PowerShell module # The PowerShell module uses the “main.iam.ad.ext.azure” API for the license operations and the AzureRM module to get an access token for the API. Please note that the mentioned API is not officially supported or documented. Although the API is being used by the Azure Portal for settings you configure via the portal.
Kudos to Jos Lieben for his “pioneer work” documenting on how to get an access token for the API.
With Microsoft Graph we have powerful automation and configuration management capabilities. To further simplify this process I built the “Modern Workplace Concierge”. It is an ASP.NET application which uses an Azure AD multi tenant app to access the Microsoft Graph API on behalf to perform export and import tasks. The project uses the Microsoft Graph Beta API to access your tenant’s data.
Modern Workplace Concierge # The Modern Workplace Concierge allows you to:
Import and export Intune configuration and settings Import and export Conditional Access policies Download OSD ready offline Autopilot profiles Download stored PowerShell scripts in Intune (as PowerShell) This allows you to import your existing Intune and Conditional Access configuration in new tenants or demo tenants. The files in JSON format can be used for further processing or documentation.
And this all via web browser no client side prerequisites or PowerShell code is required!
The Modern Workplace Concierge The project and more information is available on GitHub feel free to provide feedback there.
That's how I backup my Intune configuration with the #ModernWorkplaceConcierge. Curious? Give it a try. Of course also supporting imports .https://t.co/30H8b0olLn pic.twitter.com/g5X58l1e1i
— Nicola Suter (@nicolonsky) December 3, 2019 More Information:
Auditing Conditional Access events and changes is crucial regarding your hygiene in Azure AD for your modern workplace. With the goal that we receive appropriate notifications and alerts if special events occur. Thanks to Azure Log Analytics (also referred to as Azure Monitor) we can easily filter and create alerts based on events. This post starts where most of the others end - giving you practical examples of KUSTO queries to search your Azure AD Audit logs with Log Analytics.
Default log retention in AAD # A point which get’s raised often is the default log retention in Azure Active Directory (AAD). Azure Active Directory stores all activity reports depending on your license for 7 or 30 days:
Azure AD Free and Basic: 7 days Azure AD Premium P1 and P2: 30 days Source, more Information.
To retain and further process Azure Active Directory Audit Logs for a longer time period (because a 30 day audit trail is likely too short for most organizations) we can:
Stream to an Azure Event Hub Archive to Blob Storage Forward them to Azure Log Analytics With Log Analytics the KUSTO query language can be used to query the forwarded log entries and we can create alert rules based on custom queries.
Recently I have been troubleshooting a nasty Windows Hello for Business problem which prevented all users in a tenant from resetting their Windows Hello for Business PIN’s on Azure AD joined devices while getting the error CAA20004.
Issue # When clicking on “I forgot my PIN”:
After completing the account sign-in and MFA challenge the Error CAA20004 came up:
Troubleshooting # The Azure AD Portal shows us “Failure reason: other”.
While recording all the https traffic to Microsofts oauth2 endpoint with Fiddler this finally unveils usable information:
AADSTS65001: The user or administrator has not consented to use the application with ID ’ 9115dd05-fad5-4f9c-acc7-305d08b1b04e’ named ’ Microsoft Pin Reset Client Production’. Send an interactive authorization request for this user and resource.
The error indicates that an application registration is missing in the tenant for the application “Microsoft Pin Reset Client Production”
Solution # After a short search I found a matching Microsoft docs article. Instead of reading through the whole article the only thing I needed to do was consenthing to the: Microsoft PIN Reset Service production application and also for the Microsoft PIN Reset Client production