As I mentioned in my intro post on Identity in Office 365, there are a couple of different ways your organization can go about provisioning user accounts in Office 365. Just to review, here they are again:
- Managed IDs – these are also known as “MSO IDs” or “Cloud IDs”, accounts which you create directly in Office 365 and manage there as well.
- Federated IDs – these are accounts based in a local Active Directory environment that you manage. It requires that you configure federation between your AD and the Office 365 Cloud, but allows users to log in with accounts they’ve already been using and maintain a single username and password for both on-premise and Cloud systems.
- DirSync without Federation – As my friend Mike Holcomb pointed out in an comment on my intro post, there is a third option available: synchronizing accounts up to Office 365 via DirSync without configuring AD Federation. It is less complicated to configure than AD Federation, but only synchronizes accounts to the cloud, not passwords.
To me, the options available for account management with Office 365 are a really big reason why it can be such a compelling option for a wide range of businesses of all sizes. There really is a lot of flexibility in how you can choose to create accounts, take advantage of existing identity resources you may already be using, as well as provide a low-friction experience for your end users that doesn’t require them to track multiple accounts and passwords. Now, that’s not to say that it’s perfect, but in general I think it’s a compelling selling point for Office 365.
Please keep in mind that the info I’m providing here is meant as an introduction to the topic, and that there’s a good chance that it will change and develop over time as Office 365 matures. For the most up to date information on accounts in Office 365, you should definitely refer to the excellent Office 365 Identity Service Description document available for download from Microsoft, it should be considered your authoritative and current source.
Now that we’ve set the stage, let’s take a look at each of the options above and take a look at why they can make sense for a company, as well as some of the considerations and drawbacks that also need to be taken into account when deciding which one is the best choice for an organization looking to move to the cloud…
Managed IDs
Managed IDs exist only in the Office 365 cloud, these are accounts that you create and manage in your Office 365 environment, without needing to create, configure, or set up any local Identity systems like Active Directory or Small Business Server. Managed IDs are perfect for organizations that want to limit their reliance on local IT systems, or don’t want to have any local servers or log-ins at all. They’re also great for organizations that are what we refer to as “greenfield” situations; just getting started with their infrastructure so there’s a clean slate when it comes to Identity solutions. That’s not to say that you can’t switch over to Managed IDs with Office 365 if you are already using something like Small Business Server or Active Directory, I’m just saying that there will be additional costs you’ll have to consider in transitioning to the cloud around moving over your accounts and training your users on using the new accounts. The issue of training users can be a big one that’s easily overlooked, especially if they’re already used to using a different system.
With Managed IDs, you have to remember that you will have little control over a lot of the policies that Microsoft is using to govern these accounts in Office 365. You do have more control with Office 365 than was available with BPOS, but you’re still going to have to accept some of the constraints that Microsoft has defined for Managed IDs and be ready to work within them. This includes set minimum and maximum password lengths, set password complexity and strength rules, 90 day password expiry duration, password history restrictions, and account lockout rules. One nice change from Office 365 to BPOS, you can actually disable password expiry for Managed IDs in Office 365 if you want.
Managed IDs also benefit greatly from the new delegated administration roles that can be applied to accounts in Office 365, something else that wasn’t before possible in BPOS. Now you can assign a user rights to manage subscriptions and Managed IDS and/or reset passwords on Managed IDs without having to make them a full administrator of your Office 365 service.
One final item to consider in the area of managing Office 365 is that you have to have access to the Office 365 Administration web site (or have the Office 365 PowerShell CMDLETs installed locally) to be able to carry out your management activities. This may not be a big deal, given that a robust and reliable connection to the Internet is a big general prerequisite (in my mind) for using Office 365, but it’s worth noting, just in case.
Federated IDs
Federated IDs exist in a local account repository (at this time only Active Directory (AD) is supported, and while I don’t expect that to change, you never know), and are connected up to an Office 365 environment in the cloud via Active Directory Federation Services (ADFS). (As an aside, “federation” is a term that comes up quite frequently in Office 365, but it doesn’t always mean the same thing depend on the context it’s used in) Federated IDs are user accounts that you create in an Active Directory domain running on your own servers and through that ADFS connection are recognized by Office 365 as a valid user account in the cloud.
If your organization already has an AD domain up and running (typically referred to as a “brownfield” scenario, the other side of the “greenfield” coin I mentioned above), then you should very seriously consider going with Federated IDs and ADFS instead of Managed IDs. Federated IDs allow you to continue to use your existing tools and policies to manage your accounts, giving you complete control over your security policies (password expiration, password complexity, etc.) and account lifecycles. It also provides your users with a seamless user experience, because they only have one account to manage and use to log in to your systems. Federated IDs can also be used in greenfield situations if your organization would prefer to have more control over the IDs you provision for your users in Office 365, but setting it up will increase the time it will take you to roll out Office 365 to your users.
While Federated IDs do provide you with a great deal more control over your accounts, you need to keep in mind that this is not without some drawbacks. The biggest one is that you’re going to need to continue to spend time to maintain and administer your local AD domain, so you won’t be making a “total” move to the cloud. For many large organizations with other local servers or applications that rely on AD, this probably isn’t a big deal, but that care and feeding is still something you need to remember to plan and budget for. Also, ADFS usually requires additional configuration and administration above and beyond normal AD management as well as likely necessitate additional servers (could be physical or virtual) to host both ADFS itself, which can be tricky (especially if you’ve never done it before) AND the Office 365 DirSync tool (this is required for Federation, but as shown below you can run it without Federation). Finally, it also places a premium on the availability of your Internet connection to Office 365, because if that connection goes down you will not be able to push up updates to your local accounts into the cloud and your users may not be able to log in at all.
DirSync without Federation
DirSync is a tool provided by Microsoft that was originally intended as a tool to be used to do short-term migration of user accounts from a local AD environment up to BPOS. Basically, the BPOS DirSync tool was a stripped down version of a product called Microsoft Identity Integration Server (MIIS, which is now known as Forefront Identity Manager), which scanned through an AD domain and did a copy of all email enabled accounts into BPOS where they could be assigned a User Subscription License (USL) to be activated. This was seen as Microsoft as a way to help a company do a one-time migration of existing accounts into the BPOS cloud, or to be run during a brief period of co-existence if a migration could not be completed during a single window of time. But, as often happens with useful tools, Microsoft’s customers found that they usually preferred to make that period of co-existence permanent, managing their accounts with their existing AD tools and procedures, then copying them up to the cloud with DirSync.
The DirSync option is still available with Office 365, but there are a few things to keep in mind about it. It’s best suited for situations where you’re using some sort of a co-existence set up (either over a short period of time for a migration, or for the long term), but you also have to be careful because there are some situations where it is not supported for use (such as intermittent use solely for user creation, syncing multiple AD forests, or attempting to filter syncing to a scope smaller than all trusted domains). The other important aspect of DirSync to remember is that by default it is a limited, one-way synchronization from AD up to Office 365. One-way because it is not possible to synchronize objects from Office 365 back down to your AD domain, which means that you can only create new accounts in AD, you cannot create them in Office 365. Limited because only certain types of objects are sync’d (users, mail-enabled groups, security groups, and contacts) from AD to Office 365 and because passwords are not included in that sync, which means that users must managed their passwords in both AD and Office 365, as they must with Managed IDs. NOTE: there is some limited capabilities to write data from Office 365 back to AD through DirSync, but there is not much detailed information available from Microsoft on this feature, so I’d recommend treading lightly and testing heavily if you want to look at this.
For more information on what AD attributes are synchronized from AD to Office 365 by the DirSync tool, I’d recommend checking out this page: http://support.microsoft.com/kb/2256198
), Exchange, and Lync. While all the hybrid options are great, they also lead to a lot of questions and confusion about what they can and can’t do. This is a helpful FAQ breaking down calendaring differs and integrates between Exchange Server 2010 SP1 and Exchange Online: 
: 
