First published on CloudBlogs on Jun, 10 2014
Yesterday, we kicked-off our blog series on Access Information Protection (AIP) by talking about
setting up the environment
. In today’s post, we continue our look at AIP and specifically ways you can make resources available to users, who are connecting from various devices, inside and outside of the LAN, while keeping the company’s information safe and making sure that you maintain all mandated compliance.
One way to approach this task is to use Web Application Proxy combined with Active Directory Federation Services (AD FS) to publish resources.
Using the Web Application Proxy, you can publish access to internal web applications, allowing access from user devices either by native applications or through a web browser. Web Application Proxy in conjunction with AD FS can also preauthenticate the user and the user’s device and enforce access policies based on the user, the device, or the location.
Web Application Proxy is integrated with AD FS and uses information stored in Active Directory Domain Services. It uses user identity information, such as verifying credentials and device registration information. You can also require Multi-Factor Authentication on a per-Application basis. This integration with AD FS lets you apply conditional access rules for granular control
over how and where users can access the application. You can implement this granular control with applications that use AD FS claims, Kerberos web apps, Microsoft Office Forms-Based Access, and Representational State Transfer (REST)-ful OAuth apps.
Alternatively, Web Application Proxy can provide a generic reverse HTTP over Secure Sockets Layer (HTTPS) proxy to publish applications without AD FS that will then use NTLM or Basic authentication to validate the user.
For more general information about Web Application Proxy, check out
Overview: Connect to Applications and Services from Anywhere with Web Application Proxy
.
To use Web Application Proxy, you need to install the role service on a computer running the Windows Server 2012 R2 operating system as part of the Remote Access role. In a large environment, you may want to install multiple servers to handle the traffic. Make sure that you have the correct Public Key Infrastructure certificates, either issued by your own certification authority (CA) or purchased from your favorite publicly trusted CA. In addition, make sure that all of the servers involved have the correct time (which is usually automatic in a domain).
When using AD FS for granular control or preauthentication, several HTTPS redirects occur. Here’s the basic sequence with Web Application Proxy using AD FS for preauthentication:
-
A user request a resource URL that is a public address on which Web Application Proxy is listening.
-
Web Application Proxy redirects the request to AD FS, including encoded parameters (such as the requested resource and a relying party identifier).
-
AD FS validates the user according to the rules you’ve defined; if authenticated, it redirects the request to Web Application Proxy with a new security token included in the request (the
edge token
).
-
Web Application Proxy validates the token and now has access to the user’s identity information, which it can used, for example, to obtain a Kerberos ticket for a back-end system.
-
If the token is valid and not expired, Web Application Proxy forwards (or “proxies,” if you prefer), the HTTPS request to the published web application.
-
The client can now access the application. (Note, however, that some applications may require additional information for authentication.)
-
Web Application Proxy uses a cookie to identify the session and mark that preauthentication is no longer required.
Similar processes are used for Windows Store apps, Office Web apps, claims-aware (claims-based) applications, and Integrated Windows Authentication–based applications. Details on the steps and the differences between app types can be found in
Plan to Publish Applications using AD FS Preauthentication
.
Microsoft has prepared several walkthroughs and planning guides for using Web Application Proxy:
We mentioned that you could use AD FS with Web Application Proxy to preauthenticate or evaluate devices, not just users. Here’s today’s cliff-hanger: Come back tomorrow and read about how you can allow users to register their own devices to access resources (while giving you some control over which devices to recognize).
NEXT BLOG POST IN THIS SERIES: Registering BYOD devices (Coming June 11)
Learn more about Access and Information Protection
here
.
