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.

Lync Server 2013 – Brief Overview #lync2013

Below is the list of server roles available to your Lync 2013 on-premises environment;

  • Back-End Server
  • Front-End Server
  • Standard Edition Server
  • Director
  • Mediation Server
  • Edge Server
  • Persistent Chat Compliance Back End Server
  • Persistent Chat Server
  • Persistent Chat Back End Server

Lync 2013 Clients;

  • Lync 2013
  • Lync 2013 Basic
  • Lync 2013 Web App
  • Lync Win Store App
  • Lync 2013 Mobile
  • Lync 2013 Phone Edition (being phased out)

Administrative tools and enhancements to Lync Server 2013;

  • Lync Server Deployment Wizard
  • Lync Server Control Panel
  • Lync Server Management Shell
  • Lync Server Topology Builder
  • Central management database
  • Role-Based access control
  • DNS load balancing
  • Lync Centralized Logging Service

Lync Server – Hybrid Coexistence

Lync Hybrid diagram

Lync Hybrid

ADFS Certificate Requirements

Federation Trust and PKI

The federation trust is the key component by which secure communications in AD FS is made possible. It is not only the only PKI requirement for AD FS but it is a fundamental one, without which much of the functionality of AD FS would not be possible. There is nothing unique to ADFS about the federation trust, except the name, because it is a regular PKI implementation that may even already be in place and used by other server components for other purposes – so in this case, it can ALSO be used by AD FS.

Certificate Trust Models

It is possible to install and configure Microsoft Certificate Services to provide not only the federation trust but also all the other PKI certificate requirements. It is advisable in many cases, however, to purchase the appropriate certificates from a mutually trusted root CA (Internet root CA), so client computers from different organisations will be able to trust the various certificates involved in the AD FS deployment.

Although, this can increase the cost involved in deploying ADFS, it eases the process of establishing the PKI trust across organisational boundaries.

The main reasons to consider using an internal, corporate PKI, rather than using an externally trusted CA include;

  • Cost – Building a Windows PKI is free with the OS. (Although a catch-22 here may be that you will require on-site staff that can administer, maintain and secure the software and hardware associated with an internal PKI)
  • Control – Organisations have greater control over how the PKI is built and how, when, and where certificates are issued.
  • Existing Infrastructure – This provides an existing PKI that can be easily adapted to support ADFS.

 

ADFS Overview

Prerequisites

ADFS was first introduced in Windows Server 2003 R2 Enterprise Edition – This uses ADFS V1

In order to use the latest version of ADFS (V2) you will need to be running Windows Server 2008 SP2 or Windows Server 2008 R2. (This also includes Server 2012)

ADFS 2.0 does not require a particular operating system level and neither versions require a particular domain functional level or forest functional level for the AD Domain Controllers used for authentication.

The Federation service components consist of –

  • The Federation Server (FS)
  • The Federation Server Proxy (FSP)
  • The AD FS web agent (AD FS V1 only)

Networking Requirements

TCP/IP Connectivity –

FS in ADFS do not need to talk directly to each other for applications using the passive requester profile.

FS will communicate directly when using WS-trust, and optionally during metadata exchange.

ADFS and DNS –

Federation Service Proxy (FSP) servers should use the same host name as the federation server they are protecting.

Depending on the solution required, a split DNS configuration may be necessitated.

ADFS requires the deployment of a solid TCP/IP network and DNS name resolution for a successful implementation.

Directory Services and AD FS

AD FS is a technology that allows one location/company/party holding user accounts to project these identities to another party that hosts resources. In order to do this, authentication is required somewhere along the line, ADFS can use AD and ADLDS to accomplish this. ADFS uses Kerberos to authenticate with AD, and a LDAP call when communicating with AD’s younger brother, ADLDS, this call could be secured with an SSL but is not a requirement.

In both versions of ADFS (v1 and v2), Federation servers must be joined to an AD domain. However an Federation Server Proxy (FSP) does not need to be joined to a domain; it is recommended that this isn’t the case and instead used on a workgroup for best practice.

%d bloggers like this: