Partager via

Understanding the AD FS 2.0 Proxy

  • Article

Hi guys, Joji Oshima here again. I have had several cases involving the AD FS 2.0 Proxy and there is some confusion on what it is, why you should use it, and how it works. If you are looking for basic information on AD FS, I would check out the AD FS 2.0 Content Map. The goal of this post is to go over the purpose of the AD FS 2.0 Proxy, why you would want to use it, and how it fits with the other components.

What is the AD FS 2.0 Proxy?

The AD FS 2.0 Proxy is a service that brokers a connection between external users and your internal AD FS 2.0 server. It acts as a reverse proxy and typically resides in your organization’s perimeter network (aka DMZ). As far as the user is concerned, they do not know they are talking to an AD FS proxy server, as the federation services are accessed by the same URLs. The proxy server handles three primary functions.

  • Assertion provider: The proxy accepts token requests from users and passes the information over SSL (default port 443) to the internal AD FS server. It receives the token from the internal AD FS server and passes it back to the user.
  • Assertion consumer: The proxy accepts tokens from users and passes them over SSL (default port 443) to the internal AD FS server for processing.
  • Metadata provider: The proxy will also respond to requests for Federation Metadata.

Why use an AD FS 2.0 Proxy?

The AD FS 2.0 Proxy is not a requirement for using AD FS; it is an additional feature. The reason you would install an AD FS 2.0 Proxy is you do not want to expose the actual AD FS 2.0 server to the Internet. AD FS 2.0 servers are domain joined resources, while the AD FS 2.0 Proxy does not have that requirement. If all your users and applications are internal to your network, you do not need to use an AD FS 2.0 Proxy. If there is a requirement to expose your federation service to the Internet, it is a best practice to use an AD FS 2.0 Proxy.

How does the AD FS 2.0 Proxy Work?

The claims-based authentication model expects the user to have direct access to the application server and the federation server(s). If you have an application (or web service) that is Internet facing, and the AD FS server is on the internal network, this can cause an issue. A user on the Internet can contact the application (or web service), but when the application redirects the user to the AD FS server, it will not be able to connect to the internal AD FS server. Similarly, with IDP-Initiated Sign on, a user from the Internet would not be able to access the sign on page. One way to get around this would be to expose the AD FS server to the Internet; a better solution is to utilize the AD FS 2.0 Proxy service.

In order to understand how the proxy works, it is important to understand the basic traffic flow for a token request. I will be using a simple example where there is a single application (relying party) and a single federation server (claims provider). Below you will see an explanation of the traffic flow for an internal user and for an external user in a WS-Federation Passive flow example.

image

For an internal user (see diagram above) :

1. An internal user accesses claims aware application

2. The application redirects the user to the AD FS server

3. The AD FS server authenticates the user and performs an HTTP post to the application where the user gains access

Note: The redirects are performed using a standard HTTP 302 Redirect .

The posts are performed using a standard HTTP POST .

image

For an external user (see diagram above) :

1. An external user accesses claims aware application

2. The application redirects the user to the AD FS 2.0 proxy server

3. The proxy server connects to the internal AD FS server and the AD FS server authenticates the user

4. The AD FS 2.0 proxy performs an HTTP Post to the application where the user gains access

Note: Depending on the infrastructure configuration, complexity, protocol, and binding the traffic flow can vary.

Basic Configuration of the AD FS 2.0 Proxy:

Configure DNS:

Configuring DNS is a very important step in this process. Applications, services, and other federation service providers do not know if there is a proxy server, so all redirects to the federation server will have the same DNS name (ex: https://sts.contoso.com/adfs/ls/ ) which is also the federation service name. See this article for guidance on selecting a Federation Service Name. It is up to the administrator to configure the internal DNS to point to the IP address of the internal AD FS server or internal AD FS server farm load balancer, and configure the public DNS to point to the IP address of the AD FS 2.0 Proxy Server or AD FS Proxy server farm load balancer. This way, internal users will directly contact the AD FS server, and external users will hit the AD FS 2.0 proxy, which brokers the connection to the AD FS server. If you do not have a split-brain DNS environment, it is acceptable and supported to use the HOSTS file on the proxy server to point to the internal IP address of the AD FS server.

SSL Certificates:

The internal AD FS server can have a certificate issued by your enterprise CA (or public authority), and should have a subject name that is the same as the Federation Service Name/DNS name that it is accessed with. Using Subject Alternative Names (SAN) and wildcards are supported as well. The AD FS 2.0 proxy needs to have an SSL certificate with the same subject name. Typically, you want this certificate to be from a public authority that is trusted and a part of the Microsoft Root Certificate Program. This is important because external users may not inherently trust your internal enterprise CA. This article can step you through replacing the certificates on the AD FS 2.0 server.

Firewalls:

  • Internal and external users will need to access the application over SSL (typically port 443)
  • The AD FS 2.0 Proxy Server will need to access the internal AD FS server over SSL (default port 443)
  • Internal users will need to access the internal Federation Service on its SSL port (TCP/443 by default)
  • External users will need to access the Federation Service Proxy on its SSL port (TCP/443 by default)

How does the AD FS 2.0 Proxy work?

Proxy Trust Wizard prompts admin credentials for the internal federation service (AD FS). These credentials are not stored. They are used once to issue a proxy trust token (which is simply a SAML assertion) which is used to “authenticate” the proxy to the internal federation service. The internal AD FS server knows about the proxy trust token and knows that when it receives a proxy request that request must be accompanied by the proxy trust token.

The proxy trust token has a configurable lifetime, and is self-maintained by the proxy and the federation service. The only time you need to touch it is if a server is lost or you need to revoke the proxy trust.

When a proxy trust is revoked, the proxy trust token is invalidated and the federation service will no longer accept proxy requests from proxies who are attempting to utilize that token. You must re-run the Proxy Trust Wizard on ALL proxies in order to re-establish trust.

Using PowerShell:

Using PowerShell is an easy way to view and set configuration items regarding the proxy server. I’ve listed the more common commands and parameters used to configure the AD FS 2.0 proxy.

On the proxy server:

On the federation server:

Conclusion:

I hope you now have a better idea of how the AD FS 2.0 Proxy works and the basics on how it should be configured. If you want to dig deeper, there are some excellent resources for the AD FS 2.0 Proxy.

Planning Federation Server Proxy Placement
https://technet.microsoft.com/en-us/library/dd807130%28WS.10%29.aspx

Certificate Requirements for Federation Server Proxies
https://technet.microsoft.com/en-us/library/dd807054%28WS.10%29.aspx

AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates
https://social.technet.microsoft.com/wiki/contents/articles/2554.aspx

Troubleshooting federation server proxy problems with AD FS 2.0
https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-proxy-problems%28WS.10%29.aspx

AD FS 2.0: Guidance for Selecting and Utilizing a Federation Service Name
https://social.technet.microsoft.com/wiki/contents/articles/4177.aspx

AD FS 2.0 Proxy Management
https://blogs.msdn.com/b/card/archive/2010/06/02/ad-fs-2-0-proxy-management.aspx

[MS-SAMLPR]: Security Assertion Markup Language (SAML) Proxy Request Signing Protocol Specification
https://msdn.microsoft.com/en-us/library/ff470131(v=PROT.13).aspx

[MS-MFPP]: Federation Service Proxy Protocol Specification
https://msdn.microsoft.com/en-us/library/dd357118(v=PROT.13).aspx

AD FS 2.0 Cmdlets in Windows PowerShell
https://technet.microsoft.com/en-us/library/ee892329.aspx

Joji “happy as a claim” Oshima

Comments

  • Anonymous
    January 05, 2012
    Nice post.  I feel like AD FS is going to become more and more important in the future, and we're going to be moving away from forest trusts. Gateway servers is a good thing.

  • Anonymous
    December 31, 2013
    Pingback from Difference between VIDIZMO ID Connector & ADFS SSO - VIDIZMO - Video Streaming & Digital Media Solutions