As Microsoft makes product transitions, it’s easy to get left behind if you don’t keep up with the latest trends. I recently found myself staring at an organization edge ISA 2006 server using RADIUS pre-authentication to serve OWA and ActiveSync to outside users. While it was working just fine, the OS and application were extremely behind the times (and probably riddled with inherent vulnerabilities). RADIUS pre-authentication used to be something that everyone thought necessary for these published services to remain secure. The pre-authentication with RADIUS would take place first, and if successful, the user traffic was forwarded to the inside of the organization where basic authentication was used within the application. Fortunately, Microsoft products have slowly evolved and matured while still achieving this same authentication end-goal. ISA evolved into TMG and UAG, which many organizations still run today. But if your present design goal involves Exchange edge services, OWA, or ActiveSync, what should you use today? Microsoft has discontinued development on the TMG and UAG products and has instead evolved into a model that utilizes built-in roles within Server 2012 R2, namely Web Application Proxy, and Active Directory Federation Services.
I wanted to write this blog because I found it pretty difficult to piece together all the information I needed to get this implemented. It’s out there, but in minuscule pieces. I made some mistakes and learned from them. I’m hoping that I can help others avoid those same mistakes. Ultimately, the end result is great, so I hope this reaches someone who plans to migrate their organization off of these legacy products and into Microsoft’s latest designs. For the sake of simplicity, I’m going to assume you will relate your own situation with mine. I will state what I had to do to migrate from ISA and that should be enough information to know how to migrate from anything else. For the example external domain, I will be using “yourcompany.com” and for any internal domains, “yourcompany.local” . Make sure to replace any of these with your own domain names.
The basic design is as such:
PART ONE: Install and Prepare ADFS 3.0
When starting out on this project, my organization did not have ADFS running at all. I won’t go into everything that ADFS can do for you, but it can do quite a bit. In this case, we are using it for claims-based and pre-authentication. Think of it as the RADIUS server in my legacy situation listed above (more on ADFS 3.0). I was surprised at how simple it really is to implement. This guide is assuming that you have a Windows Server 2012 R2 box that you can install the ADFS role on. In my case, I installed the role on a Domain Controller on the inside of the organization, but it can be on any domain member server.
- Microsoft Server 2012 R2 server joined to the domain.
- A domain administrator account.
- A new certificate issued by a 3rd party CA assigned to the ADFS server computer account. Create the CSR for a common name of either “sts.yourcompany.com” or “fs.yourcompany.com” and have Server/Client Authentication roles. Also, there are a couple very important caveats here, where I made mistakes. Make sure to NOT use the newer CNG certificate generation. Use the Legacy provider or the certificate will not work with ADFS. Also, you must add a SAN (subject alternative name) of “enterpriseregistration.yourcompany.com” in the certificate request if you want Windows 8.1 and other Microsoft devices like RT tablets to be able to auto-discover your organization’s Device Registration Service (DRS) for Workplace Join. I will explain more on this later, but just know that if you don’t add this alternative name to the certificate, you can not go back and change this without completely uninstalling ADFS and re-issuing a new certificate and then reinstalling ADFS. In short, make sure that if this is something you plan to use, that you add the SAN to the request. It won’t hurt to add the SAN even if you decide later that you don’t want to use Workplace Join.
Install the certificate on the server. Make sure that it is installed on the computer personal store, and that you possess the private key.
Open the Server Manager and the Add Roles and Features Wizard. Check the box to install the Active Directory Federation Services role. Click Next through the prompts and once finished at the Results screen, make sure to click on “Configure the federation service on this server”.
Within the Active Directory Federation Services Configuration Wizard, on the Welcome screen you will see some prerequisites. At the bottom of the screen, you will want to choose the radio button option to “Create the first federation server in a federation server farm” and click Next.
You will then be asked to provide a domain administrator account. This can be a dedicated account or if you are currently logged in as a domain administrator, you don’t need to change anything here. Click Next.
On the next screen, you will be asked to provide a few things. First, you will need to use the drop down list to select the certificate you just installed on the server. It should be listed here already, but you also have the option to import your own certificate. Next, enter the name of your Federation Service. To be consistent, I made it the same name as the common name of my certificate, “fs.yourcompany.com”. Lastly, create a display name that people will see when they reach the Federation Services login page (i.e. My Company). This can be whatever you want and has no technical impact on ADFS.
On the next screen, you will be asked which service account to use. This can be a managed service account or just a regular domain account. It does not need Domain Administrator privileges. Click Next.
You will then be asked to specify the database. I chose to use the self-created Windows Internal Database for simplicity. I am not sure what size organization would be limited based on this, but I imagine it would have to be pretty large.
The final step will issue a command to create the database and configure the service. Once this completes, you will be able to access the ADFS Management snap-in to further configure ADFS.
Depending on your DNS setup, you probably will need to add a new Forward Lookup Zone for “fs.yourcompany.com” to your internal DNS which points to the ADFS server. The only alternative to this is if you later modify the /etc/hosts file on the WAP server to resolve to the internal address, but this could leave problems resolving from your internal clients. In short, the WAP server ( in your DMZ) will need to be able to resolve “fs.yourcompany.com” to the internal IP of your ADFS server, and your internal clients will need to do the same, However you choose to achieve this is up to you. This DNS resolution on the outside uses a different A record than the inside clients will be using to connect to ADFS.
Our last step in configuring a basic ADFS implementation is to create a Relaying Party Trust. This is what the WAP server will later use in order to authenticate using ADFS. For this first configuration, we will not be using any sort of claims for authentication, so we will create a “non claims aware” trust. First open the ADFS Management Console and highlight Trust Relationships on the left menu. Then on the right, choose “Add Non-Claims-Aware Relying Party Trust” to bring up the wizard.
On the next screen you must indicate a display name for this trust. Since this does not use claims, make sure to name it something that indicates that. I called mine “Non-Claims Aware Application”. You later use the WAP server to choose this and will be able to recognize the trust by the name.
On the next screen, you will need to come up with a unique trust identifier. The easiest thing to do is just use the standard convention that Microsoft suggests in the example and replace with your specific common name.
Continue through the wizard and make sure to indicate that you do NOT wish to configure multi-factor authentication at this time. This can be done any time later if you wish.
Once the trust has been successfully added, make sure to keep the check box that opens the Authorization Rules checked.
On the “Edit Claim Rules” screen, choose “Add Rule”. This will bring up an authorization claim to use for this trust. As of right now, we just want everyone to be able to try and authenticate using this trust, so in the drop down menu, choose Permit All Users, and then Next, to finish. By choosing Permit All Users, you aren’t authorizing all users. You are merely allowing everyone to attempt to authenticate using this trust. We will talk about claims and authorization restrictions in the next part.
You must now create a couple external CNAME records that will allow external users to properly use and point to the Federation Services. This was a source of confusion for me when I first attempted this. Typically, your future WAP server will handle requests for multiple applications, and serve multiple certificates. Create this CNAME to point to the external A-record you use for Exchange OWA and ActiveSync. For instance, if your public A record is “mail.yourcompany.com” :
fs.yourcompany.com Address Record(A) 188.8.131.52 mail.yourcompany.com Canonical Name(CNAME) fs.yourcompany.com enterpriseregistration.yourcompany.com Canonical Name(CNAME) mail.yourcompany.com
Configuring your external DNS this way will ensure that both certificates will be valid on the WAP later when we implement that. As of now, ADFS is configured and you are ready to implement both the WAP server and configure OWA and ActiveSync to work with ADFS, and even configure device registration and claims. I will go over all that in Part’s two and three, which will be coming soon. Let me know if you have any feedback.