This is the fourth post in a series dedicated to installing and configuring ADFS 2.1 on Windows Server 2012 for Office 365 Single Sign-On. For previous posts, see:
- Part 1, adding and verifying the new domain in Office 365, installing the first ADFS server, federating with Office 365
- Part 2, installing remaining ADFS farm servers, configuring NLB, deploying two-way federation metadata update tool
- Part 3, installing ADFS proxies, configuring Extended Authentication Protection, IdP Initiated Sign-On, authentication handlers
In this post, we will drill into directory synchronization between on-prem Active Directory and Office 365.
Why Dirsync, isn’t ADFS Enough?
ADFS sets up the infrastructure that is used by two unrelated networks to authenticate a user in one network, and allow him/her to consume a service in the other network. ADFS enables Single Sing-On, but for it to actually work as seamlessly as it does, you need to create user accounts in Office 365.
Dirsync handles this function, automatic creation of user accounts (and groups, contacts) in Office 365. Dirsync essentially mirrors a limited set of attributes from your on-premise Active Directory into the Windows Azure Active Directory used by Office 365. Existence of these replicated accounts is what allows Microsoft to provision Office 365 services for the user to consume, after ADFS authenticates them.
Step 14: Enable Directory Synchronization with Office 365
Before we set up directory synchronization, let’s first enable this feature on our federated domain flexecom.com. This setting is actually tenant-wide, and not domain-specific.
Office 365 takes some time to enable this feature, this can take anywhere between 3 and 24 hours to kick in.
The way to do this in PowerShell is as follows. Use Windows Azure Active Directory PowerShell on one of your ADFS farm servers.
Connect-MsolService Set-MsolDirSyncEnabled -EnableDirSync $true
To confirm that directory synchronization is enabled:
What you want to see is DirectorySynchronizationEnabled attribute set to True, but again, don’t expect this change to happen immediately.
The following will appear in Users and Groups section of Office 365 portal:
We are ready to install and configure DirSync.
Step 15: Deploy Dirsync Server on Windows Server 2012
At the end of June 2013 Microsoft released Dirsync appliance that fully supports Windows Server 2012, 64 bit, and also features the latest (April 2013) build of MOSSIA 64 bit, which was previously available as a “beta” download from microsoft.com. To get this Dirsync appliance, you will need to log into Office 365 Portal using administrator credentials, click on Users and Groups, then next to Active Directory synchronization, click Set Up (as shown on the previous screenshot). This opens up a Dirsync setup page:
Note: These components are subject to frequent updates. The best way to get the latest supported build is to always download it from your Office 365 portal. As of this writing, the latest build of Dirsync.exe is dated June 21 2013.
When To Use Command Line
Since our imaginary scenario has 50,000 accounts in Active Directory, and we had to deploy ADFS in Advanced Configuration, we also have to install Dirsync using command line, using full SQL configuration. At this scale, Microsoft SQL Express is no longer supported and Dirsync must be installed using SQL Server 2012 Standard or SQL Server 2008 R2 Standard. We will use SQL 2012, the same server that was used in ADFS deployment.
- Join lab-dirsync-01 server to the domain
- Create a new domain account, service-dirsync, and grant this account Domain Admin and Enterprise Admin privileges
- Add this account to local administrators group on the Dirsync server. We will de-elevate this account from Enterprise/Domain admin level after the installation, but it will be used locally on the server to perform configuration tasks in FIM console
- Download and install Microsoft SQL Server 2012 Native Client (sqlncli.msi, 64-bit)
- Download dirsync.exe as explained in the paragraph above
- In elevated PowerShell:
Next, in elevated PowerShell, change to the directory where dirsync.exe is downloaded and install Dirsync binaries using the command below:
On the Welcome screen, click Next.
Accept license agreement and click Next.
Accept default installation path and click Next.
Click Next and Finish when prompted.
Dirsync binaries are now installed. Next we are going to execute Dirsync configuration from the newly installed Dirsync PowerShell module. From the elevated PowerShell:
cd 'c:\program files' cd '.\Windows Azure Active Directory Sync' .\DirSyncInstallShell.psc1
In the WAAD Dirsync console, issue the following command:
Install-OnlineCoexistenceTool -UseSQLServer -SqlServer lab-sql-01.flexecom.com -Verbose -ServiceCredential (Get-Credential)
If your SQL server uses a named instance, add -SqlServerInstance switch.
You will be prompted to provide credentials with an account that has local administrator permissions. Use service-dirsync account that was created earlier. This account will be used to run FIM services locally on this server and to interact with FIMSynchronizationService database. At this point the installation will go ahead and setup:
- FIM synchronization service on lab-dirsync-01
- FIM database on lab-sql-01
- Install MOSSIA components on lab-dirsync-01
The output will look similar to the following:
Next, install WAAD PowerShell, 64-bit (AdministrationConfig-en.msi).
Now we need to run Dirsync Configuration Wizard to provide it with Office 365 service credentials and get the FIM service up and running. Before you run through the steps below, log off and log back on again as service-dirsync account.
- Double-click on the Directory Sync Configuration icon on the desktop
- Click Next on the welcome screen
- Provide Office 365 administrator credentials when prompted and click Next
- Provide Active Directory Enterprise Admin credentials when prompted and click Next
- On the next screen (Hybrid Deployment) select if you want to enable Hybrid Deployment. This option will be available with on-premises Exchange 2010 deployment, and if enabled, will enable Dirsync to write back a set of attributes to enable rich coexistence between on-prem and online Exchange. We won’t enable this feature. Click Next
- On the next screen (Password Synchronization) select if you want to enable Password Sync. If enabled, this feature will replicate password hashes from on-premises Active Directory to Office 365, and will defeat the purpose of setting up ADFS. Do not enable this feature and click Next.
At this point, the wizard uses service-dirsync with Enterprise Admin privileges to create MSOL_<id> account in Active Directory (Users OU) and permission it to be able to replicate directory changes. This MSOL account will be used by FIM to replicate changes from on-prem AD to Office 365, whereas service-dirsync account will only be used to run FIM services on the dirsync server and connect to SQL database.
On the Finished screen, do NOT check the box to enable immediate synchronization as it may result in many potentially unwanted objects to be replicated right away. Let’s configure OU scoping and/or attribute filtering in Dirsync first.
(In our scenario with 50,000 accounts in AD, we would need to open a support case through Office 365 Portal, to request that Microsoft removes 50,000 object replication limit.)
De-Elevate service-dirsync Account
This is an optional step, but at this point we can de-elevate service-dirsync account. To do this, first, create a new SQL login for service-dirsync account in the SQL Server Management Studio on the SQL server used for Dirsync.
Then remove Domain Admin and Enterprise Admin group membership from service-dirsync account in Active Directory. Now would be a good time to also patch and reboot the Dirsync server.
Step 16: Configure Dirsync Filtering
Dirsync filtering can be set up on a domain, OU, or attribute level. With that said, some types of objects are not easily filterable at the attribute level, at least not in a supported way. For this reason you may find that a combination of OU filtering and attribute filtering works best.
To configure OU-level filtering (or scoping), log on to the Dirsync server (lab-dirsync-01) using Dirsync service account (service-dirsync). Navigate to C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell. Launch miisclient.exe.
Click on Management Agents tab
Double-click on Active Directory Connector and then click on Configure Directory Partitions
Click on Containers button and provide administrator credentials (delete MSOL username, do not use that account)
On the next dialog, uncheck all containers at the root level, and only check the OUs that you want to synchronize
Click OK once to return to the Active Directory Connector properties screen. Click on Configure Connector Filter and then select the user object. All filters defined for the user object will be displayed.
To configure attribute filtering, click the New button. In our setup, I want to only replicate user objects that match two additional condition, over everything else that Microsoft has pre-defined:
- userPrincipalName attribute contains @flexecom.com string
- mail attribute contains @flexecom.com string
In the first case, we want to ensure that user accounts get provisioned correctly in Office 365 and that they work with our federated domain, flexecom.com. Any account that does not have @flexecom.com in the UPN attribute, would replicate as firstname.lastname@example.org and subsequently the user logging in with email@example.com account won’t be able to access the service.
In the second case, we want to ensure that primary SMTP addresses are stamped correctly by Exchange Online. For the user account to get the right primary SMTP address, it needs to be mailbox-enabled using Exchange 2010 or Exchange 2013 management console on-premises. Alternatively, you could just set the mail attribute manually (or programatically) and mail-enable the user instead. In our case we do not have Exchange installed on-prem, and therefore will not be mailbox-enabling users; if mail attribute is not set, Exchange Online will not know which SMTP domain this user belongs to and will stamp @company.onmicrosoft.com as the default SMTP address. To avoid this, we will not even replicate the account to Office 365 unless it has @flexecom.com address set in the mail attribute, this will ensure that firstname.lastname@example.org becomes the primary SMTP address in the cloud on all user objects that do get replicated.
Click on New, select mail attribute, select “does not contain” condition, type in @flexecom.com in the Value field, click on Add Condition and click OK.
Note the double negative. If mail “does NOT contain” @flexecom.com, it is filtered = NOT replicated.
Repeat the steps to add a new rule with one condition for userPrincipalName (note: adding multiple conditions to the same rule works as AND in FIM; adding multiple filtering rules with a single condition has the OR effect, which is what we want).
OK to save the filters and go back to the main FIM console screen.
Step 17: Kick Off the Full Sync
There are three ways to tweak the default replication schedule in Dirsync:
- Kick off replication run manually from the PowerShell command line
- Kick off replication run manually from the FIM console
- Adjust the default 3 hour interval for the automated runs
The easiest way to trigger replication run manually is to launch C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1 from an elevated PowerShell session, and issue the following command:
The inner workings of FIM are a little outside the scope of this post but just to mention this in the Dirsync troubleshooting context, FIM console is invaluable in seeing what is going through the directory replication logic and into Office 365.
Another way to start the synchronization run is to click on the Actions menu in FIM console, select Active Directory Connector in the Management Agent drop-down, and select either Full Import Full Sync profile, or Delta Import Delta Sync. The first time you run this, you will probably want to go for the Full run, and most subsequent runs will be better off with Delta.
The third way to influence how frequently the replication runs are executed is to modify the configuration file C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.config. Default interval is 3 hours but you can set it to run as frequently as every 15 or 30 minutes. When you make changes to this configuration file, restart Windows Azure Active Directory Sync Service.
To make sure that our DirSync is working, create a couple of user accounts with email@example.com in the UPN logon name as well as mail attribute, and trigger the full sync. These accounts will be replicated in a matter of 1-2 minutes and should appear in Office 365 Portal very quickly, with status “Synced with Active Directory”.
From the WAAD PowerShell command line:
Connect-MsolService Get-MsolCompanyInformation | fl LastDirSyncTime
This will print the last time DirSync contacted Office 365 as seen from Office 365 side.
In the next post we will deal with things like bulk activation of DirSynced users in Office 365, GAL segmentation, and client configuration.