charlie.tools

Auditing Microsoft 365 admin role assignments with Graph PowerShell

Sun, 12 Apr 2026 00:00:00 GMT

If you inherited a tenant that has been around for a while, you already know the pain: the Entra admin center shows active assignments, but it hides group-based ones behind an extra click and sends you to a second blade for PIM-eligible roles. For a quarterly review that needs to go to auditors, you want one CSV.

Here is the Graph PowerShell script I run the first week of every quarter. It walks every directory role, resolves group members, and flags which assignments are PIM-eligible vs. active.

#Requires -Modules Microsoft.Graph.Identity.Governance, Microsoft.Graph.Groups

[CmdletBinding()]
param(
    [string]$OutputPath = "./admin-roles-$(Get-Date -Format 'yyyy-MM-dd').csv"
)

Connect-MgGraph -Scopes 'RoleManagement.Read.Directory', 'Directory.Read.All' -NoWelcome

$roles = Get-MgRoleManagementDirectoryRoleDefinition -All
$results = foreach ($role in $roles) {
    $active = Get-MgRoleManagementDirectoryRoleAssignment `
        -Filter "roleDefinitionId eq '$($role.Id)'" -ExpandProperty Principal -All
    $eligible = Get-MgRoleManagementDirectoryRoleEligibilitySchedule `
        -Filter "roleDefinitionId eq '$($role.Id)'" -ExpandProperty Principal -All

    foreach ($a in @($active) + @($eligible)) {
        [pscustomobject]@{
            Role          = $role.DisplayName
            AssignmentKind = if ($a.PSObject.TypeNames -match 'Eligibility') { 'Eligible' } else { 'Active' }
            PrincipalType = $a.Principal.AdditionalProperties.'@odata.type' -replace '#microsoft.graph.', ''
            Principal     = $a.Principal.AdditionalProperties.displayName
            UPN           = $a.Principal.AdditionalProperties.userPrincipalName
            Scope         = $a.DirectoryScopeId
        }
    }
}

$results | Sort-Object Role, Principal | Export-Csv -NoTypeInformation $OutputPath
Write-Host "Wrote $($results.Count) rows to $OutputPath"

Two things that tripped me up the first time I wrote this:

Role assignments to groups show up with PrincipalType = group. You still need to walk the members — I handle that in a follow-up pass, which I will cover in another post.
The DirectoryScopeId is / for tenant-wide, otherwise it is an administrative unit. If your org uses AUs, keep that column; if not, drop it to make the CSV easier to read.

I run this unattended via a scheduled task with a certificate-auth app registration. If there is interest, I will write up the app registration setup next.

Using the PnP reusable property pane controls in SPFx 1.20

Wed, 18 Mar 2026 00:00:00 GMT

Every SPFx web part I ship eventually grows past text fields and toggles, and the default property pane controls run out of runway fast. The PnP reusable property pane controls fill the gap — there is a people picker, a collection data editor, a rich text area, and a dozen others that the built-in controls do not cover.

Add the package to your SPFx project:

npm install @pnp/spfx-property-controls --save

Then drop the controls into getPropertyPaneConfiguration. Here is a minimal people picker wired up to a web part property.

import { PropertyPanePeoplePicker, PrincipalType } from '@pnp/spfx-property-controls/lib/PropertyPanePeoplePicker';
import type { IPropertyPaneConfiguration } from '@microsoft/sp-property-pane';

export interface IMyWebPartProps {
  approvers: { fullName: string; login: string }[];
}

protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
  return {
    pages: [
      {
        header: { description: 'Approval routing' },
        groups: [
          {
            groupName: 'Approvers',
            groupFields: [
              PropertyPanePeoplePicker('approvers', {
                label: 'Select approvers',
                initialData: this.properties.approvers ?? [],
                allowDuplicate: false,
                principalType: [PrincipalType.User, PrincipalType.SharePointGroup],
                context: this.context,
                onPropertyChange: this.onPropertyPaneFieldChanged.bind(this),
                properties: this.properties,
                onGetErrorMessage: null,
                deferredValidationTime: 200,
                key: 'approversPicker',
              }),
            ],
          },
        ],
      },
    ],
  };
}

A few notes from production use:

context must be the full WebPartContext, not context.msGraphClientFactory. The control needs the site URL to resolve SharePoint groups.
Setting principalType to only PrincipalType.User is worth it for approval scenarios — letting users pick a group silently hides who gets the notification.
If you are in a multi-geo tenant, test against a satellite site. The picker is scoped to the web, and cross-geo group resolution occasionally throws silent timeouts.

The full control catalogue lives at pnp.github.io/sp-dev-fx-property-controls. The collection data control is the other one I reach for constantly — worth its own post.

Enforcing conditional access for guests without breaking B2B invites

Fri, 27 Feb 2026 00:00:00 GMT

The first time I rolled out a "guests must MFA" conditional access policy, I locked out every new B2B invitee. They hit the redemption URL, were challenged for MFA against their home tenant, passed, then got blocked by our policy because they had not yet registered MFA in our directory. The fix is not complicated, but it is counter-intuitive.

The policy target should be All guest and external users, but you need to exclude the b2b-invitation-redemption user action and carve out the Azure AD service principal that handles invite sign-ins. Here is the target section I ship:

{
  "displayName": "Require MFA for guests",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeGuestsOrExternalUsers": {
        "guestOrExternalUserTypes": "b2bCollaborationGuest,b2bCollaborationMember",
        "externalTenants": { "membershipKind": "all" }
      },
      "excludeUsers": ["<your-break-glass-account-object-id>"]
    },
    "applications": {
      "includeApplications": ["All"],
      "excludeUserActions": ["urn:user:registersecurityinfo"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa"]
  }
}

Three things I wish someone had told me:

Do not exclude the B2B invitation redemption user action. It is tempting, because that is what is failing. But the redemption itself does not need a grant control — and if a guest is already in your directory from a previous invite, you still want MFA on the redeemed session. Excluding registersecurityinfo is enough to let them complete MFA registration in the target tenant.
Scope to b2bCollaborationGuest and b2bCollaborationMember rather than the old includeUsers: "GuestsOrExternalUsers". The newer schema is more granular and lets you write separate policies for B2B, B2C, and service provider users without a dozen excludes.
Use report-only mode for at least 72 hours. Every tenant has a long-tail of guest sign-ins from external sharing that nobody has thought about in two years. Report-only catches them before they become support tickets.

If you are rolling this out via New-MgIdentityConditionalAccessPolicy, let me know — the PowerShell version has one more gotcha around the external tenants schema that is worth a separate writeup.

Proxmox ZFS replication to a cold offsite node over Tailscale

Wed, 21 Jan 2026 00:00:00 GMT

My homelab has been a single-node Proxmox box for too long. A power surge last summer took it offline for three days, and while nothing was lost, I realized the only copy of every family photo I have digitized is on that ZFS pool. Time to fix that.

The plan: a fanless mini-PC at my parents' house, on Tailscale, pulling ZFS snapshots nightly. It does not run any VMs — it is just a cold target. If the primary dies, I restore to new hardware from the offsite pool.

The trick with Proxmox's built-in replication is that it expects both nodes to be in the same cluster. I do not want a two-node cluster across a consumer internet link, so I drive replication with a shell script and zfs send | ssh | zfs receive.

#!/usr/bin/env bash
set -euo pipefail

POOL="rpool"
DATASETS=("rpool/data/vm-100-disk-0" "rpool/data/vm-101-disk-0" "rpool/photos")
REMOTE_HOST="offsite.tailnet"
REMOTE_POOL="backup"
SNAPSHOT_TAG="offsite-$(date +%Y%m%d-%H%M)"

for ds in "${DATASETS[@]}"; do
  echo "==> Snapshotting $ds@$SNAPSHOT_TAG"
  zfs snapshot "$ds@$SNAPSHOT_TAG"

  # Find the most recent common snapshot for incremental send
  LATEST_REMOTE=$(ssh "$REMOTE_HOST" \
    "zfs list -H -t snapshot -o name -s creation ${REMOTE_POOL}/${ds#*/} 2>/dev/null | tail -n1" \
    | sed "s|^${REMOTE_POOL}/||" || true)

  if [[ -n "$LATEST_REMOTE" ]]; then
    echo "==> Incremental from $LATEST_REMOTE"
    zfs send -i "$LATEST_REMOTE" "$ds@$SNAPSHOT_TAG" \
      | ssh "$REMOTE_HOST" "zfs receive -F ${REMOTE_POOL}/${ds#*/}"
  else
    echo "==> Full send (first run)"
    zfs send "$ds@$SNAPSHOT_TAG" \
      | ssh "$REMOTE_HOST" "zfs receive -F ${REMOTE_POOL}/${ds#*/}"
  fi
done

# Prune local snapshots older than 14 days (offsite keeps its own retention)
zfs list -H -t snapshot -o name | grep '@offsite-' | while read snap; do
  SNAP_DATE=$(echo "$snap" | sed -n 's/.*@offsite-\([0-9]\{8\}\).*/\1/p')
  if [[ $(date -d "$SNAP_DATE" +%s) -lt $(date -d '14 days ago' +%s) ]]; then
    zfs destroy "$snap"
  fi
done

Lessons from the first month of running this:

Tailscale MSS clamping matters. My consumer cable upload started fragmenting on long ZFS streams until I set tailscale up --accept-dns=false --advertise-exit-node=false with MSS clamping in the tailnet ACL. Throughput tripled.
zfs receive -F is fine here but be aware it destroys any receiver-side snapshot newer than the source. On a cold node that only ever receives, this is what you want. On a hot node you are failing over to, it is a foot-gun.
The first full send of my photos dataset was 1.8 TB and ran for four days. Budget for that. Subsequent nightly incrementals run in under ten minutes.

Next step: a monthly scrub on the offsite node with paging to my phone if it reports errors. That is this weekend's project.