Brand new feature out in public preview, and here is how to manage it using Graph. The documentation is already quite decent.

Just built a quick little script that creates named locations for conditional access based on the IP addresses provided and updated by Microsoft, through a json file.

By using this script to manage named locations, you can, through the workload identities conditional access policies currently in preview, limit where your service principals can be used from. You can say things like “These service principals can only be used from Azure region West Europe”.

Find it here in my GitHub!

At Ignite, Microsoft made the conditional access for workload identities feature available in public preview. Currently, this feature is quite limited in scope, but let’s see what it can do.

Currently, Terraform does not support eligible assignments of permissions in Azure RBAC, and only active assignments using the azurerm_role_assignment resource. Continue reading if you want to be able to assign your eligible assignments using ARM or Terraform (Terraform willl use the ARM template).

Finally the Azure AD Connect version is available through the Azure Portal:

But I am more interested in getting this using an API, as I am checking things towards customer tenants. Looking at the API calls behind the Azure Portal, we can find that it is using some endpoints from management.azure.com:

Step 1 – Getting the required access token

You can use the well known 1950a258-227b-4e31-a9cf-717495945fc2 app id with ROPC to get an access token as follows, only username and password required:

$secrets = @{
    username = "abc@demo.com"
    password = "MyPassword"
}

# Create uri and body - AAD graph (deprecated)
$uri = "https://login.microsoftonline.com/{0}/oauth2/token" -f $secrets.tenant
$body = "resource=https://management.azure.com/&client_id=1950a258-227b-4e31-a9cf-717495945fc2&grant_type=password&username={1}&password={0}" -f [System.Net.WebUtility]::UrlEncode($secrets.password), $secrets.username

# Get access token and build header
$token = $null
try {
    $token = Invoke-RestMethod $uri -Body $body -ContentType "application/x-www-form-urlencoded" -ErrorAction SilentlyContinue
} catch {
    Write-Error "Exception when getting AAD access token" -Exception $_
}

if($token.access_token) {
    $Global:HeadersForAzure = @{Authorization = "Bearer $($token.access_token)"}
} else {
    Write-Error "Unable to retrieve access token for https://management.azure.com"
}

Step 2 – Getting the latest actual version from Github

This step is not really crucial, but you can easily fetch the latest version from the Azure AD Connect version history, in order to compare to your tenant:

# Get latest version from Github
$VersionHistory = Invoke-RestMethod "https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/master/articles/active-directory/hybrid/reference-connect-version-history.md"
$_LatestVersion = $VersionHistory -split "`n" | 
    Where-Object {$_ -match "^## [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+"} |
    ForEach-Object {$_ -replace "## "} |
    Sort-Object | 
    Select-Object -Last 1

if($_LatestVersion -notmatch "^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$") {
    New-PolicyResult -Policy $Policy -Status "Failed" -StatusDetail "Unable to determine latest version of Azure AD Connect"
}

$LatestVersion = [Version] $_LatestVersion

Step 3 – Working with the API

Now we are ready to work with the API. Remember, this is an undocumented API, and it is prone to change without notification from Microsoft:

# Get AAD Connect Health service
$PremiumCheck = Invoke-RestMethod -Uri 'https://management.azure.com/providers/Microsoft.ADHybridHealthService/services/GetServices/PremiumCheck?serviceType=AadSyncService&skipCount=0&takeCount=50&api-version=2014-01-01' -Headers $Global:HeadersForAzure

if(!$PremiumCheck.Value) {
    throw "Unable to get Azure AD Connect configuration from management.azure.com"
}

# Check Azure AD Connect status being healthy
if($PremiumCheck.value[0].health -ne "Healthy") {
    throw "Azure AD Connect service not healthy"
}

# Get all servers providing the Azure AD Connect service
$ServiceMembers = Invoke-RestMethod -Uri "https://management.azure.com/providers/Microsoft.ADHybridHealthService/services/$($PremiumCheck.value[0].serviceName)/servicemembers?api-version=2014-01-01" -Headers $Global:HeadersForAzure

# Process servers, checking version, health and version
$ServiceMembers.value | ForEach-Object {
    if(([Version] $_.osVersion) -lt ([Version] "10.0.14393.0")) {
        throw "Server $($_.machineName) running too old operating system Windows build $($_.osVersion)"
    }

    if($_.Status -ne "Healthy") {
        throw "Server $($_.machineName) is not healthy, according to Azure AD Connect Health"
    }

    $ServiceConfiguration = Invoke-RestMethod -Uri "https://management.azure.com/providers/Microsoft.ADHybridHealthService/services/$($PremiumCheck.value[0].serviceName)/servicemembers/$($_.serviceMemberId)/serviceconfiguration?api-version=2014-01-01" -Headers $Global:HeadersForAzure

    if(([Version] $ServiceConfiguration.version) -lt $LatestVersion) {
        throw "Server $($_.machineName) is running version $($ServiceConfiguration.version) of Azure AD Connect, which is not the latest ($LatestVersion)"
    }
}

This API might be different in a few weeks, which means the example will stop working, but that’s life 🙂

I know a lot of customers pushing a lot of strange conditional access policies, because they have no idea what to actually configure, and no experience in what actually works and not. I have therefore made a little starter pack, especially useful for configuring new tenants.

You can find it at my GitHub: https://github.com/goodworkaround/conditional-access-starter-pack

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.