Office 365 federated access for home workers

If you are a home worker, sat on the Internet outside of your corporate network (VPNs excepted), it’s very likely your organisation’s ADFS 2.0 server will be sat behind a mass of firewall technology that prevents you from accessing it. So how do you get access to a federated Office 365 domain?

Enter stage left: The Federation Proxy.

ADFS includes the concept of an additional service you can publish on the public Internet so that any machines not capable of faffing about with the kerberos protocols you find on your corporate network aren’t required. You type your credentials in to a web form.

This is possible because in federation it’s the client that does all the work. The client is re-directed hither and thither, sometimes with POST data (SAML Tokens), but essentially the client is sent to a URL which it looks up, converts to an IP address and then goes to that endpoint.

This is the normal case with a client inside the corporate network. These are not the real URLs or IP addresses – just simplified examples:

1. The client looks up the office 365 URL in its DNS Server (this process might actually be complicated by say a proxy server, NAT etc – but this is essentially the flow).

2. It connects to office 365 at IP address 1.0.0.1.

3. The client is redirected to https://mfg.com. Before it can go there, it does a look-up (1) in DNS to get the MFG’s IP address – in this case 1.0.0.2.

4. The client goes to the MFG at 10.0.0.2.

5. The client is redirected to https://adfs.com. This is because when you set up identity federation, the MFG gets hold of the federation metadata document which has the URL, not the IP address. Before it can go there, it goes to the corporate DNS server and looks up adfs.com which returns 10.0.0.1.

6. The client goes to https://adfs.com which is at 10.0..0.1.

The story then unwinds itself as in a previous post and setup video and the Office 365 service gets the right SAML token.

Now let’s look at an external client and a federation proxy:

1. The client looks up office 365 in the external DNS server provided (typically) by the ISP who manages their Internet connection. They get back 1.0.0.1.

2. The client connects to Office 365 as in the previous example.

3. The client is redirected to https://mfg.com as in the previous example. This time however, the client looks up the address in the external DNS server. Note the Office 365 environment and the MFG didn’t have to do anything different. All they understand are URLs. Before the client can go to the MFG it does a look up in the External DNS and gets back address 1.0.0.2 as in the previous example.

4. The client goes to 1.0.0.2, which is https://mfg.com.

5. The MFG redirects the client to https://adfs.com. The client needs to look up the IP address and goes to the external DNS. It gets back 2.0.0.1. This is different than the previous example where the internal DNS server had the address of the internally accessible  ADFS Server. Although the federation server proxy has the same URL (https://adfs.com), it’s a different service on a different segment of network (the Internet facing DMZ) with a different IP address. The client doesn’t care.

6. The client goes to 2.0.0.1 (https://adfs.com) and tries to authenticate. They are presented with a Webform that asks for username and password. There is no kerberos exchange with the proxy because it’s facing the Internet, not the internal corporate network. It’s not possible in this scenario to do integrated kerberos authentication – so the next best thing is to type your corporate AD credentials in to a form.

7. The proxy talks to the real ADFS server and if the authentication is successful a SAML token is returned to the proxy. The dance unwinds itself in exactly the same way as the previous example only with the SAML token being supplied by the proxy, not the federation server.

 

Notice in both examples, the ADFS server and the proxy never talk directly to the MFG or Office 365. Traffic goes through the client. So as long as there is a good Internet connection between the client and each of the services (Office 365, MFG, ADFS (or proxy), it will work.

It also means if there is not a good connection, then it won’t. So say if the AD DC on corp-net goes down, or the ADFS Server goes offline, or the Internet connection to the proxy fails, then there can be no authentication and the user will not be able to get to their services in Office 365. Some people have asked me “can they just use a stored password at the Office 365 end” and the answer is no. Once a federated domain is set up, it will use federated access.

If you don’t trust the stability or management of your AD or any of its component parts (DCs, ADFS Servers, ADFS proxies, Internet connections) then think very carefully about the suitability of a federated environment. In a large, well managed, corporate environment, the risks are very low. But in a small business with no specific IT function and neglected or poorly managed infrastructure – be careful. In that case – stick with MS Online IDs and passwords.

Comments

• Anonymous
  December 06, 2011
  quick question on a comment  you made at the end of the article. "Once a federated domain is set up, it will use federated access." does this mean we cannot have some domain users using AD credentials to sign in while other users use a MS online ID, as in non domain users?