Monday, April 21, 2014

Web Application Proxy Server in 2012 R2

Setup of Web Application Proxy Server in Windows 2012 R2 When Microsoft discontinued Threat Management Gateway (which once was Proxy and then ISA server) I must admit I was disappointed; it was a relatively inexpensive authenticated reverse proxy that worked with Exchange Server as well as many other complicated products. In the interim we were told that Unified Access Gateway would be the replacement, but that product isn't as well suited to the task.

Several alternatives are out there, including: Kemp, F5, Nginx, and Squid but either the price or the relative difficulty of setup isn't in line with TMG. Fortunately starting in Windows 2012R2 Microsoft introduced Web Application Proxy which largely fills the gap.

Web Application Proxy/Server 2012r2 release party.Trust me, I paid big bucks for this insider photo.

What is Web Application Proxy?

Web Application Proxy (WAP from henceforth) is based on and replaces Active Directory Federation Services Proxy 2.0. In addition to the ADFS Proxy functionality it also introduces the ability to expose internal resources to external users. These users can be pre-authenticated (and then impersonated for SSO) against your Active Directory infrastructure using ADFS prior to being allowed access to resources. 

Wait, This is ADFS Proxy 3.0?

Yup! That and more. Here's what you can do with it:

  • Authorize external users for access to other claims-aware external or internal resources (Generally SaaS).
  • Allow access (by "reverse" proxy) to multiple internal applications on the same port.
  • Pre-Authenticate users against Active Directory via Kerberos or NTLM to facilitate SSO and access to internal applications (if desired)
  • Expose multiple internal resources on a single IP address/port (generally 443) differentiated by hostname
  • Loadbalance using a session affinity based solution in front of WAP

Let's Go!

This article will cover the following:

  • WAP requirements
  • Set up
  • Forwarding a couple of sample applications
  • Troubleshooting

Software Requirements

Web application proxy is available on Windows Server 2012 R2 and higher, and it requires ADFS 3.0 to be available on the back end. For assistance in setting up ADFS 3.0, see my article here. If you would like to proxy authentication for non-claims aware applications, I.E. Exchange OWA pre-2013 SP1 (SP1 Claims) or Kerberos/NTLM apps, you will need to have the WAP server joined to your domain.

Additionally, you'll need the certificate (private and public key) from your ADFS server and one certificate (again, private and public) for each application you intend to proxy. These certificates must be trusted by your clients, so generally external globally trusted (Digicert for example) certificate authorities are preferred. The certificates need to be installed under the "Personal" portion of the "Local Machine" store on the machine you intend to use as your WAP proxy. If you only intend to host internal resources to domain-joined computers connecting remotely you can use an internal PKI provided your clients trust your issuing CA(s). For information on how to setup an internal CA, see my article here. If you need help exporting your public and private key from your ADFS server and other services, see this article. Note that if these certificates are marked as non-exportable you will need new certificates for those services, so make sure you plan accordingly.

Connectivity and Hardware/VM Requirements

Preferably, your WAP server should be placed in a De-Militarized Zone with a firewall on either side of it. The machine can operate with either one or two Network Interface Cards, but for proper security I recommend two NICs; one internal and one external. Other connectivity options will work, including branching into your internal network on the inside interface, but I won't be covering those scenarios in detail. For all connectivity options see the following diagram:

As for the hardware you can use either real hardware or a VM assuming you have a proper DMZ NIC setup on your Hyper-V/ESX/Xen/whatever host(s). WAP is not a particularly demanding application and uses very little I/O. It is also horizontally scalable with a network level load balancer (f5) so I won't give direct guidance on specifications since it would likely have little relevance to your configuration. As in most cases, performance evaluation and configuration change is the way to go.

After deciding on your hardware and installing the OS, you'll need to configure the NICs. We'll cover that in the next section...


Now that the hardware and OS are ready to go, let's configure the NICs:

Network Configuration

  1. First open the "Network and Sharing Center" and click "Change Adapter Settings". Re-name the NICs "External" and "Internal" according to how they are connected to avoid confusion during set up and troubleshooting.

  2. Give each NIC appropriate IP address settings. The subnet for each will depend on your firewall/switch configuration. Some firewall configurations may require communication stay on a single subnet but if given a choice it is generally better to have them on different subnets. (2 NICs) Leave the default gateway on the internal NIC blank. If your WAP server is not domain joined because you intend on using only claims auth or passthrough (not delegation) then leave your DNS servers blank on the internal NIC as well and be sure to execute step 4.
  3. If the WAP server needs to access resources (ADFS, DC, App) on a subnet other than that the internal NIC is connected to, you will need to add a static route to the server so it knows how to get to that network. For example, if your WAP server is on, your ADFS server is, and your gateway is, you would issue the following command from an elevated command prompt: route ADD MASK IF -p . For more information, see this article.
  4. <Only if you haven't specified DNS servers on the internal NIC>To look up the ADFS server for claims verification you will need to add each internal ADFS server address to your %SYSTEMROOT%\system32\drivers\etc\hosts file. Do this now; if you need further instructions see this article.
  5. Now we'll secure the external NIC. Open the properties of that NIC and on the "Networking" tab unbind everything except for "QoS Packet Scheduler" and the protocol you intend on using (IPv4 or IPv6).
  6. If using IPv4, drill into the properties of that protocol and select "Disable NetBIOS over TCP/IP" under the "WINS" tab. Also ensure you disable "Register this connection's address in DNS" on the "DNS" tab.

  7. On your external firewall, open the ports for the services you wish to forward. (443 would be common)
  8. On your internal firewall, open ports necessary for AD/other communication. Here is an excellent guide.

WAP Installation

  1. In server manager, click "Manage->Add Roles and Features".
  2. Click "Next" on the "Before you begin" screen.
  3. For "Installation Type" select "Role-based or feature-based installation" & click "Next".

  4. Select your desired WAP server and click "Next".
  5. On "Add Roles and Features Wizard", select the "Remote Access" role and click "Next".

  6. You do not need to select any features; click "Next" on the "Select features" page.
  7. Read the dialog presented on the "Remote Access" screen and click "Next".
  8. Leave "Include management tools" checked and click "Add Features".

  9. On the "Select role services" page select "Web Application Proxy" and click "Next".

  10. When presented with the confirmation screen, click "Install".

WAP Configuration

Prerequisite Note: For this step you will need the public and private key for your internal ADFS server(s) installed to the "Personal" section of the "Local Computer" store on your WAP server. For more information, refer to "Software Requirements" above.

  1. After installation, server manager will notify you that configuration is required. Click the notification flag and select "Open the Web Application Proxy Wizard".

  2. On the "Welcome" screen of the "Web Application Proxy Wizard" click "Next".
  3. On the "Federation Server" screen, enter the external fully qualified domain name of your federation service. This needs to be registered in external DNS (i.e. resolvable from the internet).  For more information, see my article linked under "Software Requirements". Insert the username/password of a domain administrator account to properly register this as a proxy server. This account will not be used after this point, so a service account is not necessary. Click "Next".

  4. Select the ADFS certificate you installed earlier from the dropdown and click "Next".

  5. You'll be presented with the configuration details. If you intend on setting up another WAP server for load balancing copy the powershell command down for later use. Click "Configure" to continue.

  6. You should see the message "Web Application Proxy was configured successfully".

Setup Verification

To verify basic functionality:

  1. On the WAP server, open up Tools->Remote Access Management Console
  2. On the left-hand navigation pane, select "Operations Status"
  3. The status of the WAP server will be relayed in the middle pane. Do not be surprised to see the server listed twice, once for the FQDN and once for netbios. This is normal. 

Now that setup is complete, let's move on to publishing!

Example A: Proxying Exchange 2010 OWA (Pre-auth/Non-Claims/Delegated Authentication)

Now that we've completed the ADFS/WAP setup, let's walk through the setup of a non-claims aware application using Kerberos/NTLM delegation. A popular example would be Exchange Outlook Web Access; I'll be using version 2010 SP3.

Prerequisite Note: For this step you will need the public and private key for the services you wish to host (Exchange OWA in this case) installed to the "Personal" section of the "Local Computer" store on your WAP server. Requests destined for your back-end service are decrypted and re-encrypted at the WAP server. For more information, refer to "Software Requirements" above.

Trust Setup

First, we must set up the new trust on the ADFS server. On your back-end ADFS server (not the WAP server) do the following: 

  1. Open the AD FS management tool and click the "Trust Relationships" folder on the left hand navigation pane. 
  2. In the right hand action pane, click "Add Non-Claims-Aware Relaying Party Trust".

  3. A wizard will pop up; click "Start" on the welcome screen.

  4. Give this rule a (human) meaningful name, i.e." <Servername> Exchange OWA" along with a description if desired and click "Next".

  5. Now we'll add the non-claims aware relaying trust party identifier (which in this case is simply a URL). Enter the external fully qualified domain name of the server complete with url path ending in a trailing forward slash, i.e. and click "Next". Note: WAP identifiers must end in a trailing slash even though the MSFT example doesn't look that way.

  6. On the next screen, "Configure Multi-Factor Authentication Now?", you can set up multi-factor authentication should you desire. I will not be configuring multi-factor for this demonstration, but note you can always set it up later if desired. Leave "I do not want to configure..." selected and click "Next".

  7. Review your configuration on the "Ready to Add Trust" screen and click "Next".
  8. The "Finish" screen will have a checkbox starting with "Open the Edit Authorization Rules dialog..." that is checked by default. Leave it checked because we will want to specify who is allowed access through to the back-end via this rule right away. Click "Finish".

  9. A dialog box titled "Edit Claim Rules for <Rule Name>" will come up allowing us to define who should be allowed access via this rule. Click "Add Rule'.

  10. You will be asked to select a rule template. What you select here will depend on what is reasonable for your environment. You should create (a) rule(s) that correspond with the least access required possible as anyone getting past this point will be able to attempt to authenticate directly against the target internal resource. You may, for example, want to use a specific Active Directory group with only the users that need access to this resources. For the purposes of testing and this article, however, I will be using a simple "Permit All Users" rule. This will allow anyone in AD through and is suitable for testing or in addition to other rules. Select the rule template and click "Next".

  11. Click "Finish" to close the "Add Issuance Authorization Claim Rule Wizard"
  12. So long as you do not want any additional rules, click "OK" to close the Edit Claim Rules dialog box.

Back-end Service Configuration

Now we need to configure our back-end service to accept the authentication coming from the WAP server. In our case we will need to change the  authentication mechanism allowed by Exchange from forms based to integrated authentication.Your steps here will differ depending on what service you are offering up.

  1. Open the Exchange management console and Click on "Server Configuration"->"Client Access"
  2. For each server in your Exchange farm, click the "Outlook Web App" tab, then right click "owa (Default Web Site)" and click "properties".

  3. Select the "Authentication" tab and click "Use one or more standard authentication methods:" then select only "Integrated Windows authentication".

  4. Click "OK" on the warning.
  5. Repeat steps 2 and 3 for the "ecp (Default Web Site)" under "Exchange Control Panel" on each server
  6. Using an elevated command prompt or PowerShell, execute "iisreset -noforce" to restart IIS. (This should be done in a maintenance window)

Configure Delegation

Now we'll configure the WAP server AD computer object so that it can pass authentication to your back-end server(s). Note the SPNs referenced to not need to be manually registered at a domain level.
  1. With domain administrator privileges, open the Active Directory Administrative Center. (Active Directory Users and Computers if you prefer)
  2. Navigate to and open the properties of the WAP server computer object.

  3. Click or scroll down to the "Delegation" section of the object.

  4. Select "Trust this computer for delegation to specified servers only" and "Use any authentication protocol" (since we'll be using NTLM here; select Kerberos only for applications that support it) then click "Add..."
  5. When presented with the "Add Services" dialog, click "Add Users or Computers...".

  6. Type the name of the back-end Exchange server(s) and click "Check Names" and then "OK"
  7. Scroll to the http/SERVERNAME.domain.ext (since we're serving up the HTTP protocol; change if your app differs) and select it, then click "OK". Note: If using Active Directory Administrative Center you need to add the FQDN name and the NETBIOS name; if using Active Directory Users Computers you need only add the FQDN and both will be added.

Configure Application Publishing on WAP Server

Finally we'll configure WAP publishing for this application.
  1. On the WAP server, open the Remote Access Management Console (can be found in admin tools or tools from Server Manager)
  2. In the left hand navigation plane, select "Configuration"->"Web Application Proxy"
  3. On the right hand action pane, click "Publish"

  4. A wizard will come up. Click "Next" on the welcome screen.
  5. When prompted for preauthentication type, select "Active Directory Federation Services (AD FS)". This ensures requests are authenticated by ADFS prior to being passed onto the back-end server. Click "Next".

  6. For "Relying Party", select the trust rule we created earlier under the "Trust Setup" section above and click "Next".

  7. Now the meat of the settings; on the "Publishing Settings" step enter a meaningful name for this connection (i.e. Exchange 2010 OWA), the external URL it will be accessed by (i.e., select the external certificate for that service (see "Software Requirements" above), the internal URL (preferably should match the external but doesn't have to in all cases), and the server SPN that we specified on the step above, then click "Next".

  8. You will be shown the confirmation screen with the appropriate PowerShell command line for the options you have configured. Should you want to repeat a similar publishing step, copy and retain this command line for use later. Click "Publish".

  9. The results screen will display the publishing status. Assuming all is well, click "Close" to close the wizard.

Example B: RDP Proxy (No Pre-auth/Passthrough)

Passthrough applications are substantially easier (and less secure) because they do not require any set up in ADFS and do not subject the user connection attempt to any authentication before passing it on. This isn't to say the back-end service won't require authentication, however, but it is still less secure since you are opening your back-end service up to processing logon requests directly from the internet. 

Publish RDP Proxy on WAP Server

In this example I will publish RDP proxy direct to the internet proxied through the WAP server. This allows me to serve up this application on the same IP address and port as other services assuming the hostname requested is unique. Again, this section assumes the public and private keys associated with the URL you intend to use installed in the WAP server's "personal" store. In my example I use a hostname of ""
  1. On the WAP server, open the Remote Access Management Console (can be found in admin tools or tools from Server Manager)
  2. In the left hand navigation plane, select "Configuration"->"Web Application Proxy"
  3. On the right hand action pane, click "Publish"
  4. A wizard will come up. Click "Next" on the welcome screen.
  5. When prompted for preauthentication type, select "Pass-through" and click "Next".

  6. On the "Publishing Settings" step enter a meaningful name for this connection (i.e. RDProxy), the external URL it will be accessed by (i.e., select the external certificate for that service (see "Software Requirements" above), and the internal URL (preferably should match the external but doesn't have to in all cases). Click "Next".

  7. You will be given a summary of the publishing rule about to be created and a Powershell command of it's equivalent. If you are satisfied with the details click "Publish".


Something not working? Check out the following locations:

Event Logs

Applications and Services Logs->AD FS/Admin
Applications and Services Logs->Microsoft->Windows->WebApplicationProxy/Admin


Should you need to enable debug logging, there is an excellent article here demonstrating how to do so. One word of caution, however; should you edit the C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config referenced therein I recommend backing it up first. If not formatted correctly WAP will start up successfully with the values listed in the file, but when it comes time to rotate the ADFS Proxy Trust certificate (an automatic action that happens once every 3 weeks) the configuration of the new cert will fail. In that case you would see an Event ID 422 logged to AD FS/Admin stating "Unable to retrieve proxy configuration data from the Federation Service.".

(Excellent!) References

Want more? Here are some wonderful resources!

Technet: Web Application Proxy Overview
Technet: Install and Configure the Web Application Proxy Server
Technet: Installing and Configuring Web Application Proxy for Publishing Internal Applications
Technet Overview Guide: Connect to Applications and Services from Anywhere with Web Application Proxy
Technet Social: On WAP and IPv6
Technet Social: ADFS, WAP, and Logging
Technet Ask PFE: FAQ on ADFS Part 1, Excellent coverage of SQL vs. Internal DB and certificates for AD FS (Not WAP per se)
Marc Terblanche: Windows 2012 R2 Preview Web Application Proxy - Exchange 2013 Publishing Tests
Ask the DS Team: Understanding the ADFS 2.0 Proxy (Not about WAP but excellent coverage of AD FS proxy functionality)
Rob Sanders: Troubleshooting ADFS 2.0 (Not about 3.0/WAP but too good not to be mentioned)
Technet: Configure Event Logging on a Federation Server Proxy (Still partially relevant)
Technet: Things to check before troubleshooting ADFS 2.0 (Still partially relevant)
Technet: Configuring Computers for Troubleshooting AD FS 2.0 (Still partially relevant)

Thanks for reading, if you have questions or comments leave them below!

Monday, February 17, 2014

Generate a Certificate for Exchange 2010 using Microsoft PKI

If creating a certificate request for OWA (and other associated services) with the intention of processing this request on a Microsoft enterprise PKI structure, you'll meet a series of challenges. Here is how to overcome them in the order you will encounter them.

After creating the request and attempting to submit it, you will first see this error message:

ASN1 bad tag value met. 0x8009310b (ASN: 267).

This error is because the request is by default encoded in Unicode while 2008r2 and lower PKI can only process ANSI. To convert, either open the request with notepad and select "File->Save As" and change the encoding to ANSI before saving.

If you submit at this point, you will see:

The request contains no certificate template information. 0x80094801 (-2146875391)
Denied by Policy Module 0x80094801, the request does not contain a certificate template extension or the Certificate Template request attribute.

This is because Microsoft enterprise PKI does not process unqualified (by means of a template) requests. We need to force a template (WebServer will work) by using the following command:

certreq -submit -attrib "CertificateTemplate:WebServer" NameOfMyRequest.req

Select your CA. If your template is configured correctly, the cert request will be successful. If not, you will receive the warning:

Certificate not issued (Denied) Denied by Policy Module  0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: Web Server.

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392)

To remediate this issue you will need to create/enable your template as desired. I created a custom 2k8 compatible Web Server template that allows for exporting the private key (for Web Application Proxy) and it worked well. For more information, see Section 4 of my article.

After saving the request, use either powershell or the management console to finish processing the request, and then enjoy your e-net i-mail over the hinterlandnet.

Sunday, February 9, 2014

Windows Server Failover Clustering Quorum Behavior Guide

A Republic Quorum, if you can keep it.”  -  Ben Franklin.

Your WSFC Quorum is like a Republic, or more accurately, a Democracy. There are many articles out there regarding Quorum voting logic but most are somewhat lengthy. I decided to set out to see how few words I could effectively explain Quorum rules in, so here we go. Don't count this part. Or this. Wait... er... start counting.... NOW.

Windows 2008 and higher:

  • A Quorum is the act of n nodes agreeing on a majority. 
  • A node is a cluster member, shared disk, or fileshare witness. 
  • A cluster can have a shared disk or fileshare, but not both. 
  • A majority is defined by greater than 50% consensus. (a tie is not majority)
  • Fractions (only) are rounded up to the nearest integer. (2.5=3)
  • There is a legacy quorum method called "disk only" wherein one (defined quorum) disk is the only vote. This is considered obsolete because it creates a single point of failure. 

Windows 2008/r2 with Hotfix 2494036 or Higher:

"Nodeweight" was added to revoke a node of its voting privileges (NodeWeight=0). You can use this for nodes in a different site or to ensure that shared disk/fileshare casts the deciding vote. This is generally used in cross-site clusters.

Windows 2012 or Higher:

Dynamic Clustering
"Dynamic Clustering" changes the nodeweight of downed cluster member and effectively reduces the number of participating nodes by one. This works under the following circumstances:
  • Prior to the outage, the cluster has achieved quorum (normal under most circumstances)
  • Nodes must go down one at a time so the remaining nodes can agree to removed the downed member. If multiple nodes go down simultaneously the dynamic removal will not take place. 



Windows Server Failover Clustering is an excellent option for SQL Server, Hyper-V, and other services. Hopefully this understanding of cluster failover behavior enables you to design solutions that better meet the needs of your clients.

Note: It is important to consider how a Quorum is formed when considering patching strategy. 


TechNet: Understanding Quorum Configurations in a Failover Cluster
Aeval Shah's Blog: Windows Server 2012 Failover Clustering Dynamic Quorum
Configure Cluster Quorum NodeWeight Settings
Microsoft Support: Cluster NodeWeight hotfix for 2008/r2

Tuesday, January 28, 2014

Cloud Authentication Primer: Basic Active Directory Federation Services Setup

Cloud computing. Cool stuff eh? Just pay your (not quite) local provider and all your problems are a thing of the past.

How are we going to authenticate/authorize our users? I dunno, but sign the contract now and you get a special price for a limited time!

Fortunately you're in luck. Microsoft released Active Directory Federation Services (ADFS) all the way back with 2003 r2 and released the much appreciated version 2.0 a bit after the release of 2008 r2 (install-able as an upgrade). Version 3.0 has just shipped with 2012 r2, and each release has brought many welcome new features.

Put (probably too) simply, ADFS allows you to extend your Active Directory space to other platforms, including Azure, Amazon EC2,  and other cloud services including those supporting SAML. By doing so, you can grant your already set up internal users access to new services located elsewhere. ADFS is also required for some Microsoft products including the new Web Application Proxy, which I'll be covering later. This isn't the only way to accomplish AD auth to other parties (AD Replica; IDaaS), but it's a great place to start.

The main components of ADFS are as follows:

  • Federation Service: This service on one to many servers facilitates the core functionality; sending/receiving authentication requests to/from third parties. 
  • Federation Service Proxy: Sits in a perimeter network (DMZ) and sends requests to Federation Service servers on the interior of your network on behalf of clients outside the interior. 
Highly simplified view of ADFS In Use; I'm guessing Bob is cool with that. 

With that primer set, let's walk through a basic install/test of a single instance of Active Directory Federation Services 3.0 on Windows 2012 r2. I will not be covering the proxy or services integration at this time.


Other than domain admin rights as listed, you'll also need:
  • An Active Directory domain you would like to extend
  • 2012 r2 media and licensing taken care of. 
  • Domain Admin privileges; minor AD updates will be necessary and you'll need a new service account.
  • The ability to create new trusted certificates from either an internal or external source. (Need a new PKI setup? See my article here.)
  • At least one VM/Physical machine; One for the ADFS server and another as a shared database infrastructure if you desire. More on those options below. 
  • Desired server on the internal network and domain joined with access to Active Directory servers. 
  • Access to add records to DNS. (May not be required but I recommend it) 
  • (If applicable) Ability to create a new DB in a shared infrastructure. Note this is only a requirement if you do not intend to use the Windows Internal Database. 


ADFS, like Active Directory and most related services, is not very demanding from a hardware perspective. A modestly sized VM is generally a good solution in most cases and scaling usually is realized horizontally, dictated by geographic concerns. You can use either the built in Windows Internal Database for ADFS or place the database on a shared infrastructure if desired. I will be using a shared DB infrastructure for this example. For more information on sizing, see this link. 

Step 1: Install ADFS Binaries

  1. Log on to the machine you would like to set up as an ADFS server with your administrative logon. 
  2. If not launched already, launch Server Manager and click Manage-> Add Roles and Features
  3. Click Next on the Before you begin page. 
  4. Select Role-based or feature-based installation and click Next.

  5. Select the appropriate server and click Next.

  6. Select the Active Directory Federation Services role and click Next. (Note that despite serving up some services via HTTPS IIS is not needed)

  7. No additional features will be needed; click Next.
  8. Read the ADFS notes and then click Next to proceed.

  9. Click Install to execute. When completed, do not configure ADFS yet.

Step 2 : Acquire Certificates 

For ADFS to function correctly you'll need at least one certificate. The certificates needed are for service communications and Token-signing. For the purpose of this tutorial I will not be replacing the auto-generated Token-signing certificate because the install will work fine without doing so. For a large scale, production installation, however, I highly recommend installing a custom Token-signing certificate after installation. For more information on how to do so, see this TechNet link.

As for the service communications certificate, this must be created to proceed. This can be either an internal PKI or third party cert so long as all clients intending to use ADFS trust the certificate. Obviously if you're working with a large third party (say you'll need another third party's certificate (digicert for example). If you're working across your enterprise only, you can use your PKI but you will need to ensure all devices (mobile included for workplace join) trust your CA and your CRL needs to be accessible externally (see Publish Root CA CRL & CRT to Web) For the purposes of this example I'll be using the company PKI so expect specifics of certificate application to differ accordingly.

As for the certificate name you should pick the eventual external name of the ADFS service. Should you configure an ADFS proxy in the future, Microsoft instructions mandate the use of the same certificate. For this reason plan accordingly. Other SANs are necessary as well; we'll cover that below:

  1. Apply for a certificate; if using internal Microsoft AD PKI the web server template will work fine. 
  2. Set the common name to your desired external connection URL. For this example I'll be using
  3. Add the following DNS SANs (subject alternative names)
    1. (Yes, it's in the CN but needed here again to work properly)
    2. internalservername.internaldomain.lan (Unless you plan on splitting DNS internally) 
    3. (This is needed should you ever want to utilize Workplace Join and won't hurt you even if you don't) 

  4. Ensure the private key is marked as exportable as you'll need this cert for an ADFS Proxy in the likely event that you need it.

  5. Acquire the certificate and ensure it is installed correctly in the personal store of the local computer. 

Step 3: Configure ADFS

With your cert in hand we're ready to config ADFS. Be prepared to create a new service account for this step. 
  1. On Server Manager on the ADFS server, click the flag and then select Configure the federation server on this server.

  2. On the Welcome screen, select Create the first federation server in a federation server farm and click Next.

  3. For Connect to AD DS ensure you have the appropriate user selected. If it's the current user you won't need to change anything. Click Next

  4. On Specify Service Properties select the SSL certificate you imported earlier or import it now if you have yet to do so. 
  5. Ensure the Federation Service Name matches the external URL reference associated with the SSL certificate name. 
  6. Set the Federation Service Display Name to what you would like your users to see when using the service explicitly, i.e. "My Awesome Company". Click Next.

  7. As for the Service Account, I recommend using a Group Managed Service Account if your domain supports it (Windows 2012). If not, fall back to a Managed Service Account or standard Service Account. As I'll be using a managed service account we'll need to do the following; if not, substitute your own account creation needs for the sub steps below. 
    1. To facilitate the GMSAccount Open a Powershell prompt as administrator and execute Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

    2. Close Powershell and return to the Wizard
  8. Select the appropriate service account type and specify a name. If using a GMSAccount the Wizard can create it for you. Be sure you give it a name that suits your standards (I use GS_ where G=Group,S=Service, _=meaningful) and click Next

  9. Select if you would like to use the Windows Internal Database or a SQL install/instance on a different server. In my example I'm using a dedicated SQL server. Click Next.

  10. On the Review Options page you will be presented with the information you have just entered. Ensure it is correct and click the View Script button. This is the Powershell equivalent for this installation; save it for later reference and perhaps use for another member in the farm. Click Next.

  11. The Pre-Requisite checks will run. Provided it passes, click Configure

Step 4: Configure Networking

  1. Add a DNS record to your internal network to point the public URL you specified in the SSL certificate to the internal address of the ADFS server. 
  2. If testing workplace join internally, add the appropriate enterprise registration DNS entry as well. 
  3. If you proceed further with an ADFS Proxy you will need to add an external DNS record at that time. 

Step 5: Test and Troubleshoot

After installation you can perform a simple test by navigating to:


Where the fs.(companyname).com represents the URL specified in the DNS SAN/CN of the cert. This should present you with the following logon screen: 

All you need do is click the Sign In button and you will receive a login prompt. If entered correctly and all is working you should get the message You are signed in. when completed. 

If you have any additional problems I can offer the following: 

  • The most interesting event logs are stored in Event Viewer->Applications and Services Logs->AD FS->Admin. 
  • If the configuration fails with a cryptic error message, ensure you don't have anything taking up port 80 or port 443. If either is taken the config routine crashes. 
  • If you need to re-do the installation for any reason that is fine, but make sure you overwrite the database. The easiest way to do so is use the powershell script we mentioned above, but add the -OverwriteConfiguration True parameter. 

In Closing

Clearly this is just the beginning. The next logical step would be to setup an ADFS Proxy and then establish relationships with your SaaS providers. We'll have more on that in the future. To get started now, check these thoroughly vetted and highly appreciated links, now with 86% less sand.

Edit: Dan Salmon from the good folks at RBA Consulting sent over this excellent Microsoft link that lists many SSO ready SaaS offerings. A great place to start if you're looking...


WindowServer: ADFS Overview
TechNet: Planning for Federation Server Capacity
TechNet Security Forum: ADFS SSL Certificates
ADFS Product Support Blog: SSL, Token Signing, and Client Authentication Certs
MSDN Social: ADFS Token Cert - 3rd Party Cert Required?
TechNet: Certificate Requirements for Federation Services
TechNet: Token Signing Certificates
TechNet: Federated Web SSO Example
TechNet: Installing the ADFS Web Agent component of ADFS
Jeffrey Schwartz: ADFS 2.0 Open Doors to the Cloud
Example in Action: ServiceNow ADFS/SAML config

ADFS Proxy

Azure + AD


Thanks for reading!