All posts by Jos

Exchange Online, Office 365

Ghost Mailusers

Leave a comment

We had an odd case today that Msft support hasn’t fixed yet, but in case someone googles the error and finds this, I did find a workaround.

We had a MailUser object that was inactive (soft deleted), but couldn’t be permanently deleted using 

Remove-MailUser -PermanentlyDelete -Identity $mailuser.ExternalDirectoryObjectId

The resulting error was:

This mail enabled user cannot be permanently deleted since there is a user associated with this mail enabled user in Azure Active Directory. You will first need to delete the user in Azure Active
Directory. Please refer to documentation for more details.

However, nothing was found in AzureAD (or deleted users/recycle bin), and nothing was present in our on-prem AD.

This user was deleted a long time ago, and now being rehired….but account creation was being blocked because the mail user was still claiming the email address of this user.

After some messing around, and not patiently waiting for Msft 1st line support to delete this corrupted MailUser, I discovered the RecalculateInactiveMailUser switch in the set-MailUser command.

Normally, you can’t modify the primary smtp / aliases of a soft deleted mailuser or mailbox….BUT, for some reason, if you supply RecalculateInactiveMailUser you can. So:

Set-MailUser -Identity $mailuser.ExternalDirectoryObjectId -EmailAddresses $newProxies -RecalculateInactiveMailUser

Worked fine! While

Set-MailUser -Identity $mailuser.ExternalDirectoryObjectId -EmailAddresses $newProxies

Failed with

The operation couldn’t be performed because object ‘270fc89f-0424-42d2-8f54-25796f74457b’ couldn’t be found on ‘DB8PR02A05DC001.EURPR02A005.PROD.OUTLOOK.COM’.

Automation, Azure, AzureAD, Identity, Office 365, PowerApps, Powershell

Inviting an external user to a PowerApp programmatically

Leave a comment

Another week, another use case for Managed Identities in Automation Accounts!

The scenario today concerns a PowerApp and connected resources that should be shared with external identities, automatically of course. For each user this requires a guest account in the host / resource tenant, and a license. The license can be applied in the home tenant of the guest, or in your tenant.

Key points:

  1. Runbook that invites a user and adds the resulting guest account to a security group
  2. Security group gives access to the PowerApp and underlying (SpO) resources, and uses Group Based Licensing to license the guest for PowerApps and Sharepoint Online
  3. Logic App that is triggered by the PowerApp (trigger on create item in a sharepoint list), and starts the runbook
  4. When the invited user (guest) redeems the invitation, they are directed to a Sharepoint page first so Sharepoint syncs their profile. Otherwise, the PowerApp will not have access to any lists in Sharepoint Online as Guests are not synced to SpO until they access SpO directly.

I may demo the PowerApp, Logic App and Sharepoint lists at some point, but the main thing I wanted to share today is the Azure Runbook that creates the Guest invitation and adds the Guest to a security group using the Managed Identity of the Automation account, instead of service accounts or other pre-2021 solutions:

https://gitlab.com/Lieben/assortedFunctions/-/blob/master/invite-guestUser.ps1

Automation, Azure, Identity, Powershell

License reports by a Managed Identity

Leave a comment

Capitalizing on the huge advantages that managed identities in Azure offer, here’s another use case similar to the scheduled migration script that also uses it’s managed identity (and graph permissions) to autonomously run as an Azure Runbook without any credentials stored.

https://gitlab.com/Lieben/assortedFunctions/-/blob/master/get-licenseReportByDomain.ps1

The script will log in to Graph, retrieve all unique license types and how they are assigned to users, and will then email an HTML report (table) the the specified recipient, order by email domain.

AzureAD, Powershell

Expanding Microsoft First Party Application Permissions in AzureAD

1 Comment

Connect-AzAccount and my own silent token function use the Microsoft built in client ID of “1950a258-227b-4e31-a9cf-717495945fc2”.

The resulting token has some openID scopes and most backend calls use RBAC, but I wanted to experiment by adding OAuth2 permissions and app roles to it so I can use the context/cached refresh token to also call other Microsoft API’s.

I discovered that this can be done by adding the client to your AzureAD as an SPN (Enterprise Application):

$spn = New-AzureADServicePrincipal -AppId "1950a258-227b-4e31-a9cf-717495945fc2" -DisplayName "Microsoft Azure PowerShell"

Since this is Microsoft owned app, you’ll actually see that show up in AzureAD:

Next, we can add the AuditLog.Read.All permission to the local instance of this app ($spn), this is a Graph permission, so we first need to get the resourceId of graph in our tenant:

$GraphServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

Then we prepare our post body for the Graph API to add the AuditLog.Read.All permission to Microsoft Azure PowerShell:

        $patchBody = @{
            "clientId"= $spn.ObjectId
            "consentType"= "AllPrincipals"
            "principalId"= $Null
            "resourceId"= $GraphServicePrincipal.ObjectId
            "scope"= "AuditLog.Read.All"
            "expiryTime" = "2022-05-05T09:00:00Z"
        }

Then we’ll grab a token for the Graph API:

$token =  get-azResourceTokenSilentlyWithoutModuleDependencies -userUPN myupn@lieben.nu

And call Graph to add the permission to our local instance of Microsoft Azure PowerShell:

Invoke-RestMethod -Method POST -body ($patchBody | convertto-json) -Uri "https://graph.microsoft.com/beta/oauth2PermissionGrants" -Headers @{"Authorization"="Bearer $token"} -ContentType "application/json"

Any future tokens you grab for graph.microsoft.com using 1950a258-227b-4e31-a9cf-717495945fc2 as clientId will now contain the AuditLog.Read.All scope as well;

You should also be able to add approles, but since (hopefully) only Microsoft has the client credentials, they won’t do much.

Inspired by a question PrzemyslawKlys asked me 🙂