Friday, 24 March 2017

I want to backport my Azure AD identities to an on-premises AD!

I had this come up in an Office 365 engagement I was involved with in December. The customer was a development start up; creating apps for Android and iOS devices. They had started out as 3 employees but the success of their apps on the respective market places had seen them grow to over 200 employees!
On-premises management of devices was now becoming a serious issue, as the company now saw themselves as having to control their IT.

Now there's a variety of solutions for this. The customer could have decided to keep their identities as cloud users in Azure AD, and utilised Windows Intune for device and application rollout, and Azure AD join Windows 10 devices. However that still presented them with the problem on current on-premises printers and a Linux environment they wanted to integrate into an on-premises AD. So, this presented the problem; how do we backport all identities from Azure AD to an on-premises AD?

1. First of all confirm All domains in Office 365 are set as UPN Suffixes in the on-premises AD, this isn't a problem if you only have one domain, but if your users login to Office 365 with and - then ensure this is their UPN in your on- premises AD you have created.

2. Make sure you have some test mailbox enabled users in the tenant – we'll use these to test the back port feature without causing issue to real users. This is performed by using OU filtering when configuring directory synchronisation.

3. Ensure you have extended the Schema for Exchange and installed an Exchange Management Server. Recommended Exchange 2013 or above and the Management Server is in place. Get a free key here:
How to obtain an Exchange Hybrid Edition product key for your on-premises Exchange 2007 or Exchange 2003 organization

Now we have the basics in place, an on-premises AD, users with matching UPNs, an Exchange Management Server and Azure ADConnect (albeit not currently installed), we're ready to start prepping the on-premises AD objects to ensure they get all their Azure AD counterpart attributes! Things like email addresses, general information and location etc

4. Connect to the tenants Azure AD session:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri -AllowRedirection:$true -Credential $cred
Import-PSSession $session

5. Once connected export all Users, Groups and Contacts:

Get-User -ResultSize Unlimited | Export-Clixml C:\Users.xml
Get-Mailbox -ResultSize Unlimited | Export-Clixml C:\Mailboxes.xml
Get-Recipient -ResultSize Unlimited | Export-Clixml C:\Recipients.xml
$DGs = Get-DistributionGroup -ResultSize Unlimited
$DGs | Export-Clixml C:\DistributionGroups.xml
$DGMembers = foreach ($DG in $DGs) { Get-DistributionGroupMember -Identity $DG.Identity | Select @{Name="Group";Expression={$DG.Name}},PrimarySMTPAddress }
$DGMembers | Export-Clixml C:\DGMembers.xml

6. Now end the Session to Exchange Online by running: Get-PsSession |Remove-PsSession
7. In your Local Active Directory Ensure you have setup your desired OU structure so it is ready and waiting. Select a single OU to ease the ingestion of objects.

8. Create these variables in a local PS session:

$MigrationDomain="domain.local" (where domain.local is the main domain/primary domain they use in Office 365)
$OU="AD domain/OU" (where AD domain = for example, and OU is the OU to ingest all objects into)
$Password = ConvertTo-SecureString "Pa$$w0rd" -AsPlainText –Force (this will give ALL users the same password – change it here if you so wish)
$Recipients = Import-CliXML C:\Recipients.xml | Where {$_.WindowsLiveID -like "*@$($MigrationDomain)"}
$Users = Import-CliXML C:\Users.xml | Where {$_.UserPrincipalName -like "*@$($MigrationDomain)"}
$Mailboxes = Import-CliXML C:\Mailboxes.xml | Where{$_.UserPrincipalName -like "*@$($MigrationDomain)"}

We then Import them as 'Mail enabled Users' (this cannot be word wrapped – single command):

$Recipients|where{$_.RecipientType -eq "UserMailbox"}|foreach{New-MailUser -Name:$_.Name -Alias:$_.Alias -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -PrimarySMTPAddress:$_.PrimarySMTPAddress -OrganizationalUnit:$OU ExternalEmailAddress:$_.PrimarySMTPAddress -Password:$Password| Set-MailUser -EmailAddresses:$_.EmailAddresses}

This won't have any good information on them like phone or office location etc. So we add this using, the below, (if there are multiple DCs or Sites wait for replication, or bind to a specific DC):

$Users|foreach{Set-User $_.UserPrincipalName -City:$_.City -Company:$_.Company -Department:$_.Department -Fax:$_.Fax -FirstName:$_.FirstName -Initials:$_.Initials -LastName:$_.LastName -MobilePhone:$_.MobilePhone -Notes:$_.Notes -Office:$_.Office -Phone:$_.Phone -PostalCode:$_.PostalCode -StateOrProvince:$_.StateOrProvince -StreetAddress:$_.StreetAddress -Title:$_.Title}

9. It should at this time have created all the users in the local AD with all relevant company information, phone numbers, details etc. With the caveat they all have the same password. You will need to manage that process yourself (users will have to change themselves - although you could configure password write-back in Office 365 and allow users to change their password either on-premises or Office 365).

10.  READ: At this point we can utilise the test users created in Step 2 to test Active Directory synchronisation. I presume the user knows how to install AADConnect and also to perform OU filtering AND ensure it doesn't sync on initial install. So this is what they will need to do.

11. Move the test users to a test OU.

12. Install AADConnect – ensuring it is not for Hybrid and it is not set to run after install.

13. Go into it and perform OU filtering, select the test OU from step 11 only with the test users in.

14. Perform a sync – see if the users tie up to the accounts in Office 365, you should see them change from 'cloud users' to 'synced with onpremises Active Directory.

15. Login to the Management Server either through Powershell or the EAC – ensure the synchronised users show as 'Mail Users', if they don't it means you missed some - convert them and check their email addresses!

16. Once you're happy perform more ingestion of real users, move the accounts to their correct OUs that you have setup in Step 7 or even earlier. Add OUs into OU filtering as you go.

And that's it! You're all done.

If you decide to synchronise your Distribution Groups (you can leave them cloud only, unless you're planning on using them for security purposes on premises, or prefer synchronisation of groups - or are looking to utilise group write-back capabilities):

1. Set some more variables:
$OU="AD domain/OU"
$DistributionGroups = Import-Clixml c:\DistributionGroups.xml
$DGMembers = Import-Clixml c:\DGMembers.xml


foreach($DG in $DistributionGroups){$ThisDGMembers=$DGMembers|Where {$_.Group -eq $DG.Name}|%{$_.PrimarySmtpAddress}| New-DistributionGroup -Name:$DG.Name -Alias:$DG.Alias -DisplayName:$DG.DisplayName -PrimarySmtpAddress:$DG.PrimarySmtpAddress -SamAccountName:$DG.SamAccountName OrganizationalUnit $OU Members $ThisDGMembers}

I hope you found this excercise interesting! I did - i'll be pushing out a new post on the pre-requisites you need to meet for directory synchronisation with Exchange Online soon - stay tuned!

Take care,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

No comments: