Run AAD Connect Sync & Monitor Status

Depending on the size of an AD environment (and more specifically, the number and location of objects that are in scope to be synced), a delta sync can take anywhere between a couple of seconds and significantly longer.

Checking if a sync currently is running is possible using a couple of methods. When sticking to PowerShell, the following commands can be utilized:

Start-AdSyncSyncCycle: running this command interactively when a sync is running will result in an “in your face” error message similar to the following:

Get-AdSyncScheduler: this command outputs the configuration settings of the sync process and also includes the state, wether or not it is running:

While all of the above are usable, they are not that user friendly, and require a user to retry the command in order to know *when* sync has been completed.

The below PowerShell code (let’s not call it a script, shall we?) does the following things:

  • Checks if a sync process currently is running
  • If not, starts a delta sync
  • Notifies the user / admin when the delta sync is finished
# verify if ADSync module is loaded, and if not, load it.
$module = Get-Module "ADsync"
if ($module -eq $null)
{
Import-Module AdSync
}else
{
    Write-Host "ADSync Module already loaded"
}

# verify if a sync is currently running. If not, start a delta sync
$sync = Get-AdSyncScheduler

if ($sync.SyncCycleInProgress -eq $False)
{
Start-AdSyncSyncCycle -Policytype "Delta" |Out-Null
}

# periodically test if sync is running until it's... not running anymore
do {
    Write-Host "Azure AD Connect Sync Cycle in Progress..." -ForegroundColor "Yellow"
    $sync = Get-AdSyncScheduler
    
} until ($sync.SyncCycleInProgress -eq $False)

Write-Host "Azure AD Connect Sync Cycle is finished." -ForegroundColor "Green"

PowerShell Quicktip: list all Azure MFA-enabled users

Recently, I got a question from a customer to list all users that already enrolled in Azure MFA (through, for example, the url https://aka.ms/mfasetup.

The following PowerShell code lists all non-disabled users that already enrolled in Azure MFA:

Connect-MsolService
Get-MsolUser -All | Where-Object {$_.StrongAuthenticationMethods -ne $null -and $_.BlockCredential -eq $False} | Select-Object UserPrincipalName

Spring 2020 – Security Webinars

Also during (a somewhat different) spring, Microsoft is keeping its promise by delivering webinars to introduce new and improved technology.

Be sure to mark the dates!

WhenAbout
April 15MCAS: Enabling Secure Remote Work
April 20MSSP Support
April 22Threat Hunting on AWS using Sentinel
November 21st Using Sigma to accelerate your SIEM transformation to Azure Sentinel

Details and registration information can be found on https://aka.ms/SecurityWebinars

The certificate “name” on “servername” has expired

When logging in to a customers Exchange Server 2013 environment recently, a pop up caught my eye, indicating the following errror:

An expired certificate as such obviously isn’t such a weird event. However, when zooming into the error, the server that the error referred to was an old, already decommissioned, Exchange Server!

The following locations were checked, to no avail:

  • Get-ExchangeServer
  • Get-ExchangeCertificate
  • ADSI Edit
  • Certificate store on all Exchange Servers

After some googling searching the web with Bing, I found a solution on the web.

Get-Mailbox -Arbitration | Search-Mailbox -DeleteContent

Keep in mind, to run the command, specific permissions are required. A management role needs to be created with Mailbox Import Export assigned role. Assigning the Discovery Management role is not enough!

Self-Service Password reset for Windows

Azure AD has the capability to enable end-users to perform a self-managed reset of the password, in case one does not remember it anymore.

Configuration is fairly easy, and can be done both through Intune and by adding a registry key. Detailed steps on how to do so can be found on https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-windows .

When configuring this on my home tenant, I received the following error:

All usual suspects were covered: the correct licenses were assigned, password writeback was configured and showed up in the portal as working, so no issues there. When opening the SSPR section in the Azure Portal, the following error was shown:

Digging into the Event Viewer on the Azure AD Connect Server revealed the error: The password could not be updated because the management agent credentials were denied access.

Following best practices from Microsoft, the account that was configured in the Azure AD Connect management agent did not have elevated permissions, and therefore did not have the possiblity to reset passwords.

Assigning delegated permissions to reset the password of the OU containing the synced users, solved the issue.