“Run your business, not your mail server.” I am not sure where I read that, but it makes so much sense! Every organization is moving to the cloud, and some just haven't started their journey yet. One of the fastest and most compelling online cloud based offerings is Office 365. Available in various SKUs, you can get SharePoint, Lync, Exchange, and Office professional as cloud-based offerings. The subscriptions are as low as $2 per user per month to $20 something per user per month. Also, with SharePoint 2013, if you buy Office 365 subscriptions for your users, you don't need to buy CALs (Client Access Licenses) for on-premises use.

It is therefore no surprise that Office 365 is gaining mass acceptance. Any organization choosing to completely ignore Office 365 is making a mistake.

It is therefore no surprise that Office 365 is gaining mass acceptance.

But, large organizations cannot ditch on-premises systems either. In fact, a lot of systems will remain on-premises for a long time. Additionally, even those who have every intention of ditching on-premise installations of SharePoint, Lync, and Exchange completely will have to contend with a transition period.

Business users whose mailboxes have been migrated into Office 365, will expect their mail to be present when they open Outlook. They will expect the same sign on experience, and some might even expect search facilities to work exactly like they used to. How do you manage a move like that for thousands of users without lighting up the call buttons of the helpdesk?

How do you manage a move like that for thousands of users without lighting up the call buttons of the helpdesk?

There are many things to consider when thinking of migration:

  • User experience
  • Identity management
  • Data security
  • Feature set
  • Integration with internal systems
  • Even how you budget your dollars for next year.

Moving to the cloud is not a point-and-click operation. I suspect it is something that will keep us techies engaged for the next many years to come. But in this article, I will focus on one of the key tenets of migrating from on-premises to Office 365, which is “Identity Management.”

Organizations are used to things such as single sign-on, password policy control with expiry/notification, or role-based administration. Or maybe smart card integration and two-factor authentication. Or hybrid scenarios, where not all Exchange accounts can be moved to Office 365 instantly, or where a single search in a SharePoint site brings together information from disparate systems on a single page. These are things organizations take for granted in on-premises Active Directory.

These are things organizations take for granted in on-premises Active Directory.

Does Office 365 satisfy these needs? You bet it does! It does so by allowing you to integrate your on-premises Active Directory with Office 365. But is it straightforward? Keep reading.

Identity Types in Office 365

You can log on to Office 365 in many ways. The simplest mechanism is to log on using a Microsoft account, previously known as Windows Live ID.

But in most scenarios, you will probably use an organization account. There are three types of organization accounts you can use with Office 365.

  • An Office 365 ID provided and hosted by Microsoft, typically looks like sahilmalik@winsmarts.onmicrosoft.com. The advantage of this sort of account is that it is perfect for starter organizations. Perhaps you have no on-premise Active Directory, you have no IT department, and you don't want to wait to get started. You don't have to set up any servers on your own premises. The disadvantage here of course is, yet another username and password to remember, no single sign-on experience, no two-factor authentication, and the password policies you can set are limited to what Office 365 can offer.
  • An organization ID that is assigned by Microsoft but validated against the user's Active Directory ID. In this scenario, the user must have an on-premise domain\user logon ID. The username and password is validated against the organization Active Directory database, and access to Office 365 resources is granted.
  • An organization ID that is assigned by Microsoft, but validated against ADFS. In this scenario, a user such as sahilmalik@winsmarts.onmicrosoft.com wishes to access a partner organization's resources. In this scenario, Sahil Malik will have to authenticate using a username password with the partner organization's Active Directory. The username password is then passed to the partner's federated Active Directory database, and Sahil Malik is granted access to the organization's resource.

Also, as an administrator, there are various registry keys you can set to administer Office 365. You can read about them here http://blah.winsmarts.com/2013-5-Registry_keys_to_administer_Office_365_in_your_Organization.aspx. Editor's note: this link is no longer valid; Sahil has removed the original content.

Active Directory Integration Options in Office 365

You can, of course, choose to go with just Microsoft identities. But most medium-to-large organizations that care to integrate their AD with Office 365, have two main options:

  • Directory sync only, where you set up a computer with the directory sync tool. The directory sync utility is fairly easy to setup and run. You set it up on a Windows server and just let it run. It runs automatically once every three hours, and it can work with SQL Express, but if you have more than 50,000 objects in your Active Directory, you should probably also look into adding a full SQL Server to this sync tool. This mechanism allows you to enable hybrid scenarios where, say, not all Exchange users are migrated into the cloud at once (or ever). Users, groups, and their policies can be managed on-premise. But you still do not get a full SSO (single sign-on) experience or two-factor authentication etc.
  • Directory sync and SSO is the best possible integration that typically also requires a higher financial investment, and is therefore suited for larger enterprises. The biggest disadvantage is that you need high availability for your ADFS (active directory federation services) installation. If the ADFS server goes down, no one can login. But besides that, you get SSO with corporate credentials, users and groups can be managed on premises, two-factor authentication is possible, and identities can be managed on-premises. This is the most automated solution.

In order to set up Active Directory integration with Office 365, you need your Active Directory forest functionality to be at level 2003-something directory sync requires. Even though you can set up the dirsync (Directory Sync) tool on Windows 2003 32-bit, I highly recommend that you install it on at least Windows 2008 and use a 64-bit OS. The 32-bit tool, even though it is available, is deprecated. For ADFS 2.0, you need to set up a Windows Server 2008 or Windows Server 2012 computer. All involved servers can also be virtualized.

Even though you can set up the dirsync (Directory Sync) tool on Windows 2003 32-bit, I highly recommend that you install it on at least Windows 2008 and use a 64-bit OS.

When you set up the dirsync tool, you can choose to set it up as a one-way synch or a two-way synch. As the name suggests, a one-way synch is Active Directory-to-cloud, and you can move to a two-way synch later. A two-way synch is required for hybrid deployments and you cannot move back to one-way synch. The cloud becomes master for some properties, such as safe senders etc.

Before you set up dirsync and ADFS, you must do some basic checks on your Active Directory to ensure it is ready. There are some basic requirements:

  • You need to create a load-balanced highly available installation of ADFS 2.0 services.
  • Every user in your organization must have a UPN.
  • The UPN suffix must match a validated domain in Office 365, which means that you must pre-validate your Office 365 account with a domain that you own and intend to sync.
  • There are some UPN character restrictions, although letters, numbers and .-_!#^~ are allowed. There is no dot before the @ symbol, so sahil.malik@winsmarts.com is acceptable, but sahilmalik.@winsmarts.com is not acceptable. This is important because the on-premises Active Directory does not have such limitations.

If this sounds like a lot to check, there is help. You can - and perhaps should - use the Office 365 deployment readiness tool, which will check the above rules and many more. You can find this tool at http://community.office365.com/en-us/forums/183/p/2285/8155.aspx. Editor's note: This link no longer resolves.

You can - and perhaps should - use the Office 365 deployment readiness tool, which will check the above rules and many more.

This tool does not send any information to Microsoft, and it does not make any changes to your Active Directory. It just checks your Active Directory against many rules, and ensures that your Active Directory is ready to synch.

In fact, there are many scenarios that are not errors, but prevent certain objects from synching. A group without a display name or duplicate proxy addresses are perfectly okay in on-premises Active Directory, but these will not be synched to Office 365; these are things that the Office 365 deployment readiness tool will flag for you and allow you to fix.

Once dirsync is set up, it syncs the whole attribute set of the synced objects every three hours. You cannot change the sync period (three hours) and you cannot synch a subset of attributes. It will not, however, synch default accounts, such as domain\administrator or system objects. And even though you can't change the three-hour duration for synch periods, you can turn dirsynch off completely if you wish and turn it back on at a later date. Turning synch on and off are manual operations that may take some planning and time.

Summary

Everyone! Get on the cloud bandwagon, NOW! It's not that easy, is it? There is probably a lot of planning, scrubbing of data, and re-architecture of internal systems to be done before you can start your journey to the cloud. But the benefits are undeniable: cost savings, flexibility, and even security, are all reasons why everyone will eventually move to the cloud.

In migrating from on-premises SharePoint to Office 365, identity will be one of the big-ticket items you will need to plan for. I hope this article gave you some insight into what to consider. I'll talk of more such fun stuff in the next article.

Until then, Happy SharePointing.