I keep on neglecting to finish this blog post, so I am going to crank this out. I recently federated a lab environment with Office 365 and I wanted to share the resources and some of my lessons learned. Actually federating with Office 365 is a pretty straight forward task.
In this blog I will capture the major steps I took, capture some lessons learned, and give you the resources you need to get there.
With Office 365 you have a few authentication options:
- Microsoft Online IDs – These are cloud based IDs. They are best for small organizations. Users will have a different log-in a different username and password; so there is no Single Sign On experience for the user accessing cloud services. If there is a two factor authentication requirement, that cannot be supported using this authentication method. You do have the option to bring in your corporate GAL that is managed through on-premise Exchange with the synchronization tool.
- Federated IDs – This is when you decide you want to provide a Single Sign-On (SSO) experience with Office 365. This is enabled through Active Directory Federation Services 2.0 (AD FS 2.0) to be installed on premise. Implementing federations provides the ability to support two-factor authentication and enables co-existence/hybrid scenarios.
- External User Authentication – It is worth mentioning on the side that organizations want to bring in external users and partners to collaborate with them. SharePoint Online supports the ability to create a partner cloud account that is within Office 365 or allow users to authenticate to SharePoint Online with Windows Live ID. The Windows Live ID is very appealing because external users can use whatever email address and password they have to access SharePoint Online.
This is all actually very well documented in the references I am providing at the end blog. The steps for federating with Office 365 are:
- Plan and Prepare
- Deploy Active Directory Federation Services
- Establish a Relying Party Trust with office 365
- Set Up Active Directory Synchronization
- Activation of Services for Users
Plan and Prepare
First thing you really need to sit down, read the materials and come up with execution plan. It is not brain science however knowing your requirements and how people will access Office 365 services will directly affect how you deploy your federation services.
Here are some things to think about:
- Multiple Domains - If you have multiple domains and sub domains you should spend some extra time planning trusts with AD FS.
- Multiple Forests - If you have multiple active directory forests, synchronization and authentication is not currently supported today with Office 365 Multi-tenant. To get around this you can consider consolidating forests or only deploy Office 365 with a primary login forest.
- Deployment Readiness Tool – As part of running the Deployment Readiness Tool, you may have some changes as it will check email domains, AD (required attributes, remove special characters, etc.), networks, DNS, etc.
- DNS – Part of the configuration will require DNS configuration and you need to make sure you are working with a person in your company or organization that can make these configuration changes.
- Access Outside Corporate Network – Need to understand how users will need to get access to your environment. If they will be accessing from home, public areas, etc. you will need to need to deploy proxy servers in your DMZ (will discuss later).
- Two-Factor Authentication – If you need to support two-factor authentication some additional configurations (will discuss later).
- Certificates – You will need SSL and Token Signing Certificates. I highly recommend getting all of this worked out from a logistics perspective before you start, otherwise you will be waiting for people to get things for you.
- Administration Rights – Note that many of the configuration steps require domain administrator rights. You will need to get this person involved and they need to participate as part of the configuration and installation of the service.
Honestly every plan to implement this will differ to some degree based on the current state of your current infrastructure. The link below entitled “Office 365 Single sign-on: Roadmap” along with the “Office 365 Deployment Guide” are your best resources for configuring federation with Office 365.
Initially there are a couple resources that will need to be added such as:
- AD FS 2.0 – Must be installed on-premise to support federation. It is recommended that you add more than AD FS 2.0 server for redundancy purposes and load balance them.
- Directory Synchronization Tool – This tool will synchronization active directory information to Office 365 to support the GAL. The reason why you need to do this is because AD FS only helps with the ability to authenticate, it will not actually allow you to find other users in your organization like in Exchange or SharePoint Online. This cannot be installed on a Domain Controller or AD FS server.
If you need to be able to support users to access Office 365 services when outside the corporate network, you will need to add some additional resources to support the federated authentication.
Federation with External Network Access
The most common documented one is to install AD FS 2.0 Proxy Server(s) in the DMZ (depicted below). Requests come in externally to the proxy servers and then sent through to corporate network to authenticate against AD.
An alternative is to use something like Microsoft Forefront Unified Access Gateway (UAG) for supporting users to access federated Office 365 services when outside the corporate network.
Strong / Two-Factor Authentication
Another common requirement is the need to support two-factor authentication along with federation. If a user is logging in on the corporate network or with a domain joined machine, you can utilize the existing infrastructure to meet this requirement and no further deployment is required except for AD FS 2.0 (which provides the single-sign on experience to Office 365). However if need to extend support of two-factor authentication for users accessing Office 365 services from non-domain joined machines additional configuration is required.
One solution is to use Microsoft Forefront Unified Access Gateway (UAG) SP1 to provide two-factor authentication for these users whom need to access Office 365 services from non-domain joined machines. UAG provides several solutions for two-factor authentication and direct access. One thing to be aware of is UAG supports two-factor authentication for passive federation endpoints (i.e. web clients such as SharePoint Online and OWA). UAG cannot support two-factor authentication for active federation and basic authentication endpoints (i.e. Outlook client, Lync client, ActiveSync). This means providing strong authentication with UAG will be limited to using Office 365 web clients. In my opinion this is not a major limitation for businesses utilizing Office 365 services because typically the only thing that IT will for non-domain joined machines are browsers. Even with bring your own device policies, organizations will typically not support down to the rich client; nor do they really need to.
Another potential solution is to use AD FS 2.0 to enforce strong authentication by modifying the AD FS 2.0 proxy logon page to add two-factor support. This would entail adding extra fields for the users to enter extra factors for authentication. Doing this would require integration with whatever two-factor authentication servers/services that is in place.
In summary, UAG is a good solution for accessing Office 365 service when supporting two-factor authentication for external, non-domain joined machines.
Pilot Single Sign On
Additionally you may be interested in piloting users with single sign-on authentication. There is a great article in the references in this blog that explains how to do this. It is really straight forward. First you will notice that you can always add single sign-on later. You have the ability to create your Office 365 tenant using cloud IDs and when you are ready you can transition over to federated authentication with active directory. Second thing to note is you can even create scenarios where some users authenticate to Office 365 services using a federated account while other users only use cloud based IDs. This can provide you some flexibility in potentially how you want to manage accounts.
- Office 365 Single sign-on: Roadmap - http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125004.aspx
- Office 365 Deployment Guide - http://community.office365.com/modg/default.aspx
- Office 365 Identity Management Service Description - http://www.microsoft.com/download/en/details.aspx?id=13602
- Office 365 Virtual Labs - http://technet.microsoft.com/en-us/office365#tab=1
- ADFS Guidance - http://technet.microsoft.com/en-us/library/adfs2(WS.10).aspx
- How to publish AD FS 2.0 endpoints on to the internet using Microsoft ISA or TMG - http://community.office365.com/en-us/w/sso/293.aspx
- Strong authentication (two-factor, 2FA) for Office 365 - http://community.office365.com/en-us/w/sso/294.aspx
- ADFS and UAG - http://community.office365.com/en-us/f/178/p/4628/20658.aspx
- How to pilot single sign-on in a production user forest - http://community.office365.com/en-us/w/sso/357.aspx