To solve this I built a module that does just one thing

Uninstall-Graph

You can get it at uninstall-graph.merill.net.

It basically runs through multiple times to uninstall all the modules and then finally cleans out the folders for the ones that are stubborn.

Remember to restart a fresh PowerShell session after running this.

Why is the Graph PowerShell module so special?

For starters, some graph modules depend on other graph modules then you have various non-Microsoft modules (like Maester) that rely on Graph modules.

This means uninstalling them is not as simple as running

Uninstall-Module Microsoft.Graph

You would typically see something like this error.

PackageManagement\Uninstall-Package : The module 'Microsoft.Graph.Applications' of version '2.12.0' in module base folder 'C:\Program Files\WindowsPowerShell\Modules\Microsoft.Graph.Applications\2.12.0' cannot be uninstalled, because one or more other modules 'Microsoft.Graph' are dependent on this module. Uninstall the modules that depend on this module before uninstalling module 'Microsoft.Graph.Applications'.

Why would you need to uninstall Microsoft Graph in the first place?

Well the most common reason is that you end up with different versions of the various Graph PowerShell modules and one day you will be hit errors like this

Could not load file or assembly 'Microsoft.Graph.Authentication, Version=2.8.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

or

Import Graph module fails with Could not load file or assembly 'Azure.Core, Version=1.39.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' or one of its dependencies. The system cannot find the file specified

or something similar.

So getting back to a clean slate and then installing the modules afresh is my preferred solution for this problem.

I’m keen on having this module address all the edge cases when it comes to uninstalling the Graph PS modules. So if you come across any issues please raise them on GitHub. Thanks!

• Riverside Standard (I got a 50% discount coupon so paid $90 for first year)

• Podcast Chapters which was a one time $20.

• Fedica - for cross posting podcast clips ($10 per month)

I run a weekly podcast with a new guest for each episode.

This is a solo effort where I do EVERYTHING (schedule, interview, edit, publish).

So I am constantly scheduling, recording, editing and publishing my podcast. Even reaching out and keeping track of the people I reached out is crazy since I might have DMd on LinkedIn, Twitter, Email, Teams/Slack.

I tried various note taking apps and calendar integrations like Notion but couldn't get a handle on things.

What finally worked for me is

superthread.com

Using it I was able to create a kanban where I progressed each guest through a workflow. They went from

• Backlog - People I want to get on the podcast

• Scheduling - People I've reached out to (this card has status us Invited/Agreed) if they say yes I tag as Agreed so I know I can schedule them.

• Scheduled - This is once I have them locked in for a date

• Recorded - These are ones I've completed recording but haven't edited or published

• Editing In Progress - These are ones that I'm editing

• Published - These are ones that have gone out to everyone.

Superthread has a rich notes page that is linked to the card for each person/episode. This way I can quickly drill into the note where I store questions and add in notes during the meeting.

I like it so much I use it for tracking my content ideas and ideas for the apps I’m building.

Podcast Editing Process

Okay, now to the actual editing and publishing process (I use Riverside to edit)

I publish video to YouTube and Spotify and audio to everywhere else. I use Substack as my pod website, audio file host.

Here's my workflow (I keep this in an .md file and keep refining them each week (One day I'm hoping to build an AI agent that automates all this)

# Podcast creation process

## Edit in Riverside

- In Riverside, edit the podcast by listening to the audio and making cuts as needed.
- Use the smart scene option to generate autoamatic multicam cuts.
- Change video layout (eg me scratching my head)
- If track is not in sync with video click through and add a delay to the track.

✅ Export a 4k version of the video (only use the remove watermark option on export).

## DaVinci Resolve

- Import the video into DaVinci Resolve.
- Use the Assets in this folder (intro, outro etc)
- Take two or three interesting clips from the conten and insert them at the beginning.
- The YT thumbnail should be relevaant to the first clip or overall theme of the podcast.

✅ Render YouTube 4k preset and audio only with mp3 audio.

## Titles, Chapters and Description

- Upload audio track to substack to create transcript and download it.
- Use the prompt.md in Gemini to generate titles, chapters and description.
- Create a chapters.csv file with the chapters and timestamps generated by Gemini.
- Use Podcast Chapters (https://chaptersapp.com/) and import the mp3, csv and add images and chapter titles.

Below is the the prompt.md file that I use with Gemini gemini.google.com

prompt.md

Create a viral heading for a youtube video from this podcast transcript. Make it short and exciting and create variations that will incite fomo or curiosity or controversy. 

Give a short thumbnail title as well as a video title.

Also include a summary of the podcast and create highlevel chapter headings. Include the timestamp (minutes and seconds) for the chapter heading so it can be used in youtube and podcast chapters. It should be like this: 
00:00 Intro

Make sure the chapter headings are clean and simply and start accurately with the right time stamp and sentence

Also give me the chapters in the format of chapter name, timestamp and in a csv format so I can copy and paste into a csv file.



------------------------------------------------------------------------------------
Template for Notes
------------------------------------------------------------------------------------

# 🎙️ Entra.Chat - https://entra.chat

<description>

Subscribe with your favorite podcast player or watch on YouTube 👇

——
### About <Name>

<Description>

LinkedIn - https://linkedin.com/in/

——

🔗 Related Links

• Title - https://

——

📗 Chapters

00:00 Name

——

### Podcast Apps

🎙️ Entra.Chat - https://entra.chat

🎧 Apple Podcast → https://entra.chat/apple

📺 YouTube → https://entra.chat/youtube

📺 Spotify → https://entra.chat/spotify

🎧 Overcast → https://entra.chat/overcast

🎧 Pocketcast → https://entra.chat/pocketcast

🎧 Others → https://entra.chat/rss

——

### Merill's socials

📺 YouTube → [youtube.com/@merillx](https://youtube.com/@merillx)

👔 LinkedIn → [linkedin.com/in/merill](https://linkedin.com/in/merill)

🐤 Twitter → [twitter.com/merill](https://twitter.com/merill)

🕺 TikTok → [tiktok.com/@merillf](https://www.tiktok.com/@merillf)

🦋 Bluesky → [bsky.app/profile/merill.net](https://bsky.app/profile/merill.net)

🐘 Mastodon → [infosec.exchange/@merill](https://infosec.exchange/@merill)

🧵 Threads → [threads.net/@merillf](https://www.threads.net/@merillf)

🤖 GitHub → [github.com/merill](https://github.com/merill)

I download the transcript generated by Substack (they do it for free!) and copy/paste the prompt and attach the file to create the notes as well as the csv file for burning the chapter markers and notes into the mp3 file (using https://chaptersapp.com/).

Once I burn the .mp3 with chapter notes I re-upload it to Substack (this is the version that gets sent out).

Podcast clips

I create about 5-6 short clips out of the recording. Because I don't have the premium version in Riverside I create a portrait video version in Riverside, export it and then use Da Vinci to cut out about 5-6 short clips that are 1-2 min long.

I then use Fedica (a paid service) to schedule and publish one clip every day of the week (plus I sprinkle some for future dates). These get cross posted to all the social media including YT Shorts and TikTok.

So what do you think? What areas would you improve on this? Anything that I should drop? Things I should do to improve the process?

Recently, I posed this question in a poll on LinkedIn and X:

What do you think of using Apps (Service Principals) as a 'Plan B' emergency access account?

Here’s the combined results from the 817 votes.

This split reflects the nuanced nature of the topic, with no clear consensus. In this blog post, I’ll break down the approach of assigning a Global Administrator (GA) role to an SP for emergency access, analyze the pros and cons based on community feedback, and share my personal take on the matter.

Why emergency access accounts?

Getting locked out of your Entra tenant is the stuff of nightmares for any IT administrator or security professional. Whether it's a misconfigured Conditional Access policy, a lost or broken multi-factor authentication device, or an expired credential, the inability to access your critical cloud environment can bring operations to a grinding halt.

Microsoft’s recommendation has been to set up a "break-glass" or "emergency access" user account. These highly privileged accounts are kept under strict control, excluded from standard Conditional Access policies and secured with robust methods like FIDO2 keys stored securely offsite. Their usage is heavily monitored and alerts are triggered immediately upon sign-in.

But in the evolving landscape of cloud identity, a new idea has surfaced, sparking considerable debate: What about using an Application (specifically, a Service Principal) with Global Administrator permissions as an emergency access mechanism?

This approach hinges on the fact that Service Principals authenticate differently than users, often using certificates or secrets, which bypasses user-focused Conditional Access policies. The idea is to create a Service Principal, grant it the Global Administrator Entra role, and secure its credentials (ideally a certificate on a hardware security module like a YubiKey) and monitor its activity rigorously.

The earliest reference for this approach that I’ve seen is this reddit post from 2023 ‘Using Service principal as Azure AD Break glass access’. At that time I dismissed the idea, but lately I’ve seen quite a few posts on various forums where admins had locked themselves out of their tenant and it got me thinking about using SPs.

So that’s where the poll came in → "What do you think of using Apps (Service Principals) as a 'Plan B' emergency access account?" The results, based on 817 votes, were quite telling:

• Yes: 165 (20.2%)

• No: 327 (40.0%)

• Maybe: 325 (39.8%)

The poll results clearly indicate a significant level of hesitation or outright opposition to this approach. The combined "No" and "Maybe" votes represent nearly 80% of the responses, suggesting that while there's some interest or recognition of potential edge cases ("Maybe"), the majority are either against it or highly skeptical.

Let's delve into the lively discussion that followed to understand the reasoning behind these votes.

Analysis of Community Responses: The Pros and Cons Unpacked

The comments on both platforms provided invaluable context to the poll numbers, highlighting strong opinions and practical experiences.

Arguments Against (The "No" Votes and Skeptical "Maybe"s):

The most prevalent concerns centered around security risks and complexity:

1. Lack of MFA: A major drawback repeatedly cited is that Service Principals cannot natively perform multi-factor authentication in the same way a user account does. While certificate-based authentication is strong, it's seen by many as not a direct equivalent to user+MFA, leaving a perceived gap.

2. Credential Management Hell: The security of a Service Principal relies entirely on the security of its credentials (secrets or certificates). Many respondents expressed concern that organizations already struggle with managing user credentials and application secrets. Adding a highly privileged SP with poorly managed credentials (e.g., secrets stored insecurely, certificates expiring or on insecure devices) introduces a significant attack vector. Mathias Dumont and Alexander specifically highlighted this risk.

3. Privilege Escalation Path: Granting a Service Principal Global Administrator is immensely powerful. Several folks, including Jordan Pitcairn, Stian Andresen Strysse, and Graham Gold, pointed out that the App Administrator and Cloud Application Administrator roles have the power to manage credentials for Service Principals. If these admin roles are not tightly controlled (e.g., via PIM), an attacker compromising one of these roles could potentially create new credentials for the break-glass SP and gain GA access without needing to compromise the original secured credential. Graham Gold explicitly stated, "App Administrator = Tier 0... If not gated with PIM and approvals, you’re handing out a backdoor to GA."

4. Complexity and "Hackiness": Niclas Madsen strongly felt this is a "bad design and a 'hack'," adding unnecessary complexity that introduces risk. Jesper Joachim Raarup echoed this, arguing it adds another "angle of attack" and distracts from fundamental security hygiene. The KISS (Keep It Simple, Stupid) principle was invoked by Kévin KISOKA and Amanda Wuest.

5. Lack of Dedicated Controls: Jackson Sweeney and D Lind highlighted the lack of granular controls like Restricted Administrative Units (RAUs) for Service Principals, making it harder to isolate and protect them compared to privileged user accounts (though RAUs for users also have limitations).

6. Workload Identity CA Dependency: While Conditional Access policies for Workload Identities exist and were mentioned as a potential mitigation (Eric Mannon, Tom Camps, Michaelsoft Binbows), many organizations haven't implemented them, or they aren't as mature as user CA policies. Relying on this for the security of a break-glass SP is seen as risky if the organization's maturity isn't high enough (Graham Gold).

7. Doesn't Solve Core Problems: Some felt this approach doesn't address the root cause of lockouts (poor policy design) or the fundamental need for robust break-glass user accounts (Alexander, John Hoddinott).

Arguments For or Accepting in Specific Cases (The "Yes" Votes and Accepting "Maybe"s):

Despite the strong opposition, there were compelling arguments and scenarios where this approach was seen as viable or even necessary:

1. Bypassing Restrictive CA Policies: The most significant practical advantage mentioned by proponents like Stian Andresen Strysse, Gabe Delaney, and Roel van der Wegen is that a Service Principal can circumvent user-based Conditional Access policies that might block all user sign-ins, including traditional break-glass users (if they weren't properly excluded or if the exclusion failed). Gabe and Roel shared real-world experiences where they used application permissions to regain access to locked-out tenants.

2. MSPs and Scaling: Roel made a specific case for MSPs managing hundreds of tenants. Managing physical FIDO keys for break-glass users across numerous clients becomes logistically challenging. A multi-tenant application approach, with careful credential management and monitoring, could be a more scalable "Plan B" for MSPs, though this was debated due to supply chain risks (Jesper Joachim Raarup).

3. Requires a Robust Framework: Many "Maybe" votes and some "Yes" arguments (Gabe Delaney, Kirby Clements, Michael Cramer) stressed that this isn't something to be done lightly. It requires a dedicated framework including:

   • Strict credential management (HSM, certificates).

   • Comprehensive monitoring and alerting on any activity or modification of the SP or its credentials.

   • Clear boundaries on the SP's permissions (though for GA break-glass, this is inherently broad).

   • Protection against accidental modification.

4. Microsoft Should Build It: Michael Cramer proposed that Microsoft should create a built-in, purpose-designed recovery account feature in Entra ID, secured by design (e.g., mandatory multiple FIDO keys, automatic CA exclusion, special auditing), rather than leaving admins to implement potentially risky workarounds. Kirby Clements agreed, suggesting Microsoft could formalize this by restricting management of such SPs to only GAs or a new dedicated role.

5. Better Than Poor User Break-Glass: Some implied that a well-implemented SP break-glass could be more secure than traditional user break-glass accounts secured only with password managers or single, easily compromised MFA methods.

Conclusion from the Responses

Based on the poll results and the detailed comments, the community sentiment is clear: Using a Service Principal with Global Administrator rights as a general break-glass emergency access account is largely viewed with skepticism and concern (the combined 80% "No" and "Maybe" votes).

The primary reasons for this apprehension are the inherent security challenges of managing Service Principal credentials, the potential for privilege escalation through less-controlled App Admin roles, the lack of native user-like MFA, and the added complexity compared to traditional methods.

While there's recognition that this approach could be useful in specific, dire lockout scenarios (especially those caused by CA policies affecting users) or perhaps for specific operational models like MSPs, the consensus is that the security risks, if not mitigated by an exceptionally robust security framework, monitoring, and strict controls over App Admin roles, outweigh the potential benefits for most organizations. The "Maybe" votes indicate that for some, the idea isn't outright rejected but is contingent on significant safeguards and potentially official tooling or guidance from Microsoft.

Ultimately, the discussion highlights a perceived gap in current Entra ID capabilities for truly resilient emergency access that can bypass even fundamental policy misconfigurations, alongside a lack of organizational maturity in securing workload identities compared to user identities.

My Personal Opinion

(Please note: This is my personal opinion and does not represent the official stance of my employer, Microsoft.)

The poll responses definitely opened my eyes to new risks I hadn’t considered before as well as concrete examples of the usefulness when managing a large number of tenants like MSPs (or even an Enterprise with 100s of tenants).

I lean towards "Yes" for specific types of tenants, and this stance is based on a few key observations:

1. Increased Lockout Vectors: It's true that the ways to lock yourself out of a tenant have proliferated. Beyond losing a password/MFA, misconfigured Conditional Access policies (blocking all access), authentication strengths, or even Passkey profiles can render all user accounts inaccessible. The risk of an accidental, tenant-wide lockout seems higher than before.

2. Difficulty of Recovery: As this Reddit post illustrates, recovering access to a locked-out tenant via Microsoft Support is, by design, a difficult and time-consuming process. And it absolutely should be hard. Microsoft must rigorously verify identity before handing over control of a tenant to prevent threat actors from easily claiming ownership. However, for legitimate administrators facing a crisis, this process can be agonizingly slow (or impossible if you don’t have any form of mechanism to show concrete proof linking you to the tenant).

3. Tenant Type Matters:

   • Entra ID Free Tenants, M365 Dev tenants: (Yes) These tenants don’t have a clear way to prove ownership. No linked credit card etc. Although you can’t create new M365 Dev tenants (the free ones), for those who already own them they are indispensable and would be a huge loss if you lost access. Plus, today it’s almost impossible to recover them if you lock yourself out.

   • Customers with Enterprise Agreements and dedicated Microsoft account teams: These organizations have direct access to Microsoft support channels and resources that can potentially expedite recovery in extreme circumstances. The need for a self-service, potentially risky workaround is diminished (Maybe from me).

   • Production tenants where your CEO can call Satya on the phone: Do you even need break-glass accounts? 😂

Creating a Break-Glass Service Principal account

If I were to create a Service Principal for break-glass (for appropriate tenant types), here is how I would configure it:

• Create Emergency Access Service Principal: A dedicated app (jury is out on single tenant vs multi-tenant app).

  • Multi-tenant SPs cannot be blocked by Workload ID CA policies in other tenants (today).

  • Workload ID still requires a seperate license so not many tenants have this proactively. If you do have such a policy you will need to exclude this account from the workload ID CA policy.

• Grant Entra GA role: Why such a wide role? It’s hard to predict what can go wrong. The last thing you need is to do all the prep work but the account is not usable to help with tenant recovery.

• Secure Credentials with HSM Certificate: Crucially, use certificate-based authentication. Generate the certificate signing request (CSR) on a local Hardware Security Module (HSM), such as a YubiKey or a dedicated hardware appliance. The private key never leaves the HSM.

• Robust Monitoring: Implement immediate and high-priority alerting whenever this Service Principal signs in or is used. This requires integration with a SIEM like Microsoft Sentinel or a dedicated monitoring system. KQL queries watching Entra ID sign-in and audit logs would be essential. Alerts should go via multiple channels (email, SMS, SOC alert). A GitHub Action or similar automation could be used to trigger checks and alerts.

• Redundancy for Monitoring: Have a separate, independent system (perhaps a third-party monitoring tool outside of Entra ID control that the SP couldn't easily disable) that performs a "heartbeat" check to ensure your primary monitoring and alerting systems (like the GitHub Action) are still operational. If the heartbeat stops, it triggers an alert.

Someday I hope to build a PowerShell module or an app that makes it super easy to set this up correctly and manage it. 😉

References and further reading

• How to Configure an Emergency Access App in Entra ID - Lokesh

• M365 Breakglass Maturity Model - Graham Gold

• Attacker’s Breakdown: M365 Break Glass Maturity - Elli Shlomo

There's not much meat in it but it hints at Microsoft working on making it available again (don't quote me on this).

You can read the announcement at Exciting updates coming to the Microsoft 365 Developer Program

I like some of the improvements like being able to add new licenses to the tenant, etc.

Hopefully we’ll see more details coming through and this launching.

Also check out Andrew's hot take 👇

I was fixing a Maester bug and thought it would be good to share my process for going about it.

We start off with a Maester bug (Issue with MT. 1016 #804). In this instance the tenant had a CA policy for All Users but did not have one explicitly targeting guests.

While it’s alway a better practice to have a seperate set of policies for guests, Maester should not penalise them for this. Technically they are in the clear since MFA being applied to all users including guests.

Now the existing code for this check was getting too long and adding more parts to this expression was going to make it hard to maintain.

GitHub Copilot to the rescue! I prompted and got a much cleaner implementation and was able to add the additional check.

Now we need to test if it’s working as expected. This involves creating a bunch of CA policies to test and how do we make sure it keeps working with future changes?

That’s where Pester tests come in. I created a bunch of Pester tests to simulate various types of CA policies. Some targeting all users, others targeting just guests and also checking if any type of guest had been excluded.

How I went about this copying out the json of the CA policy. This one here targets guests but excludes the B2B Collab Guest type. This type of policy should be failed by Maester since the tenant is missing an important chunk of guest users being required to have MFA.

• Maester Test: Test-MtCaMfaForGuest.ps1

• Pester Test File: Test-MtCaMfaForGuest.Tests.ps1

So far I’ve been mostly using GitHub Copilot and others to do specific tasks but I’m now starting to have design discussions and conversations to look for areas that I might be missing (or to play devils advocate).

I also pitted the LLMs against each other. Here’s a comparison.

GitHub Copilot is not just for code, it’s great for design thinking too.

The last one I tried was Google Gemini’s Deep Research which looked up over 190+ sites including Microsoft docs, LLM docs to provide a complete four page report. Very impressive.

Microsoft Community

Utilities that anyone in the Microsoft community will find useful.

• 🤖 lokka.dev - An AI agent tool that brings the power of Microsoft Graph to AI agents

• ⚡ cmd.ms - Your Microsoft Cloud command line.

• 🔥 maester.dev - Microsoft test automation framework + security analyzer.

• 🔎 akaSearch.net - Community contributed search engine for aka.ms links

• 💬 Microsoft 365 Message Center Archive - Searchable archive of all Microsoft 365 Message Center posts.

• 🎓 Refined Microsoft Learn - Browser extension to make Microsoft Learn distraction free and focus on the content.

• 🦋 bluesky.ms - Find Microsoft folks on Bluesky.

Microsoft Entra

Utilities for Microsoft 365 and Microsoft Entra admins and cybersecurity folks.

• 🗞️ Entra.News - Stay up to date on all things Entra with this weekly newsletter with the latest updates on Microsoft Entra from both Microsoft and the community.

• 🎧 Entra.Chat - A weekly podcast on Microsoft Entra.

• 💪 idPowerToys.merill.net

  • Microsoft Entra related power toys including a Conditional Access visualizer and Entra mind maps.

• 📮 aka.ms/AppNames

  • Repository hosting a daily updated csv/json of Microsoft first party app names and their GUIDs

• 🗃️ Entra Exporter

  • PowerShell module that exports all the config and data of a Microsoft Entra tenant.

• 👮 Azure AD Assessment

  • Guidance to assess the health of an Azure AD tenant and provide best practice guidance / recommendations.

• 🔨 MSIdentityTools

  • Collection of useful cmdlets for common Azure AD functionality

Microsoft Graph

Utilities for everyone that works with Microsoft Graph and Graph PowerShell.

• 🩻 Graph X-Ray

  • Fiddler for Microsoft! Convert your actions in the Azure Portal to Graph PowerShell commands.

• 🦒 Graph Permissions Explorer

  • Site that shows all the Graph APIs and data exposed for a given Graph Permission.

Learn more at https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-track-linkable-identifiers

🚀 I just launched my weekend hack project 🦋. With Twitter becoming unusable a whole heap of the Microsoft community is now on Bluesky and having a blast.

I made Bluesky.ms to make it easy to find each other. If you are already on Bluesky, add your profile so others can find you.

If you haven’t started on Bluesky here’s a primer.

🦋 What is Bluesky?

Bluesky is a social app that is designed to not be controlled by a single company. It’s an open network and a version of social media where it’s built by many people, and it still comes together as a cohesive, easy-to-use experience.

✅ Where do I sign up

• Web → Bluesky Web app

• iPhone → Bluesky iOS app

• Android → Bluesky Android app

🚀 How do I find people?

Rebuilding all the folks you know or finding people with similar interests take time. Here are some neat ways to bootstrap the process.

✅ Starter Packs

These are lists of Bluesky users that you can bulk follow. The starter packs help you quickly get started on Bluesky and follow folks in the Microsoft community.

See bluesky.ms/starterpacks for the latest list.

You can also find other non-Microsoft starter packs over at blueskydirectory.com/starter-packs

✅ Help others find you

If you write about Microsoft content and want others to find you, add your profile over at bluesky.ms.

This crowd sourced database welcomes everyone. If you find it’s missing anyone please feel free to add them in.

Let’s build some awesome open communities!

What are the minimal permissions required to read group membership for a user?

The ask was for an application so we need to grant Application permissions and the first attempt was with User.Read.All permission.

When you run this query you do get the groups the user is a member of but it is limited to just the group id. The permission is not enough to get the name of the group.

Invoke-GraphRequest -Uri 'https://graph.microsoft.com/v1.0/users/merill@elapora.com/memberOf/microsoft.graph.group?$select=displayName' | ConvertTo-Json

Now this would be perfectly valid if your app needed just the ID of the group.

However if the app needs the name and other details of the group then you will need to grant additional permissions.

My immediate thought was to grant Group.Read.All but this is a scary permissions, especially when it is an application permission. This will grant tenant wide access to read any information stored in a Group or Team. This includes files and messages in a channel.

So what’s the least privilege permission that will grant access to just the display name?

As of today, the answer is GroupMember.Read.All permission. The reason I say “as of today” is because the permissions are constantly being updated and new permissions are being added, so it is always a good idea to check the docs for the least privilege permissions. Since I did this frequently I built a site to easily show the least privilege permissions Microsoft Graph permissions reference.

The request was to find all the members in an Administrative Unit with a specific value in the extensionAttribute10 property.

However this query errored out as an unsupported query.

❌

/directory/administrativeUnits/<guid>/members?$filter=onPremisesExtensionAttributes/extensionAttribute10 eq 'ABC'&$count=true

code: "Request_UnsupportedQuery",
message: "Property 'extensionAttribute10' does not exist as a declared property or extension property."

The fix was fairly simple, just add /microsoft.graph.user at the end of the url path.

✅

/directory/administrativeUnits/<guid>/members/microsoft.graph.user?$filter=onPremisesExtensionAttributes/extensionAttribute10 eq 'ABC'&$count=true

So let’s break down the fix.

Adding /microsoft.graph.user at the end of url path tells Graph API to only return members that are of type user. You can then apply all the available user object property filters including filtering by extensionAttribute10.

Why did the original query fail?

The administrativeUnit object like the group object can contain different types of directory objects.

Here’s a visual representation of the directory object inheritance hierarchy.

When you create a group or an administrative unit, you can add users, devices, and other groups to it. Each of these objects will have their unique set of properties.

Not all object types inheriting from DirectoryObject can be added to groups and administrative units.

When you query for members in a group or an administrative unit, you are querying against all the objects in the container.

So while you can query against special properties like id and displayName you cannot directly query against any of the other properties.

This explains why a query for displayName will work without qualifying the query with the object type.

✅

/groups/<guid>/members?$filter=displayName eq 'John'&$count=true

In our original query, not all the member object types in the administrativeUnit object would have a declared property called onPremisesExtensionAttributes. Instead it is a declared property of the user object.

Once you qualify the query to filter by the microsoft.graph.user object, the query works as expected.

To close it off with another example, this query for groups will fail for the same reason.

❌

/groups/<guid>/members?$filter=onPremisesExtensionAttributes/extensionAttribute10 eq 'ABC'&$count=true

Which can be fixed by qualifying the query with the microsoft.graph.user object type.

✅

/groups/<guid>/members/microsoft.graph.user?$filter=onPremisesExtensionAttributes/extensionAttribute10 eq 'ABC'&$count=true

Here’s the TLDR;

Hope this helps!

Invoke-GraphRequest -Uri 'beta/users' -OutputFilePath ./user.json

or

Invoke-GraphRequest -Uri 'beta/users' | Out-File -FilePath ./user.json

Surprisingly, the answer is that Out-File is the fastest

Here’s what I got when I ran the two commands:

Measure-Command { Invoke-GraphRequest -Uri 'beta/users' -OutputFilePath ./user.json }

TotalSeconds      : 3.1084942

Invoke-GraphRequest -Uri 'beta/users' | Out-File -FilePath ./user.json

TotalSeconds      : 0.5016927

That got me thinking. Does the performance change much when using different output types?

Measure-Command { Invoke-GraphRequest -Uri 'beta/users' -OutputType Json | Out-File ./user.json }

TotalSeconds      : 0.4035508

Here’s what I get when I ran the same command with different output types. There was no clear winner and they all ranged between 0.2 and 0.5 seconds.

The catch is that device filter can only be applied to managed or hybrid joined devices.

It’s a limitation since you can’t use it with unmanaged devices, but that is exactly the reason why it is better to use it over device platform when your CA policy is targeting managed devices.

The device platform relies on the user agent string which can be easily spoofed. Nicola has a good write up on this over at Bypassing Conditional Access Device Platform Policies

In some instances, it was the devs in the org asking for this, in other instances it was the application vendor.

Here are some things to watch out for 👇

Multi-tenant apps are meant for ISVs and SaaS vendors to create an instance of an app in ‘their own tenant’. Examples of such apps are ServiceNow and SalesForce.

When an app is created as a multi-tenant app, ANY user from ANY Azure AD tenant can visit the app’s url and sign in.

If you create a multi-tenant app in your corporate tenant and apply a conditional access policy. The policy only applies to users and guests in your tenant.

⚠️ I’ll repeat ➟ your CA policies do not apply to users signing into your multi-tenant app in their own tenant.

So, what is the general rule of thumb that Azure AD admins and cybersecurity teams should follow?

If the app is from a vendor/SaaS provider:

✅ Add the app to your tenant from the Azure AD Application Gallery

✅ If the app is not in the gallery, you as the customer can request the vendor to get their app listed on the Azure AD app gallery

✅ If app gallery is not an option, request the vendor to create the app in their own tenant. Use the admin consent model to add the app to your tenant.

✅ If the only option provided by the vendor is to create the app in your tenant, push for the vendor to allow you to create a single tenant app.

If the app is developed by devs in your org and is only meant for users in your own org.

✅ Ask why the dev needs this to be a multi-tenant app?

✅ Ask if the devs have implemented appropriate checks to prevent sign-ins from other tenants.

There are many valid scenarios for creating multi-tenant apps in your tenant, including

✅ You are a SaaS vendor or ISV and you create and publish apps that Azure AD customers can consume

✅ You manage multiple Azure AD tenants in your org and you need a single service principle (workload identity) to access the other tenants (e.g. automate DevOps tasks across your tenants)

Here are some further reading on the topic of multi-tenancy. These are meant for devs however its good reading for admins to appreciate what it takes to build a least-privilege multitenant app.

👉 https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/

👉 https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant

Note: This MSRC blog post provides additional guidance on how you can review the multi-tenant apps in your tenant and switch them to a single tenant app if multi-tenant is not a requirement.

Guidance on Potential Misconfiguration of Authorization of Multi-Tenant Applications that use Azure AD - MSRC Blog - Microsoft Security Response Center

To avoid this, you can register your own app for use with Microsoft Graph PowerShell. This allows you to have more granular control.

Here are the steps to go about setting it up.

• Browse to Entra > App registrations [adappreg.cmd.ms] > New Registration

  • Name: Microsoft Graph PowerShell - High Privilege admin use only (<- Give a meaningful name)

  • Account type: Accounts in this organization directory

  • Redirect URI:

    • Select Public client/native from the drop down

    • Uri: http://localhost

  • Click Create

That’s it!

Now you can use this app instead of the default one by connecting with

Connect-MgGraph -ClientId <Your new app clientid> -TenantId <your tenant id>

Here are a few screenshots to help guide you.

Remember to use the ClientId and TenantId parameters when signing in.

Restricted user access

I would also recommend limiting the users that have access to these Graph PowerShell applications. To do this browse to the Enterprise Applications [adapps.cmd.ms](https://adapps.cmd.ms] blade, select the app and in Properties set Assignment required? to Yes. Then grant access to the required folks from the Users blade.

Windows PowerShell 5.1

The steps above will get you working with PowerShell 7, which is what you SHOULD be using. In the unfortunate event that you are stuck with Windows PowerShell 5.1 you need to do one more thing.

• Open the app you just created in App registrations [adappreg.cmd.ms]

• Select Authentication

  • Check https://login.microsoftonline.com/common/oauth2/nativeclient

  • Click Save

I created this view since the Microsoft docs don’t include all this information in a single view (especially the Custom Security Attributes).

Source: Comparison of extension types - Microsoft Learn

¹ Multi-value support in directory extensions is limited to attributes synchronized from on-prem. It is not possible to create new multi-valued directory extensions in Azure AD.

I’m a command line guy and hate having to click to get to various Azure AD pages. Over time I created these shortcuts and thought you might find them helpful.

Here is how it works. Open a new tab and type aka.ms/ad/{command}

Where shortcut is one of the commands below.

aka.ms Command Portal Blade aka.ms/ad/ca ca Conditional Access aka.ms/ad/pim pim Privileged Identity Management aka.ms/ad/users users Users aka.ms/ad/groups groups Groups aka.ms/ad/devices devices Devices aka.ms/ad/apps apps Enterprise Applications aka.ms/ad/appreg appreg Application Registrations aka.ms/ad/auth auth Authentication Methods Policies aka.ms/ad/legacymfa legacymfa Legacy MFA aka.ms/ad/guests guests Guest Access Settings aka.ms/ad/logs logs Sign in Logs aka.ms/ad/xtap xtap Cross Tenant Access Settings aka.ms/ad/roles roles Azure AD Roles aka.ms/ad/sspr sspr Password Reset aka.ms/ad/security security Security aka.ms/ad/mfaunblock mfaunblock MFA Unblock aka.ms/ad/reviews reviews Access Reviews aka.ms/ad/score score Secure Score aka.ms/ad/license license Licenses aka.ms/ad/synclog synclog AAD Connect Sync Errors aka.ms/ad/adfslog adfslog ADFS Log aka.ms/ad/consent consent Consents and Permissions aka.ms/ad/support support Support aka.ms/ad/list list List all these shortcuts

If you liked those here are some of my favourite Identity related shortcuts.

aka.ms Page aka.ms/azad Azure AD Portal aka.ms/sspr Self Service Password Reset aka.ms/mysecurity My Security aka.ms/myapps My Apps aka.ms/my-account My Account aka.ms/my-groups My Groups aka.ms/my-access My Access Packages aka.ms/mystaff My Access Packages aka.ms/mfasetup Alternative for My Security aka.ms/ge Graph Explorer aka.ms/ge Intune

Have I missed anything? Have new suggestions? Let me know at twitter.com/merill.

Hey folks, I took part in a hackathon last week and built the Graph PowerShell Conversion Analyzer. Hopefully, this will help a bit as you upgrade your AzureAD & MSOnline PowerShell scripts to Graph PowerShell.

It’s very rough right now but I would love to hear your feedback.

Try it out at https://graphpowershell.merill.net

You start by pasting in one of your old scripts that you want to upgrade to Graph PowerShell and clicking the Analyze button.

This will generate a report of all the Azure AD PowerShell and MSOnline commands that were found along with a mapping to its corresponding Graph PowerShell command. The sample generated will try to map the parameters to the new command.

This is where I still need to do a lot more work to make it really useful.

Where possible you also get direct links to both the Graph PowerShell command reference as well as the Graph API reference (which usually has more relevant info).

No more hunting around and searching the docs!

The last bit is where you the community can really help us and each other out. We’ve started an open repository of sample Graph PowerShell scripts at https://aka.ms/graphsamples

We would love to make this the largest collection of Graph PowerShell sample scripts. It’s open to everyone to contribute so please share your scripts (even one-liners).

Let me know what you think. If you have any ideas on how this can be improved I’m all ears!

_Expect simple name=value query, but observe property ‘assignedLicenses’ of complex type ‘AssignedLicense’.

    ❯ Get-MgUser -Filter 'assignedLicenses/$count eq 0'
    Get-MgUser_List1: Expect simple name=value query, but observe property 'assignedLicenses' of complex type 'AssignedLicense'.

The fix is quite simple. Set the ConsistencyLevel header to eventual and pass in a variable to store the count of the result set and you are good to go.

    ❯ Get-MgUser -Filter 'assignedLicenses/$count eq 0' -ConsistencyLevel eventual -CountVariable licensedUserCount -All
    
    Id                                   DisplayName     Mail                           UserPrincipalName
    --                                   -----------     ----                           -----------------
    1468b68b-8536-4bc5-ab1f-6014175b836d merill-fdo      merill-fdo@yopmail.net         merill-fdo_yopmail.net#E…
    160f8064-a20c-4236-bdf4-3393003e916b Ezra Brand      ezra@fdo.net                   ezra_fdo.net#EXT#@pora.n…
    37e5a3d1-f92b-4a12-bb35-91bf80969810 Joshua Sal      user2@fakedomain.com           user2_fakedomain.com#EXT…
    5c8537e4-7d7f-4920-a921-382d91fa53fd Fake Damain     user@fakedomain.com            user_fakedomain.com#EXT#…
    640885de-9652-4fb2-8a87-963cc2f599a0 Chris Green     chris.green@yopmail.net        chris.green_yopmail.net#…

Azure AD’s ‘Nudge’ feature allows you to run a Microsoft Authenticator registration campaign that interrupts a user signing in with SMS and nudges them to set up the Authenticator app.

If you set this up but are not seeing users being nudged/prompted with the ‘Improve your sign-ins’ message its most probably because you have a conditional access policy for the ‘Register security information’ page.

The nudge screen will not be displayed if a user’s sign in is in scope of a conditional access policy that blocks access to the “Register security information” page.

Let’s take for example you have a conditional access policy that blocks users from accessing the ‘Register security information’ page over the internet and limits access to your company’s corporate (local area network).

When a user tries signing in over the internet and uses SMS they will not be shown the nudge (Improve your sign-ins) screen.

Let’s say for arguments sake if Azure AD were to send them to the page where they can set up security info. If we allowed the user to set up new auth methods it would bypass your conditional access policy defined above. Alternatively, it wouldn’t be a pleasant experience if we redirected the user to the nudge screen and then showed them a CA policy error when they tried to set up a new auth method.

Instead, we simply avoid showing the nudge prompt if the current sign-in is not in scope for the ‘Register security info’ conditional access policy.

Hope that makes sense.