Directory Synchronisation

Directory Synchronisation

Brief Overview of Directory Synchronisation (DirSync)

The Windows Azure Active Directory (AD) Synchronisation Tool is an application that synchronises the on premises Active Directory with Microsoft Online Services. This allows services like Office365 to provision the user structure for migration to the cloud.

It is good practice to install this tool on only one computer in the local network of the domain you are migrating, it is also good practice to tightly restrict access, as you would with a Domain Controller or other sensitive network infrastructure.

Dir Sync effectively synchronises the full set of attributes from your on premise Active Directory to the Windows Azure AD tenant used for Microsoft Online Services, once provisioned in Windows Azure AD, services such as Exchange Online can utilise this infrastructure to ensure a relationship between the users details on premise to in the cloud. The latest edition of Dir Sync provides a simple-sign on process using the Password Synchronisation feature, or you can utilise the Single Sign-On experience of ADFS (Active Directory Federation Services). In addition to this, a small set of attributes can be synced back from Windows Azure AD to the one premises infrastructure.

Preperation is the key to Dir Sync

An administrator must complete some basic preparation before being able to synchronise their on premise AD to the Windows Azure AD.

This process includes deciding on a ‘simple sign-on’ or ‘single sign-on’ environment.

Simple sign-on – Allows the synchronisation of the on premise AD DS password hash with Windows Azure AD to allow users to authenticate to Windows Azure Ad using their UPN (User Principle Name) and corporate password.

Single sign-on – Identity Federation enables a company’s users to authenticate using the customers corporate AD. This process requires on premise hardware and configuration separate to the Simple sign-on process, but can give some benefits which I will touch on later.

Dir Sync requires certain prerequisites in order to perform a successful migration, these include;

Joined to the Active Directory Forest – The computer must be domain joined, it will need to contact all the DC’s for all the domains in the forest**

** A forest is one or more Active Directory domains that share the same class and attribute definitions, site and replication information, and forest-wide search capabilities.

Dedicated Server (Best Practice but not a requirement) – This is a good practice recommendation to avoid interference with other applications or services on the particular server. EDIT ********Can now be installed on a Domain Controller!

Running a supported Windows Server OS – 64-bit edition of Windows Server 2008 Standard or Enterprise, Windows Server 2008 R2 Standard or Enterprise, Windows Server 2008 Datacentre or Windows Server 2008 R2 Datacentre, or 64-bit edition of Windows Server 2012 Standard or Datacentre.

Running Microsoft .NET Framework version 3.5 or later – Server 2008 R2 upwards this can be added as a feature through Server Manager.

Running Windows PowerShell – Windows Server 2008 R2 upwards has PowerShell installed by default.

Access-Controlled environment – Access to the computer should be limited to administrators only.

Running Microsoft SQL Server Software – If you have more than 50,000 AD objects you will require MS SQL 2009 Standard / R2, if you have less than this number you can utilise the default SQL Express database which is installed as part of the Dir Sync process.

Things to Consider

Active Directory Object Limit (as mentioned above) – Default limit of 50,000 objects in Windows Azure AD, to increase this limit you will need to contact Microsoft Cloud Services support and request an increase. Expect a week or more to have this resolved.

When using Simple Sign-On – Consider turning on the Password synchronisation Feature of the Windows Azure AD Synchronisation Tool. However, this should be enabled, after a migration, as this can interfere with certain functions of the migration.

Directory Synchronisation write-back – Write-back is required to enable full rich coexistence, if Exchange hybrid servers are not to be deployed or there is no Exchange server on premise then write-back is not required. If enabled – only a few attributes will be written to the on-premises AD service. Microsoft Exchange Server 2010 SP3 schema extensions will need to be installed to enable write-back, this is included in latest versions.

Service Account Requirements

The Windows Azure AD Sync Configuration Wizard will create a service account in your local AD, this will require your intended Windows server to be domain joined. The installation wizard creates this account using the local AD permissions that you provide.

To prepare, create or use 2 service accounts;

  • An Enterprise Administrator account in the on-premise AD domain.
  • A Global Administrator account in Office 365. (Set to never expire)

The details of these accounts will be required later in the installation.

Existing user accounts will be soft matched if they are already in existence in the Windows Azure AD, if this is the case please use this link to further elaborate on this process – http://support.microsoft.com/kb/2641663

Activating Directory Synchronisation

Directory Synchronisation must be activated before installing the Directory Synchronisation Tool, Microsoft strongly recommends that you leave it activated for the entire time that directories are being synchronised. Once deactivated the source of authority is transferred from the on premise AD domain to the cloud.

Dir Sync must be deactivated if you wish to transfer all user, group, contact, and mailbox management to the cloud. For example a company that used the staged migration tools to move their mailboxes to the cloud and no longer want to manage objects from on premise, can deactivate Dir sync.

To activate directory synchronization, log into your Office 365 portal and follow these steps:

  1. Select Office 365 from the Admin dropdown in the header.
dirsync1

Figure 1: Office 365 Admin dropdown

2.            Click users and groups in the left pane of the Admin page.

dirsync2

Figure 2: Office 365 user and groups

3.            Click Set up located at the right beside the Active Directory synchronization tag.

dirsync3


Figure 3: Office 365 Active Directory synchronization setup

4.            Follow the onscreen steps to activate the directory synchronization features.

dirsync4

Figure 4: Office 365 directory synchronization steps

Please be aware that this may take up to 24 hours to take effect. The portal updates with the status of the configuration change. Please wait until the configuration is complete, before proceeding.

Installing the Dir Sync Tool

After activating Windows Azure AD synchronisation for Office365, you can download the Dir Sync Tool. This is either utilised in the SQL Server Express version for less than 50,000 AD objects or a full SQL Server instance for more than 50,000 objects.

The process for downloading this is below;

1.            Access the Office 365 portal.

2.            Select Office 365 from the Admin dropdown in the header.

3.            Click users and groups located in the left pane of the Admin page.

4.            Click Set up located at the right beside the Active Directory synchronization tag.

5.            Click download under step 4 and follow the instructions to save the installation file on your computer.

dirsync5

Figure 5: Directory Synchronization Tool download

6.            Verify that the Microsoft Online Directory Synchronization Tool package downloaded to your computer.

Installing Dir Sync Tool – Less than 50,000 objects

1. On the computer where you want to install directory sync install the following; http://go.microsoft.com/fwlink/?LinkID=278924 (64bit)

2. Follow the instructions in the Setup wizard.

3. On the last page of the wizard, select Start Configuration Wizard now, and then click Finish to start the Windows Azure Active Directory Sync tool configuration wizard.

4. Provide the Enterprise Administrator and Windows Azure Active Directory credentials as prompted.

5. Enable the optional features that are required.

6. When prompted, check Synchronize your directories now to start synchronization.

 

Installing Dir Sync Tool – More than 50,000 objects

The Directory Synchronization Tool can be installed in Wizard mode, which provides step-by-step guidance through the installation process. Double-click the installation package and follow the directions to install. Continue with the following steps when using full SQL:

1.            Log onto the Directory Synchronization Server.

2.            Click Start, then Run.

3.            Type CMD and click OK.

4.            Type the path to where you saved the Directory Synchronization Tool package.

5.            Type DirSync.exe /fullsql and click Enter. If prompted with a User Account Control prompt, do either of the following:

a.            Click Continue.

b.            Enter the username and password of the on-premises service account and click OK.

Note: The fullsql switch installs DirSync without installing SQL Express. The install stops after the Install-OnlineCoexistence cmdlet is installed.

6.            Click Next through to the end of the wizard and then click Finish.

Important: The Directory Synchronization Tool installation is completed using Windows PowerShell.

7.            On the Directory Synchronization computer, open Windows PowerShell by opening the command-line tool and entering the command Powershell.exe -noexit.

8.            Press Enter.

9.            Type Add-PSSnapin Coexistence-Install at the Windows PowerShell prompt.

10.         To install the Directory Synchronization Tool

a.            Using a remote installation of SQL Server 2008, type

Install-OnlineCoexistenceTool –UseSQLServer –SqlServer <SQLServerName> -ServiceCredential (Get-Credential) –Verbose

Sample:

PS C:\Temp> Install-OnlineCoexistenceTool -UseSQLServer -SqlServer “SERVER\INSTANCE” -ServiceCredential (Get-Credential) -Verbose

b.            Onto the same system as SQL Server 2008, type

Install-OnlineCoexistenceTool –UseSQLServer –Verbose.

11.         At the Windows PowerShell Credential Request prompt, type the username and password of the on-premises service account.

Configuring the Directory Synchronisation Tool

After installing the latest supported version of SQL Server 2008, completing the Microsoft Online Services Directory Synchronization Tool Configuration Wizard is required for synchronization to occur.

  1. From the Directory Synchronization server, click Start/All Programs/Microsoft Directory Sync and then click Directory Sync Configuration.
  2. Click Next.
  3. Provide the username and password for a user account with Administrator permissions in your organization on the Microsoft Online Services Credentials page of the Microsoft Online Services Directory Synchronization Configuration Wizard and click Next.
  4. Provide the username and password for a user account with Enterprise Admin permissions on the on-premises Active Directory service located on the Active Directory Credentials page of the Microsoft Online Services Directory Synchronization Configuration Wizard and click Next.
  5. Select Enable rich coexistence if you would like to enable it and click Next.
  6. Select Enable Password Sync if you would like to enable it and click Next
  7. Click Next to complete the configuration.
  8. Select Synchronize directories now on the Finish page and then click Finish.

Verifying Directory Synchronisation

If you want to check that Active Directory synchronisation is provisioning users, groups and contacts from on premise apps to the cloud correctly, you can verify your directory sync.

After automatic synchronisation

  1. Sign in to the cloud service with service administrator credentials.
  2. When directory synchronization is complete, verify that the changes you made in your local Active Directory now appear in the cloud.

After forced synchronisation

  1. Ensure that there is a valid email address for your organization’s designated cloud service technical contact.
  2. Sign in to the cloud service with service administrator credentials.
  3. Verify the additional properties of a specific user account (such as Job title, Department, or Street address) that will be synchronized from your local Active Directory to Windows Azure AD.
  4. Verify that you cannot edit the additional properties of that user account in Windows Azure AD.
  5. Log on to your local Active Directory with the permissions needed to edit user accounts, contacts, and distribution groups.
  6. In your local Active Directory, make a simple but obvious change to one of the additional properties of the specific user account.
  7. Open the Windows Azure Active Directory Sync tool Configuration Wizard.

a. Provide the information requested on the wizard pages.

b. On the Finished page, select Synchronize your directories now, and then click Finish.

  1. When directory synchronization is complete, view the additional properties of the user in Windows Azure AD, and verify that the change you made to the additional properties of the specific user account in your local Active Directory have been synchronized to Windows Azure AD.

Synchronisation Notes

•     To verify that the Directory Synchronization Tool is working from your local Active Directory service to Microsoft Office 365, testing both manual synchronization and automatic synchronization is required. It may take up to three hours to complete this process.

•     The Directory Synchronization Tool writes entries to the directory synchronization computer’s event log. These entries indicate the start and end of a directory synchronization session.

•     Directory synchronization errors are reported in the event log and emailed to your organization’s designated technical contact.

•     When reviewing the event log, look for entries with Directory Synchronization as the source. An entry designated as Event 4 with the description “The export has completed” indicates that the directory synchronization is complete.

  • When directory synchronization is installed, the local Active Directory becomes the master for all changes to the synchronized mail-enabled objects in Office 365.

The Federation Server As a Claims Provider

To summarise this particular post;

  • The Claims Provider presents a web service that can issue security tokens containing claims in a standardized format (SAML – Security Assertion Mark-up Language)
  • The Claims Provider allows administrators to publish policy data about the claims provider, which a relying party federation server can retrieve and use as part of the federation relationship.

The federation server is a computer that runs a security conscious service that issues security tokens.

When the federation server is given the role of a Claims Provider (CP) it allows authentication capabilities; whereas in the Relaying Party (RP) role it acts as a passage that allows identities to travel between different security boundaries.

In the case of Office 365 – Active Directory Federation Services (AD FS 2.0) is the Windows Server role that provides this federation server functionality. In this implementation, ADFS can fulfil either of the above functions – Claims Provider or Relaying Party.

As a Claims Provider;

  • Processes requests from incoming users to provide signed tokens containing claims that represent the user’s digital identity.
  • Claim information can consist of – user’s name, role or group membership etc.
  • ADFS issues tokens in a SAML format.
  • ADFS can protect the contents of security tokens in transit by signing and encrypting them.

Side note – ADFS 2.0 allows you to encrypt tokens, previous versions were only digitally signed.

As a Relaying Party;

  • Receives tokens from a trusted Identity Provider.
  • Will issue new security tokens that a local application can consume to make authorisation and personalisation decisions.
  • By using a relaying party, organisations such as Microsoft are able to provide ‘Single Sign-On‘ (SSO) for Office 365, crossing the boundaries between ‘signing on locally’ and authorising use within the ‘cloud’.

The two above terms can be further defined as follows;

Claims Provider – An organisation that is responsible for the user identities in a federated relationship. (In our examples this will be the organisation with the Active Directory infrastructure (onsite))

Relaying Party – The organisation that is responsible for administering and protecting the web-based resources and other claims-based applications. (In our example this would be the cloud- Office 365)

Working together

In a Federation Trust Relationship, the Relaying Party is the partner that trusts (or relies on) a Claims Provider to authenticate users, this takes the process of user authentication from the applications and web services that are managed by the RP. The RP consumes the claims from the CP, which it verifies through, typically, a PKI certificate.

%d bloggers like this: