Provisioning Exchange Online / Office 365 Custom Roles automatically from Okta

Natively, when connected to Office 365, Okta allows you to automatically provision users and/or groups. Additionally, Okta will assign licenses you select, and if configured, set predefined roles in Office 365. This means you have one locus of control, very nice.

Then, Exchange Online allows you to define custom roles where you can scope permissions for your users with far greater granularity compared to the default roles, Okta won’t detect or provision users into these custom roles.

As this was a business requirement for a customer, I coded up a small proof of concept you can schedule that will read membership of selected groups in Okta through the Okta API, then ensure that ONLY those members are in the matching role groups in Exchange Online.

Continue reading Provisioning Exchange Online / Office 365 Custom Roles automatically from Okta

Creating a Dynamic Group using the Graph API

Azure has a very nice feature called ‘Dynamic Groups‘. We use these in our customer tenants to dynamically generate a group with actual users, excluding Guest accounts (marked with #EXT#).

As I couldn’t find any articles detailing how to create a Dynamic Group through the Graph API, I’m posting this for whoever it helps šŸ™‚

$dynamicGroupProperties = @{
    "description" = "Dynamic Group Created through the Graph API";
    "displayName" = "Dynamic Group Created through the Graph API";
    "groupTypes" = @("DynamicMembership");
    "mailEnabled" = $False;
    "mailNickname" = "testnickname";
    "membershipRule" = "(user.userPrincipalName -notContains `"#EXT#@`") -and (user.userType -ne `"Guest`")";
    "membershipRuleProcessingState" = "On";
    "securityEnabled" = $True
}

invoke-webrequest -Headers $headerParams -uri "https://graph.microsoft.com/beta/groups" -Body (ConvertTo-Json $dynamicGroupProperties) -method POST -Verbose

If you’re not yet used to working with the Graph API, read up on how to connect to the Graph API using Powershell.

Powershell Lock Function

A handy Powershell function to lock / unlock using .NET, to prevent concurrent read/writes to files or anything else you like.

function handleThreadLock{
    Param(
        [switch]$setLock,
        [switch]$releaseLock,
        [string]$lockName="defaultLockName"
        [int]$timeOut=600
    )
    if($setLock){
        #register a thread lock
        $script:threadLock = New-Object System.Threading.Mutex($false, $lockName)
        $waited = 0
        while($true){
            try{$lockState = $script:threadLock.WaitOne(1000)}catch{$lockState=$False}
            if($lockState){
                break
            }else{
                $waited+=1
                if($waited -gt $timeOut){
                    Throw "failed to get a thread within $timeOut seconds!"
                }
            }
        }
    }  
    if($releaseLock){
        #release a thread lock
        [void]$script:threadLock.ReleaseMutex()
    }  
}

In your script, call it like this:

try{
    handleThreadLock -setLock
}catch{Throw "Failed to set lock!"}

try{
    add-content -Path "c:\yourfile.txt" -Value "log entry" -ErrorAction Stop
}finally{
    handleThreadLock -releaseLock
}

How to retrieve all Okta groups including their members using Powershell

Okta exposes a very useful API, with which I’ve been working for a while to ensure business fit for certain scenario’s that Okta and/or Office 365/Azure don’t fully support yet.

One of those scenario’s requires information about certain groups and their members. I’m narrowing the selection down to just pure Okta groups, but any groups (e.g. AD Synced) can be returned with below code by adjusting the filter in the retrieveAllOktaGroups function.

  1. First, you will need an Okta token to use with Powershell’s REST functions, this is the easiest part.
  2. Okta’s API’s are customer specific, so your $OktaAPIBaseURL parameter should be something like “https://companyname.okta.com”
  3. Run the retrieveAllOktaGroupsAndMembers function below with the token as a parameter
  4. Remember that Okta tokens expire if not used for a while

Continue reading How to retrieve all Okta groups including their members using Powershell

OnedriveMapper v3.11 release

Version 3.11 of OneDriveMapperĀ has beenĀ released:

  • additional fixes to Microsoft’s new sign in method

Important Auto Update Instructions

This version can only auto-update from a cleanly installed v3.10, lower versions will need to be reinstalled.

New Azure AD Signin experience

In IE mode, the script now redirects to the old experience, this means that IE mode will BREAK once Microsoft enforces the new experience. They have not released a timeline for this.

If I have time, I’ll include support for the new experience, but I highly recommend make sure you’re using Native auth as this is far less likely to be affected.

Get the new versionĀ here

OnedriveMapper v3.10 released!

Version 3.10 of OneDriveMapperĀ has beenĀ released!

  • handle the new tile / prompt that appears in IE login mode where Microsoft no longer always redirects to the portal
  • Progress bar color is now a configurable option (cloud/non cloud)
  • alphabetic ordering of configs (cloud only)
  • Fixed auto update loop issue where auto update would break itself for subsequent updates.
  • When restarting self (switching auth mode or auto updating) properly hide the console if this was set

Important Auto Update Instructions

If you were using Auto-Update, DO NOT do so for this version. Use the MSI to replace the old version (see last fixed issue).

New Azure AD Signin experience

As some may have read, Microsoft is previewing a potentially disruptive change without advance notice. My tenants don’t yet display the new behavior so I cannot test if OnedriveMapper will be affected. I haven’t heard of any issues yet šŸ™‚

Get the new versionĀ here

The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Windows Azure Powershell\TokenCache.dat’ because it is being used by another process.

While building some multithreading Azure Runbooks that log into multiple subscriptions simultaneously, I noticed that these multiple concurrent runs often end up on the same Azure Automation Host.

Apparently, these runbooks then don’t run in full isolation, and the following error may occur:

The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Windows Azure Powershell\TokenCache.dat’ because it is being used by another process.

AzureProfile.json may also get locked. I resolved this by doing a retry on the Save-AzureRMContext, and using a randomized file name for the azure json profile:


$randomProfileName = [System.IO.Path]::GetRandomFileName()

Save-AzureRmContext -Path .\$randomProfileName -Force -Confirm:$False

And for my full Azure Login code snippet:

$randomProfileName = [System.IO.Path]::GetRandomFileName()
 $tries=0
    while($true){
        $tries++
        try{
            Write-Output "Logging in to Azure $azureSubscription"
            $res = Login-AzureRmAccount -Credential $azureCreds -SubscriptionId $azureSubscription -TenantId $tenantId -ErrorAction Stop
            Select-AzureRmSubscription -SubscriptionId $azureSubscription -ErrorAction Stop -TenantId $tenantId
            if($res.Context.Subscription.Id -eq $azureSubscription){
                Write-Output "Logged in to Azure subscription $($res.Context.Subscription.Id)"
            }else{
                Throw "Failed, we were logged in to $($res.Context.Subscription.Id) while trying to log in to $azureSubscription"
            }
            Save-AzureRmContext -Path .\$randomProfileName -Force -Confirm:$False
            break
        }catch{
            if($tries -ge 30){
                Throw
                Exit
            }
            #sleep on failed attempts, as the azure token cache gets locked by concurrent jobs
            sleep -s (Get-Random -minimum 1 -maximum 6)
        }
    }