Many global organizations are seeking ways to deliver authentication to their global sites, in the most optimal way.With Office 365, you have the ability to provide your end-users a single sign-on experience with Active Directory Federation Services (ADFS), integrating with Office 365.In order to leverage ADFS, you have to plan out your authentication strategy.The major item you need to know about ADFS is how it routes the user to the ADFS servers.Today, DNS is primarily used to refer the connecting client to the appropriate ADFS server.All users have to logon to the service with a User Principal Name (UPN), which looks similar to username@companydomain.com.That user’s logon domain is companydomain.com.Since DNS is used, you are somewhat limited on how you leverage ADFS.Here is an example of the first few steps of authentication.
The first step is for the user to request access to the service.Office 365 then determines if the user is an ADFS or non-ADFS user.If the user is an ADFS user, the user is then referred to an address setup within the service.As an example, it may be sts.companydomain.com (based on the users UPN.)The end user then does a DNS lookup for the location of that server (the STS A record part.)If the end user is outside the network (e.g., private IP within the same routable internal network) where ADFS is located, then the user will likely get a public IP address for the ADFS proxy servers (see path 3a, in the image above.)If the end user is within the internal (private routable network, on the same network as the ADFS internal server), the user will receive the internal IP address for the ADFS internal servers.
The primary limitation with this setup, for all users leveraging the UPN of @companydomain.com, is that you can only have one DNS record to refer the user to a proxy or internal ADFS server.This creates challenge for those companies looking to globally distribute ADFS for redundancy or performance reasons.
For those companies looking for redundancy or local authentication performance, there are some options.Companies that want to maintain the same UPN for all users, but need to provide global redundancy, can deploy a DNS solution that enables the capability to load balance information between sites.This is based on the location of the user, availability of the services, and general performance of the servers.F5 is one example of a great option to enable this capability.With a solution from F5, you can deploy ADFS server to each of your sites dedicated to ADFS, then rely on the F5 DNS service to direct your users to the appropriate servers. (Note: Please review the ADFS Office 365 guides from Microsoft, when scaling ADFS servers.)
If you are required or have the ability to manage multiple UPNs, you have the option to deliver users to a specific site, based on their UPN.Here is an example of how this would work.
In conclusion, if your business requires redundancy or a need to address performance issues with logons, you should consider the options above.Start by evaluating the authentication service from a single location.If your business requires redundancy, move to the options above. If you are already planning multiple UPNs, then the architectural decisions become more simplified. Disaster recovery solutions may look similar, but they can be less / more complex based on your recovery time objectives (RTO.)Either way, the service depends on DNS to function.So when building your solution, keep in mind how DNS plays a role into the entire logon experience.
