Office 365 has a great deal of information available on Technet and elsewhere on the Internet. Recently, I had to implement ADFS SSO for Office 365 on Windows Server 2012 platform, which lacks official documentation at this time. My experience was that things work fine, mostly, as long as you install the right components from the official sources. This, and the next few posts, are dedicated to ADFS 2.1 deployment on Windows Server 2012.
Windows Server 2012 ADFS for Office 365 – Deployment Steps
At a high level, deployment steps are as follows:
- Setup and verify custom domain in your Office 365 tenant account
- Configure public and private DNS zones for Office 365 services
- Execute Office 365 OnRamp and review results
- Deploy a minimum of 4 Windows Server 2012 servers
- FS server 1, domain joined, core network
- FS server 2, domain joined, core network
- FSP server 1, workgroup, DMZ
- FSP server 2, workgroup, DMZ
- Dirsync server, domain joined, core network
- Optionally, deploy Windows Server 2012 with SQL Server 2012
- Enable federation in your Office 365 tenant configuration
- Enable directory synchronization in your Office 365 tenant configuration
- Install FS servers, configure FS farm
- Install FSP servers, configure FSP farm
- Configure network features (NLB/HLB, firewall rules, external DNS)
- Install Dirsync, configure replication
- Federate ADFS farm with Office 365
Step 4-F becomes mandatory if Active Directory contains 50,000 or more objects. If this is the case, Dirsync and ADFS databases must be on a dedicated (Standard edition) SQL server, and ADFS farm as well as Dirsync server must be installed from the command line, using “Advanced Configuration”, as it is referred to in ADFS 2.0 deployment guide on TechNet.
Optional post-deployment steps may consist of any or all of the following:
- Scope dirsync synchronization to specific OUs
- Filter objects from dirsync synchronization based on attribute values
- Run scripts to set UPN logon name on user accounts and groups
- Run scripts to set mail attribute on users or groups
- Run scripts to fix invalid characters in AD object attributes
- Run scripts to set required attribute values on replicating AD objects
- Configure IdP-Initiated Sign-On pages
- Configure GAL segmentation
- Deploy Sign-In Assistant to domain-joined PCs
- Configure MSIE security zones on domain-joined PCs
- Customize ADFS logon and logoff pages
- Configure ADFS authentication methods
- Create change password self-service portal for external users
- Create scripts for automated licensing of Office 365 accounts
- Create scripts for automated address book policy assignment in Office 365
- Testing, of course
How Long Does It Take to Implement ADFS
At a high level, assuming a simple scenario (2 FS servers, 2 FS proxy servers, one Dirsync server, one SQL server), and assuming that several subject matter experts can work on unrelated items in parallel, 5 business days is sufficient to implement ADFS SSO for Office 365.
In terms of man-hours, with a little bit of documentation and testing, and fully excluding any mail migration, ADFS SSO for Office 365 would normally take 10 days / two weeks.
In reality, this number will fluctuate somewhat depending on the size of the deployment. Environments with 50,000 AD accounts will have more time set aside to correcting invalid characters and missing values in various AD attributes, may take longer to deploy Sign-In Assistant to all domain-joined desktops, etc.
You can download the full project plan from the Downloads page – or here.
In the next post we will dive into the details of installing ADFS 2.1 on Windows Server 2012 for Office 365.