Join Keyfactor at RSA Conference™ 2024    |    May 6 – 9th    | Learn More

  • Home
  • Blog
  • ADFS with Non-Standard HTTPS Port

ADFS with Non-Standard HTTPS Port

Recently, CSS was requested by a client to implement an AD FS 2.0 (ADFS) federation solution to meet a very unique security requirement associated with scenarios of external access to internally hosted services.

  • Security Requirement- The client’s firewall policy does NOT allow network traffic on TCP port 443 from the DMZ to the internal network. All HTTPS traffic must use alternative ports from the DMZ to the internal network. This means that the ADFS proxy server in the DMZ could not use the standard HTTPS TCP port 443 for communication with the ADFS federation server in the internal network.
  • Proposed Solutions- Generally, there are two solutions to meet this security requirement while also meeting ADFS requirements.

For additional information about related ADFS requirements, please refer to: Using a Third-Party Proxy as a Replacement to an AD FS 2.0 Federation Server Proxy

The first solution is to have network devices handle port mapping exclusively without changing ports on ADFS proxy server and ADFS server. In other words, all ADFS participating components are still using standard HTTPS 443 port as usual.

The following diagram shows the logical view of the first solution:

We have successfully deployed this solution in the client production environment. However, this solution depends on how specific network devices handle port mapping, we won’t go into that here, but instead show an alternative solution.

The second solution is to leverage an out of the box (OOTB) ADFS proxy server configuration option which is to use an “HTTP proxy server” when sending requests to ADFS server.

The following diagram shows the logical view of the second solution:

The following diagram shows the configuration option of ADFS proxy server:

In this solution we configure the ADFS proxy server to “Use an HTTP proxy server when sending requests to this Federation Service.” An alternative port (e.g. 8080) can then be specified to reach an HTTP Proxy server in the internal network.

For additional information, please refer to: Configure a Computer for the Federation Server Proxy Role:

Suggested Configuration Procedures to validate this second solution in your environment include:

  • Install a network “sniffer”, for example WireShark (, that can see the traffic from the ADFS proxy towards the internal network. Use this to gather the request and response messages during the configuration process.
  • Before configuring ADFS proxy server with the HTTP proxy server option, directly configure internet explorer (IE) on the ADFS proxy to use the HTTP proxy server:

On ADFS proxy server, configure IE to use a proxy:

IE > tools > internet options > [connections] > LAN Settings > Proxy server > [advanced]

Use IE to request federation metadata from ADFS server ( ) to validate proper operation and that no SSL certificate warnings are produced.

To see more details of the traffic out of the ADFS proxy you can use a local proxy that is capable of decrypting HTTPS, such as Fiddler ( Using this tool you can observe the HTTP flow from both IE and the ADFS proxy itself.

Be sure to enable the tool to connect to the HTTP proxy, in Fiddler this is accomplished using the “chain to upstream gateway” option.

Fiddler > tools > fiddler options > Connections > [x] chain to upstream gateway

You will normally also need to disable Channel Binding on ADFS Server for authentication to succeed.

The HTTP proxy component behaves like a “man in the middle” in AD FS 2.0 deployments. IIS on the AD FS 2.0 server automatically protects against man in the middle attacks using a Channel Binding Token (CBT).

For additional information on CBT and Extended Protection for Authentication, please refer to: Forefront UAG and AD FS 2.0 supported scenarios and prerequisites

Configuring Advanced Options for AD FS 2.0

  • Additional Tech Notes

When decoding the SSL session with Fiddler one should be able to trace the federation flow by observing the clear text message via Fiddler.

Example 1:

The ADFS proxy server collects the user credentials by presenting the login page. Once the user submits the credentials, the ADFS proxy server requests a security token on behalf of a user by making a web service HTTP POST call to the ADFS server. Along with the request, the ADFS proxy server inserts the collected credentials in the Username Token element in the SOAP message below:


<s:Envelope xmlns:s=”” xmlns:a=”” xmlns:u=””>

<s:Header> ….


<t:RequestSecurityToken xmlns:t=””>

<ReplyTo xmlns=”” />

<wsp:AppliesTo xmlns:wsp=””>

<wsa:EndpointReference xmlns:wsa=””>






<UsernameToken u:Id=”uuid-6cdb82dc-1b05-45e6-8b6b-d17c5bbf123c-26″ xmlns=””>


<Password Type=””>mypassword</Password>





<ActivityId xmlns=””>355bd888-cb90-4367-8428-1cc473c6b717</ActivityId>

<MSISSession xmlns=””>

<WsFederationData />





Example 2:

With a SAML 2.0 access scenario, the ADFS proxy server receives SAML authentication request then makes a web service HTTP POST call to the ADFS server. Along with the request, the ADFS proxy server will insert the SAML authentication request in the SOAP message as below:


<s:Envelope xmlns:s=”” xmlns:a=”” xmlns:u=””>

<s:Header> ….


<msis:IssueRequest xmlns:msis=””>













<SecurityContextToken u:Id=”_4ba3e1a4-cd96-470a-aa64-2d7c8431c3e3-BE4548F70EA0675E553AD9904F63C39F” xmlns=”″>



<Cookie xmlns=””>sc7Wn1l1ylzr18EQM2WgK2uvztHbSB….3nIuRCbXowdPRaDU9stlXKNfA99vD</Cookie>



<msis:SessionState />