This has been on my To-Do list for such a long time and because of Covid-19 I have finally found the hours required to get this done. A while back I received two Yubico and never got around to testing them 🙁 naughty I know. So let’s look at Yubico;

Microsoft and Yubico have been created a path for a passwordless future for organizations of all shapes and sizes. With a technology standard called FIDO2 and U2F which Yubico co-authored with, Microsoft and Google. Yubico became a founding member of the FIDO Alliance.

How does it all work, I hear you

The Yubikey supports multiple methods for authentication, enabling and the same key to be used across services and applications. With an out of the box native integration for the Microsoft environment provides a rapid deployment.

1. The user plugs the FIDO2 security key into their computer.
2. Windows detects the FIDO2 security key.
3. Windows sends an authentication request.
4. Azure AD sends back a nonce.
5. The user completes their gesture to unlock the private key stored in the FIDO2 security key’s secure enclave.
6. The FIDO2 security key signs the nonce with the private key.
7. The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
8. Azure AD verifies the signed nonce using the FIDO2 public key.
9. Azure AD returns PRT to enable access to on-premises resources.

Enabling support for Yubikey

Time to log into your Azure Active Directory via http://portal.azure.com

Now thats the easy bit completed, the next step is educating the users.

Configuring Yubikey

Each user will need to visit the following your https://myprofile.microsoft.com/

Hows does the sign-in work?

Well, really simple. Check out the video below

Regards
The Author – Blogabout.Cloud

Did you know that Enforce Cloud Password Policy for Password Synced Users exists? and that it is also disabled by default. This means that any user that you sync using Azure Active Directory Connect will not have an expiration timer set against their account. This can be a nightmare for an organization that has strict password policies.

So let’s switch it on and get all your synced users applied

First of all, you will need to run the following command after you have ran Connect-MsolService

PowerShell Command

Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers -Enable $true

You can verify all your users by running the following commands

PowerShell Command

# Output all users to PowerShell console
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled

# Output all users where DirSyncEnabled equal True
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled | Where-Object {$_.DirSyncEnabled -eq $true}

Now let’s apply the following script to ensure that the Password Policy is not disabling password expiration.

PowerShell Command

Get-AzureADUser -All $true | Where-Object { $_.DirSyncEnabled -eq $true -and $_.PasswordPolicies -eq ‘DisablePasswordExpiration’ } | ForEach-Object {
Set-AzureADUser -ObjectId $_.ObjectID -PasswordPolicies None
}

Regards
The Author – Blogabout.Cloud

This post will explain how to merge an on-premise AD user objects with an already existing Azure AD user using hard-match with the sourceAnchor/immutableID property. I have recently experience this issue with a customer who was merging their contoso.com addresses to their fabikam.com Azure AD account.

As you can imagine this isnt a simple process but with the power of PowerShell and good old fashion “I can” attitude, this merger was a complete success.

Before we continue I would like to state that there are two methods that Azure AD Connect will use to match existing users;
– Soft-Match
– Hard-Match

When you install Azure AD Connect and you start synchronizing, the Azure AD sync service (in Azure AD) does a check on every new object and try to find an existing object to match. There are three attributes used for this process: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID.

Soft-Match

Soft-Match will use the properties userPrincipalName and proxyAddresses to match existing users.

Hard-Match

Hard-Match will use the property sourceAnchor/immutableID. You can only select which property is used as sourceAnchor during the installation of Azure AD Connect as described in their documentation.

If the selected sourceAnchor is not of type string, then Azure AD Connect Base64Encode the attribute value to ensure no special characters appear.

Important Note

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated.

So we only have to set the immutableID property of the existing user in our Azure AD to the Base64 encoded string of the ObjectId of the user in our on-premise AD. If you already synchronized your Active Directory then you probably have two users with the same name in your Azure AD. Just follow the following steps to finally merge these users:

You have to execute the following PowerShell commands on the machine with your on-premise AD and the Azure PowerShell commands via the Azure Cloud Shell.

In my scenario, I had a customer that the Email Address on the Active Directory Account didn’t match the PrimarySMTPAddress in Azure AD, however, the PrimarySMTPAddress in Exchange was correct. So I need to match both objects using the PrimarySMTPAddress from Exchange And Azure to set the ImmutableID. I create a PowerShell to gather PrimarySMTPAddress from Exchange along with the required information from Active Directory

1. Get ObjectId from All AD Users

$reportoutput=@()
$users = Get-ADUser -Filter * -Properties *
$users | Foreach-Object {

    $user = $_
    $exchange = Get-Mailbox $user.Name
    $immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'DisplayName' -Value $user.DisplayName
    $report | Add-Member -MemberType NoteProperty -Name 'PrimarySMTPAddress' -Value $exchange.PrimarySMTPAddress
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $immutableid
    Write-Host ('INFO: The following user {0} has the Immutable of {1}' -f $user.name,$immutableid)
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\desktop\immutableid.csv -NoTypeInformation -Encoding UTF8

2. Remove duplicated Azure AD User

If you have synced users and have duplicate accounts you will need to remove these before looking at continuing. A simple way of doing this changing the OU you have synced which has caused the duplicate or you can use the Azure Portal

But if you love PowerShell the following command is also possible as well.

Remove-AzureADUser -ObjectId <objectid>

3. Get Azure AD User ObjectID

One of the key requirements for this post is that we require the ObjectID of the Azure Active Directory account we are looking to match against. The following PowerShell command prints a list of all users with their ObjectId and exports to your desktop.

Get-AzureADUser | export-csv $env:userprofiles\desktop\AzureADUser.csv

4. Matching my CSV Files

So I ended up with two CSV files

– Export of AD with PrimarySMTPAddress from Exchange
– Export of Azure AD with ObjectID and PrimarySMTPAddress.

A few months ago I came across a little gem in the PowerShell world called ImportExcel which is a PowerShell module I have discussed in the past.

Once you have a single pane of glass with your ObjectID and ImmutableID matched within a csv, you will now be able to set all the ImmutableID for all your Azure AD Objects.

5. Set immutableId for Azure AD User in Bulk

Run the following script against Azure AD using PowerShell.

$Filepath1 = $env:USERNAME\desktop\immutableid.csv
$csv1 = Import-Csv -Path $filepath1

#endregion 

Start-Transcript $env:USERPROFILE\desktop\PilotUser.csv

foreach($user in $csv1){

    Set-AzureADUser -ObjectID $user.ObjectId -ImmutableID $user.ImmutableID
    Write-Host $user.PrimarySMTPAddress,"with ObjectID"$user.ObjectId," has been set with ImmutableID",$user.ImmutableID
}
Stop-Transcript


6. Start AD Sync

You can now resync the OUs which had all the user accounts and hard matching will be completed using the newly set ImmutableID.

Start-ADSyncSyncCycle -PolicyType Delta

Regards
The Author – Blogabout.Cloud

In this example I have local Active Directory with AAD Connect installed one of the Azure Region, which sync users and password hash to Office 365. I have now decided to migrate the authentication from local Active Directory to Office 365 and decommission on-premises Active Directory.

In order to transition from on-premises “Synced Identity” to “In Cloud Identity”, we will need to complete the following process.

IMPORTANT NOTE!!!!!

When deactivating Directory Sync it may take up to 72 hours before it can reenable depending on the size of your production network. All users will keep their current password but all synchronized objects are removed from Azure AD, please keep this in mind.

To check if you can reenable Directory Sync you will need to run Get-MSOLCompanyInformation. This will show you the detailed information. and the last four fields are the most important in this scenario as this will indicate if Directory Sync can be reenabled as the status is False.
DirectorySynchronizationEnabled
LastDirSyncTime
LastPasswordSyncTime
PasswordSynchronizationEnabled

In my scenario, Directory Sync was able to be reactivated after 8 hours. The customer I was working with accepted the potential risk in order to complete this work.

Sign into the AAD Connect Server and Sync the Delta

The following command performs a sync of all AD Objects before attempting to convert into Cloud Only.

 Start-ADSyncSyncCycle Delta 

Turn off AAD Connect Sync

The following command turns off Azure Active Directory Connector while we perform all the following tasks. In this post I have outlined all steps which can be taken to convert AD Users account into Cloud Only.

 Set-MsolDirSyncEnabled -EnableDirSync $false 

Convert Single User to Cloud Only

The following command converts a single user into a Cloud Only account

 Get-MsolUser -UserPrincipalName thewatchernode@blogabout.cloud | Set-MsolUser -ImmutableId "$null" 

Remove Immutable ID of all users

The following command removes the Immutable ID for all users

 Get-MsolUser | Set-MsolUser -ImmutableId "$null" 

Remove Immutable ID for Bulk users

The following scripts allows you to modify users at bulk

$Filepath = $env:userprofile\desktop\file.csv
$csv = Import-Csv -Path $filepath
$immutableID=$null 

Foreach($user in $csv)
{
Set-MsolUser -UserPrincipalName $user.UserPrincipalName -ImmutableID $immutableID
}

Turn on Azure Active Directory Connect Sync

Once you have completed all the required conversions of AD accounts to Cloud. Head back to your local Active Directory, move user(s) to an OU that isn’t synchronized using AADC.

This helps you as an IT Pro understand who has been converted at a quick glance now not worry about using PowerShell to discovery who is or isn’t.

The following command turns on Azure Active Directory Connector now that we have converted the users accounts to Cloud Only

 Set-MsolDirSyncEnabled -EnableDirSync $true 

Enable Force Sync if the Sync didn’t work

  Start-ADSyncSyncCycle -PolicyType Initial 

If you are using an ADFS Server there is an additional step providing you have moved all your users to the Cloud. You will need to change the Federated Domain to Standard Domain

Convert-MsolDomainToStandard -DomainName blogabout.cloud -WhatIf
Convert-MsolDomainToStandard -DomainName  blogabout.cloud -Confirm

All that is left now is to log in as one of the converted users to prove Single Sign-On is working and logon as a Global Admin into Office 365 to check the sync status of the users has a pretty cloud for “In-Cloud”

Regards
The Author – Blogabout.Cloud

What is DBEB? It is a solution that allows an organization to reject message for invalid recipient at the service network perimeter. DBEB enables your Office 365 Global Administrator to add mailed-enabled recipients to Office 365 and block all messages sent to email address that aren’t present in Office 365.

Valid messages are then subject to the rest of the service filtering layers which are;

Antimalware
Antispam
Mail Flow Rules (otherwise knows as Transport Rules)

Invalid messages are blocked before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this:

Important Note

In hybrid environments, in order for DBEB to work, email for the domain must be routed to Office 365 first (the MX record for the domain must point to Office 365).

Configuring DBEB

First of all, you need to verify that your accepted domain EXO is an Internal Relay, this is done by going to Exchange Admin Console –> Mail Flow –> Accepted domains.

If, your domain type is Authoritative you will need to click the edit button and set to internal relay

Adding your users to Office 365

• Directory synchronization: Add valid users to Office 365 by synchronizing from your on-premises Active Directory environment to Azure Active Directory in the cloud. For more information about how to set up directory synchronization, see “Use directory synchronization to manage recipients” in Manage Mail Users in EOP.
• Add users via PowerShell or the EAC: For more information about how to do this, see Manage Mail Users in EOP or Manage mail users in Exchange Online.

In the EAC, go back to Mail flow > Accepted domains.

Select the domain and click Edit.
Set the domain type to Authoritative.
Choose Save to save your changes, and confirm that you want to enable DBEB.

• Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay. Once the domain type has been changed to Authoritative, DBEB is designed to allow any SMTP address that has been added to the service (except for mail-enabled public folders). There might be infrequent instances where recipient addresses that do not exist in your Office 365 organization are allowed to relay through the service.
• For more information about DBEB and mail-enabled public folders, see Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders.

Regards.
The Author – Blogabout.Cloud