AD FS Publishing and Policy Rules
I’ve been working with a customer who wanted to lock down access to O365 so users can access all the services from anywhere apart from browser based access, which can only be accessed from their corporate managed devices. Here’s a quick rundown of what we did…
We used the basic setup of 2 AD FS proxy servers in the DMZ and 2 internal federation servers to give us high availability. We had TMG sat in front of the AD FS proxy boxes, an example of the rule is shown below:-
Create a TMG Firewall Policy for AD FS
1. Log in to TMG as Domain Admin and launch Forefront TMG Management from the Start menu
2. Select Firewall Policy and select Publish Web Sites
3. Web publishing rule name: AD FS and click Next
4. Select Allow and click Next
5. Select Publish a single Web site or load balancer and click Next
6. Select Use SSL to connect to the published Web server or server farm and click Next
7. Internal site name: <your-federation-service-name
8. Check the checkbox to Use a computer name or IP address to connect to the published server
9. Computer name or IP address: <your-adfs-proxy> and click Next
10. Path: /* and click Next
11. Accept requests for: This domain name (type below):
12. Public name: <your-federation-service-name>
13. Path: /*
14. Click Next
15. Click New
16. Web listener name: AD FS Listener and click Next
17. Select Require SSL secured connections with clients and click Next
18. Check the checkbox next to External and click Next
19. Click Select Certificate, select your SSL cert certificate, click Select, and click Next
20. Select how clients will provide credentials to Forefront TMG: No Authentication and click Next and Next and Finish
21. Click Next, select No delegation, but client may authenticate directly, and click Next
22. Make sure All Users is displayed and click Next and Finish
23. Right-click the AD FS policy and select Configure HTTP
24. On the General tab, uncheck the checkbox for Verify normalization and click OK
25. Right-click the AD FS policy and select Properties
26. Select the Link Translation tab, uncheck the checkbox for Apply link translation to this rule, and click OK
27. Click Apply at the top of the TMG console
See here for full details/images - https://social.technet.microsoft.com/wiki/contents/articles/limit-access-to-office-365-via-adfs-with-threat-management-gateway.aspx and follow this link for ISA - https://blog.c7solutions.com/2011/06/publishing-adfs-through-isa-or-tmg.html and it’s also worth noting that Forefront UAG works only with the WS-Federation Passive protocol (e.g. browser access, such as the portal and OWA) not the active (e.g. Exchange ActiveSync, Outlook 2007, Outlook 2010, IMAP, POP, SMTP and Exchange Web Services) or MEX (e.g. Office subscriptions and Lync) see here for more details.
We also just used the Windows Internal Database (WID) as we don’t require more than 5 federation servers in the farm. The WID uses a primary/secondary model to replicate the database to all of the nodes in the federation farm. Because only one server is configured as the primary server, configuration changes can only be made on that server. The federation services on the secondary nodes are not able to modify the database. In this configuration, there are two features that cannot be implemented because they rely on database changes across all nodes. These two features are Token Replay Detection and SAML Artifact Resolution (for more details see here).
We followed the TechNet article ‘Limiting Access to Office 365 Services Based on the Location of the Client’ to create our own custom rule to lock down access to O365. The rule we created was ‘Allow all external access to Office 365, except Browser based access’ this is the rule we created:-
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value=~"\b1\.2\.3\.4\b"]) &&
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "True");
If we break down the rule we can see what it’s doing and it’s a little confusing as it uses double negatives! When the Value = True in the claims deny (last line in the rule) and the expression is set to NOT exist it allows that expression through!
So looking at our rule we are allowing ‘x-ms-forwarded-client-ip’ with a value IP address of 1.2.3.4 which is the public IP address from our internet facing TMG (so the NAT’d IP from internal to external).
We are not allowing ‘x-ms-proxy’ or ‘x-ms-endpoint-absolute-path’ the absolute path is what’s blocking the browser access. So when we try to access OWA for example from a none managed device (e.g. not tunneled through the corporate network using the internet proxy servers and appearing to come from 1.2.3.4) but instead coming from another IP, such as home broadband, we get access denied as below.
Access Denied
There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
You are not authorized to access this site. Contact your administrator for more information.
Reference number: 11111111-1111-1111-1111-111111111111
You can then lock down POP and IMAP using the following link if required
Oh and dont forget we now have the Client Access Policy Builder to automate the creation of these rules for the most common scenarios as listed in the TechNet article above.
Written by Daniel Kenyon-Smith