Jason Heyes from Microsoft Premier Support UK posts a great article on ADFS and Office 365 federation.
So, now onto some of the foundation design activities you need to consider to get ready for Office365. I will try to avoid getting into too much detail, but hopefully you will find these guidance notes useful as you start to think about design considerations. In this post I will provide my views on:
-
- What needs to be done with Active Directory
- How to provide authentication against the service
- Network considerations
- How clients will connect
- What are the end user device requirements for accessing Office 365
- How will we provide for co-existence during the migration
1. What needs to be done with Active Directory
· With regards to Active Directory, it is recommended that some general housekeeping is undertaken to ensure only the relevant Organizational Units (OUs), user accounts and groups exist within the Active Directory Forests, and all of their attributes are up to date and maintained.
· A current limitation of Office 365 is that it is currently only possible to perform directory synchronization with MSOnline from a single customer forest, therefore if there is more than one forest in the organization additional remediation work will need to be undertaken. This will impact on the tenancy model an organization needs to implement for Office 365, and there are several possible options when in this situation:
i. Multi-tenant, account forest – utilizes multiple tenants in Office 365. This option would require the creation of a new Authentication Forest at each of the regional levels and users from the respective regional Forests being migrated to that Authentication Forest. This Authentication Forest would not only be the point at which Directory Synchronization occurs for Online Services but it would also form the foundation for an Active Directory consolidation to rationalize the Forests within a region.
ii. Multi-tenant, dirsync forest – again, utilizes multiple different tenants in Office 365. This option differs in that it would require the creation of a new Forest at the regional levels, however the users would remain in their respective regional Forests with only Directory Synchronization occurring to allow the creation of their identities within their respective tenant.
iii. Single tenant, account forest – utilizes a single tenant. This option would require the creation of a new Authentication Forest, but in this case it would be a global Authentication Forest. All users would then be migrated from the respective Forest to that global Authentication Forest. This Authentication Forest would not only be the point at which Directory Synchronization occurs for Online Services but it would also form the foundation for an Active Directory consolidation to rationalize the Forests within each country and region.
iv. Single tenant – dirsync forest – again, utilizes a single tenant. This option also requires the creation of a global Authentication Forest, however the users would remain in their respective regional Forests with only Directory Synchronization occurring to allow the creation of their identities within the single tenant.
2. How to provide authentication against the service
· Identity and Access. This is one of the big new features of Office365. Previously users were forced to access the MSOnline infrastructure with a Windows Live ID, which meant users having a separate account and password to remember. Whilst that solution is still possible in Office365, we now also offer the possibility of Identity Federation, which allows users to access the Office365 environment using their corporate credentials. This feature uses the organizations Active Directory and does entail the implementation of ADFS v2 into the on-premise environment, but the prize being that from a user perspective it is a single sign-on experience, with seamless integration between your on-premise and cloud based infrastructure.
· The ADFS design undertaken will be highly dependent on the tenancy model chosen, as described above. With the Office 365 platform, it is possible to use federated authentication to enable users and partners to access their Online Services tenants. Using this approach customers can make use of their existing Active Directory infrastructure as well as ADFS v2 to federate Identities with Microsoft Services. For large organizations it is recommended that they adopt a resilient implementation of ADFSv2.
3. Network considerations
· Clearly connecting to a cloud based infrastructure has significant network implications! We provide lots of example scenarios in the Service Descriptions to help customers estimate the bandwidth and latency required – an example for SharePoint could be based on the following assumptions:
i. An average interaction (page load) transfers approximately 100 KB
ii. A typical user generates about 36 interactions (page loads) per hour
iii. About 10 per cent of a company’s users will be active at the same time
· The figures above could then be used in the following way, If an organisation had 1,000 SharePoint Online users:
i. Network bits per second = (100,000 bytes/load × 8 bits/byte × 36 loads/hr) ÷ 3,600 seconds/hr = 8,000 bits per second
· Hypothetically this organisation would have approximately 100 active users at any one time. Those 100 users would require approximately 100 x 8000 bits per second or 800 kilobits per second of available network bandwidth. Assuming a daily peak of twice the average usage, your network connection would need to provide approximately 1.6 megabits per second of network bandwidth.
· We also provide speedtests to give you an indication of whether or not your links are sufficient – for EMEA, try http://speedtest.emea.microsoftOnline.com
4. How clients will connect
· Online Sign-In Services Connector.To help keep your client computers keep up to date with the latest Microsoft Online Standard Service updates, it is required that all users download and install the Microsoft Online Services Connector. By using the Online Service Connector, this component will download the needed patches, updates to configure your Operating System and Office Applications for use when consuming these Online services.
5. What are the end user device requirements for accessing Office 365?
· As noted in the previous post, one aspect of moving to the cloud is the requirement to ‘stay current’. So in order to access the infrastructure, clients have to be at a certain level, as below:
Software
Supported Version
Operating systems
Windows 7 Windows Vista Service Pack 2 Windows XP Service Pack 3 Windows XP Home Edition is supported but will not support federated identity Windows XP Media Center Edition is supported but will not support federated identity Mac OS X 10.5 (Leopard), 10.6 (Snow Leopard)
Office clients
Microsoft Office 2010 or Office 2007 Service Pack 2 Office 2008 for Mac and Microsoft Entourage 2008 Web Services Edition Office 2011 for Mac and Outlook 2011 for Mac .NET 2.0 or later Microsoft Lync 2010 Communicator for Mac
Client applications
Services Connector
Browser software—Microsoft Online Portal
Internet Explorer 7 or later Mozilla Firefox 3.x Apple Safari 3.x
6. Providing for co-existence
For any large organization it is not possible to provide a ‘big bang’ approach – in other words, it will be necessary to provide co-existence between the on-premise and cloud based services for a period of time. The following two technologies provide key support for this co-existence.
· Directory Synchronization
o Directory Synchronization enables Identity and Application co-existence, meaning an organization can manage both sets of identities as if they are on-premise, and can provide co-existence between on-premise and cloud based Exchange and Lync implementations. Some core directory synchronization capabilities were offered in the BPOS release, but Office365 increases this by allowing identity co-existence (managing identities as if they are all on-premise) and free/busy integration between Exchange online and on-premise, meaning that larger organizations who take some time to migrate their messaging infrastructure to the cloud can co-exist over the migration period.
· Exchange Rich co-existence
o Which leads on to the Exchange co-existence story. This does require some on-premise infrastructure – dirsynch needs to be in place, an Exchange 2010 CAS server needs to exist on-premise, and its highly likely you’ll be using ADFS, but this does allow you to ‘federate’ Exchange – making your on-premise and cloud Exchange infrastructure work together like a single, seamless infrastructure.
Read more @> Office 365 – Design considerations - Microsoft Premier Support UK - Site Home - TechNet Blogs
Published on: .
Sales@AgileIT.com