Merging on-premise AD User Objects with existing Azure AD user Objects.

Merging on-premise AD User Objects with existing Azure AD user Objects.

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


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$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

Deleted Users

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


1
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.


1
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.


1
2
3
4
5
6
7
8
9
10
11
12
13
$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.


1
Start-ADSyncSyncCycle -PolicyType Delta

Regards
The Author – Blogabout.Cloud

Using Azure Blob Storage for your Intune applied Lock Screen and Desktop Backgound

Using Azure Blob Storage for your Intune applied Lock Screen and Desktop Backgound

Leveraging your Azure subscription for Microsoft Intune massively reduces the requirements for on-premises infrastructure. In this post I will show you how to use Azure Blob Storage to provide the Lock Screen and Desktop background all with the power of the Microsoft Cloud.

First up you will need to create a storage account within your Azure subscription.

Create Storage Account

Specify the following;
– Resource Group
– Storage Account Name
– Location (Europe) UK South

Specify settings

Once the storage account has successful created, you will need to go to the resource

Go to resource

Go to “Containers”
Create new “Container”
Specify the name of the Container
Specify the Public Access level as “Blob”
Then click ok

Specify settings

Click on your new “Container”

Created Container

Click Upload
You will need to upload your required .jpg file

Click on the uploaded file and you will be provided a URL which can be used

Provide the URL into your required destination for example Lock Screen as shown below

As you can see from below my Lockscreen and Desktop backgrounds are what I have specifed.

Image for Lockscreen
Lockscreen
Image for Desktop
Desktop

Regards
The Author – Blogabout.Cloud

Convert Synced User into In-Cloud only User

Convert Synced User into In-Cloud only User

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.

Azure Active Directory Connect Diagram

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

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.

1
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.

1
Set-MsolDirSyncEnabled -EnableDirSync $false

Convert Single User to Cloud Only

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

1
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

1
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

1
Set-MsolDirSyncEnabled -EnableDirSync $true

Enable Force Sync if the Sync didn’t work

1
 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


1
Convert-MsolDomainToStandard -DomainName blogabout.cloud -WhatIf<br>Convert-MsolDomainToStandard -DomainName
1
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

Windows 10 Azure AD – Something went wrong

Windows 10 Azure AD – Something went wrong

So I have been recently cleaning up my test lab Azure Active Directory and accidentally removed a device which I was still actively using within my tenant. I received the following error;

“Your organization has deleted this device. To fix this, contact your system administrator and provide error code 700003”

When trying to access organizational resources

In order to resolve this issue, you need to complete the following steps

– Remove the Work account from the Windows 10 device under your account –> Access Work or School and remove the account
– Open command line or PowerShell windows with Admin rights
– Enter the following command;
dsregcmd /leave

dsregcmd /leave

Enter command: “dsregcmd /status” to check if the system is now left the Azure AD

dsregcmd /status

You will now been able to register your device and access your organisation once again.

Regards
The Author – Blogabout.Cloud

Managing your on-premises device with Azure Update Manager

Managing your on-premises device with Azure Update Manager

Azure Update Manager allows customers manage their Azure VM and on-premises devices using an agent called (MMA) Microsoft Monitoring Agent. The client will by default check if its compliant every 12 hours and the agent initiates a scan to check for update compliance within 15 minutes of the agent being restarted, before an installation and after update installation.

Azure Update Manager only supports the following OS for patch cycles

Supported Client Types

Operating SystemNotes
Windows Server 2008, Windows Server 2008 R2 RTMSupports only update assessments.
Windows 2008 R2 SP1 and later (including Windows Server 2012 and 2016).Net Framework 4.5.1 or later is required
Windows Powershell 4.0 or later is required
Windows PowerShell 5.1 is recommended for increased reliability.
CentOS 6 (x86/x64) and 7 (x64)Linux agents must have access to an update repository. Classification-based patching requires ‘yum’ to return security data which CentOS doesn’t have out of the box. For more information on classification-based patching on CentOS
Red Hat Enterprise 6 (x86/x64) and 7 (x64) Linux agents must have access to an update repository.
SUSE Linux Enterprise Server 11 (x86/x64) and 12 (x64) Linux agents must have access to an update repository.
Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 (x86/x64) Linux agents must have access to an update repository.

Unsupported Client Type

Operating SystemNotes
Windows ClientClient operating systems (such was Windows 7 and Windows 10 arent supported.
Windows Server 2016 Nano ServerqNot Supported

However, the Windows Client arent supported for patch management. The MMA agent can be installed if you just require update reporting using Azure Monitor.

Where do I start in configuring Azure Update Management?

The first thing we need is an Azure Automation Account

You will need to provide details as specified below

Please Note:

Log Analytics Workspace is required later in this process and its only currently available in the following locations;

Australia Southeast
Canada Central
Central India
East US
Japan East
Southeast Asia
UK South
West Central US
West Europe
West US 2

If you want to check where functionality located, please visit this url https://azure.microsoft.com/en-us/global-infrastructure/services/?products=monitor&regions=us-east,us-east-2,us-central,us-north-central,us-south-central,us-west-central,us-west,us-west-2,canada-east,canada-central,united-kingdom-south,united-kingdom-west,non-regional,south-africa-north,south-africa-west

Once the account has been created, select the newly account and go to Update Management Section and Update Management. This will show the Location you specified, Log Analytics Workspace subscription and you can now create the Log Analytics Workspace.

Configure Automation Account for Update Management

Once you press Enable, you’ll receive a message that “The installation of the Update Management solution is in progress.”

Enable Update Management with Log Analytics Workspace

Now we have successful created the Log Analytics Workspace you will be able to build the “Schedule Update Deployment” as shown below

Update Management – Schedule Update Deployment

Now we can get down with the nit and gritty of configuring deployment schedules based on your own requirement. This section will be configured down to personal preference for my Test Lab Machine.

Please Note:

The following information will only reference Windows Operating System, Linux is also available but will not be discussed.

Groups to update

In this section, you can filter the machines you would like to manage using Azure Update Management. This also includes the Non-Azure machines feature which is currently In Preview at the time of this post.

Azure Machines

If you select preview for your Azure Machines and unable to detect an clients. You may need onboard your Azure VM https://docs.microsoft.com/en-us/azure/automation/automation-onboard-solutions-from-vm

Non-Aure Machines

Machines to update

In this sectrion, depending how you are providing your client machines into the Azure Portal, you can use one of the three Types to select your machines

  • Saved Searches
  • Imported groups (AD,WSUS,SCCM)
  • Machines
Machines to update

Update classifications

In this section, you can select 8 individual classifications based on your requirements.

  • Critical updates
  • Security updates
  • Update rollups
  • Feature packs
  • Service packs
  • Definition updates
  • Tools
  • Updates

Select the type of update classifications you would like to apply to your client machines.

Include/Exclude updates

In this section you can Include or Exclude particular Microsoft update using the KB number without the KB prefix.

Schedule settings

In this section, you can specify the require schedule whether its run once or needs to recurrence cycle.

Pre-scripts + Post-scripts

In this section, Pre-scripts and Post-scripts are tasks that can be automatically executed before or after an update deployment run. You can configure up to one Pre-script and Post-script per deployment.

Finishing touches

Maintenance Window – To set the maintenance window, the duration must be a minimum of 30 minutes and less than 6 hours.
The last 20 minutes of the maintenance window is dedicated for machine restart and any remaining updates will not be started once this interval is reached. In-progress updates will finish being applied

Reboot options – There are currently 4 reboot options available

  • Reboot if required
  • Never reboot
  • Always reboot
  • Only reboot – will not install updates

Regards
The Author – Blogabout.Cloud

What is Global VNet Peering?

What is Global VNet Peering?

Global VNet Peering? This function has recently come to my attention while working with an international customer who is in the process of integrating into their new owners Azure Active Directory. Global VNet peering enables resources in your virtual network to communicate across Azure regions privately through the Microsoft backbone. Resources communicate directly, without gateways, extra hops, or transit over the public internet. This allows a high-bandwidth, low-latency connection across peered virtual networks in different regions.

Example of Vnet Peering between Regions

You can use Global VNet Peering to share resources within a global, private network. You can then easily replicate data across regions for redundancy and disaster recovery.

In my case I was integrating the Active Directory Domains and using Azure Active Directory Connector located in primary region to synchronize the AD Objects from one domain into the other. This approach provided a quick and simply migration without really complexity.

Global Vnet Peering is only currently supported for the following regions.

  • Americas: West Central US (Wyoming), West US 2 (Washington), Central US (Iowa), US East 2 (Virginia), Canada Central (Toronto), Canada East (Quebec City)
  • Asia Pacific: Southeast Asia (Singapore) Korea South (Buscan), South India (Chennai), Central India (Pune), West India (Mumbai)
  • Europe: UK South (London), UK West (Cardiff), West Europe (Netherlands)

Cost of VNET Peering within the same region

Inbound data transfer $0.01 per GB
Outbound data transfer $0.01 per GB

Cost of Global VNET Peering

Zone 1Zone 2Zone 3US Gov
Inbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB
Outbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB

Virtual Network TAP preview

Virtual Network TAP is a feature that allows customers to enable mirroring of their virtual machine network traffic to a packet collector.

GlobalUS Gov
VTAP $0.0125 per hour $0.0125 per hour

IP addresses

Public IP addresses, and reserved IP addresses can be used in services running inside a virtual network. They carry a nominal charge as outlined here

VPN Gateways

A virtual network can have one or more VPN gateways to connect back to on-premises network or other virtual networks in Azure. The VPN Gateway is charged as detailed here

Regards
The Author – Blogabout.Cloud

New functionality now in preview for Conditional Access

New functionality now in preview for Conditional Access

So I was happily minding my own business looking at the configuration of my Conditional Access and notice 3 new options have appeared;

  • Baseline policy: End user protection (Preview)
  • Baseline policy: Block legacy authentication (Preview)
  • Baseline policy: Require MFA for Service Management (Preview)

Baseline policy: End user protection (Preview)

This policy protects users by requiring multi-factor authentication (MFA) during risky sign-in attempts to all applications. Users with leaked credentials are blocked from signing in until a password reset.

Once the policy is enabled, users are required to register for MFA within 14 days of their first login attempt. The default method of MFA registration is the Microsoft Authenticator App.

This policy is either On or Off and you can also exclude users from receiving this policy

Baseline policy: Block legacy authentication (Preview)

This policy blocks all sign-ins using legacy authentication protocols that don’t support multi-factor authentication (such as IMAP, POP, SMTP). The policy does not block Exchange ActiveSync.

  • Office 2013 (without registry keys)
  • Office 2010
  • Thunderbird client
  • Legacy Skype for Business
  • Native Android mail client

This policy is either On or Off and you can also exclude users from receiving this policy. This policy is great as I have configured a custom built policy for just this but my policy also includes Exchange Active Sync.

Baseline policy: Require MFA for Service Management (Preview)

This policy requires users logging into services that rely on the Azure Resource Manager API to perform multi-factor authentication (MFA).

Services requiring MFA include:

  • Azure Portal
  • Azure Command Line Interface (CLI)
  • Azure PowerShell Module

This policy is either On or Off and you can also exclude users from receiving this policy

Its great to see some more brilliant developments in Conditional Access and really excited to see these go live with customers.

Regards
The Author – Blogabout.Cloud

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

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:

1
550 5.4.1 [&lt;InvalidAlias>@\&lt;Domain>]: Recipient address rejected: Access denied

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

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

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing is the latest in connecting your SIP trunk provider but how about leveraging the Microsoft cloud and deploy your Session Boarder Controller (SBC) into Azure.

Audiocodes are one of many SBC providers using Azure to provide an additional options with your approach to moving to Microsoft Teams.  If your a consultant deploying AudioCodes Mediant VE SBC for Microsoft Azure, this process couldnt be any easier with using Azure Resource Manager (ARM) templates which can be developed to adapt to any customer requirements.

If you have a bit of Azure knowledge in deploying new resources the below image will not be to difficult understand.

But if this is the first time you’ve looked deploying a resource in Azure, I highly recommend looking at creating a template and use Visual Studio. This will allow you to make modification in the code and learn how ARM templates work.

How much does the Audiocodes Virtual Machine cost?

The below tables is based on today costing as of 12 November 2018 and these prices may change.

VM Size Offering Family VCPU RAM Data Disk Max IOSP Temporay Storage SIP Sessions Price
D2_v2 Standard General Purpose 2 7 8 8×500 100GB 200 £75.41
D2_v3 Standard General Purpose 2 8 4 4×500 50GB 500 £66.54
D3_v2 Standard General Purpose 4 14 16 16×500 200GB 900 £150.83

Microsoft Teams Direct Routing will only get bigger as time goes on and you can expect the number of supported SIP sessions to increase (expected 6000 sessions in Q1 2019). It is also worth noting that Audiocodes also offer a multi tenant SBC so if you are a service provider, you can house multi customers on a single SBC appliance.

Regards

Author – Blogabout.Cloud

Dynamic groups in Microsoft Teams

Dynamic groups in Microsoft Teams

Microsoft Teams now supports dynamic groups but what does this mean? Dynamic groups are an Azure AD Premium (P1) feature that allows group membership to be automatically tied to AD attributes (i.e. users with a location of ‘London, New York or Seattle’) that will continuously sync as the membership changes over time. Dynamic group membership reduces the administrative overhead of adding and removing users.

Which is great for IT Administrator across the group.

How to create a dynamic group

Please follow the steps from here

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-create-rule

Once you have created the group, every assigned member will receive an email stating they have joined the defined group

We already have a group (Office or Security) and would like to change its membership type to “Dynamic”

Of course you can do this from the Azure AD admin center. Please follow the steps from here https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-change-type

How do create a Microsoft Team with a Dynamic Group

Launch Microsoft Teams and click “Join or create a team

Click “Create a team from an existing Office 365 Group

Select the dynamic group you are an owner of and the group name will become the Team name.

Command Questions

Does this support syncing Security Groups (SGs)?

No, dynamic membership groups are different from SG/DL

How long does the dynamic group changes take to reflect in Teams?

This can take up to 2 hours after membership changes are reflected in Azure portal.

Regards,

Author – Blogabout.Cloud