As usual when a new Microsoft Graph endpoint is released, I do some digging using Graph Explorer. Not rocket science, but some times I find very interesting stuff, and this time I have found something.

Let’s say you have 1000 users curretly using SMS for Multi-Factor Authentication, and you want to get them to use the Microsoft Authenticator app instead. What do you do? Do you send out emails, checking the current rollout status using the microsoftAuthenticatorAuthenticationMethod endpoint of each user? Sure, today you do, but there is a secret feature available that some time in the future will help you out. Registration campaigns!

Going forward, the Azure AD PowerShell Module will not be updated, and Microsoft has stated that it is the Microsoft.Graph PowerShell Module that will be used. This makes sense, as this is auto-generated based on the Microsoft Graph Odata, not requiring Microsoft to maintain several things. However, right now, some of the PowerShell verbs are not really following best practices. Anyway, here is how to do some simple things 🙂

Azure AD Conditional Access has been quite powerful for a long time, but just got way better with the new authentication context feature. Authentication context is essentially a new way to scope conditional access policies, where instead of targeting an application, you target a context, such as “High security operations” or “Operations requiring consenting to terms of use”. Using the authentication context, you can split your applications into several assurance levels, each being targeted by a separate set of CA policies.

Let’s have a look at the tech first, with tokens and stuff.

A common problem when creating just about any resource in Active Directory, Exchange Online, Azure AD, SharePoint, etc. is life cycle. I see so many customers that have no control over their distribution groups. This is a script that you can use to determine which if your distribution groups are in use, and which are not, by looking at the message trace for the last 90 days.

Shortest blogpost that will ever be on this blog. Here is a url you can use to get all guests from your Azure AD, including those you have set userType to “Member” for, for different reasons:

https://graph.microsoft.com/beta/users?$filter=creationType eq 'Invitation' or userType eq 'Guest' or externalUserState eq 'Accepted' or externalUserState eq 'PendingAcceptance'

The Microsoft Graph endpoint for instantiating Azure AD gallery apps is quite new, and I just needed them in order to instantiate 20+ apps based on the GitHub Enterprise Organization template. Here is my code, if someone has use for it 🙂

I have left out “how to get an access token”. The permissions required is Application.ReadWrite.All.

With Azure AD External Identities, Microsoft is bringing some of the Azure AD B2C features to “regular” Azure AD, and it is now generally available (GA). With these features, you can add public self service sign up-baed authentication flows to your services, using your existing Azure AD.

So, “Temporary Access Pass (Preview)” just popped out as an available authentication method in my demo tenant, and I figured this was something that needs investigation!

Quick blogpost today, showing how to batch create privileged access groups for the Privileged Identity Management feature in Azure AD. The endpoint used is not currently documented in the Graph documentation.

First thing you need to do is get yourself an access token. Follow my guide for this. This script will use a hardcoded variable for the token.

# Get your access token somehow, not in scope for this example
$accesstoken = "eyJ0eXAiOiJKVGtHUniJSUzI1NiIs--- snip ---wFzrJUYkOm37KY27WJvQ"

# Groups to create
$groups = "test12345","test123468","test9577","test304934089"


# No need to edit below this line

# Build header value
$headers = @{Authorization = "Bearer $accesstoken"}
$groups | Foreach {
    # Check if group already created
    $matching = Invoke-RestMethod "https://graph.microsoft.com/beta/groups?`$filter=displayName eq '$($_)'" -Headers $headers 

    $id = $null
    # Create if no group was found
    if(!$matching.value) {
        Write-Verbose "Creating group: $($_)" -Verbose
        $body = @{
            displayName = $_
            isAssignableToRole = $true
            mailEnabled = $false
            mailNickname = $_
            securityEnabled = $true
        } | ConvertTo-Json

        $creation = Invoke-RestMethod "https://graph.microsoft.com/beta/groups" -Headers $headers -Method Post -Body $body -ContentType "application/json"
        Write-Verbose "Group '$($_)' created with object id $($creation.id)" -Verbose
        $id = $creation.id
    } else {
        Write-Verbose "Group '$($_)' already created" -Verbose
        $id = $matching.value[0].id
    }

 
    # Check for PIM registration of group
    $pimmatching = Invoke-RestMethod "https://graph.microsoft.com/beta/privilegedAccess/aadGroups/resources?`$filter=externalId eq '$id'" -Headers $headers

    # Register group in PIM, if not already registered
    if(!$pimmatching.value) {
        Write-Verbose "Registering group $($_) ($id) in PIM" -Verbose
        $body = @{
            externalId = $id
        } | ConvertTo-Json

        $registration = Invoke-RestMethod "https://graph.microsoft.com/beta/privilegedAccess/aadGroups/resources/register" -Headers $headers -Method Post -Body $body -ContentType "application/json"
    } else {
        Write-Verbose "Group $($_) already registered in PIM" -Verbose
    }
}

In a recent blogpost, Protecting Microsoft 365 from on-premises attacks, it is recommended to not federate (which I have been recommending for years) and not to synchronize accounts with privileged access to Azure AD and Microsoft 365. This post contains a few script to help you determine synchronized accounts with privileged access to Azure AD.