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:
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.
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud