Howto – ADFS & ADFS Proxy on Windows Server 2012 R2 with Office 365


http://goodworkaround.com/node/53

Windows Server 2012 R2 is RTM and published on MSDN. Active Directory Federation Services (ADFS) 3.0 have some major differences from the 2012 version (ADFS 2.1). The ADFS Proxy is gone, replaced by the Web Application Proxy (WAP), a part of the Remote Access role. The WAP is an replacement for the ADFS proxy and can also be used to publish other applications such as SharePoint and Outlook Web Access. Also Bring Your Own Device (BYOD) is possible with the new Device Registration Service / Workplace Join and there are better support for two-factor authentication. IIS is no longer used, which removes a lot of the customization possibilities. This article is about how to configure the new ADFS for Office 365.

Let’s get right to it. My setup is a non-redundant system with a single ADFS server and a single Web Application Proxy (WAP). My federation server farm will in this case be called sts.goodworkaround.com. From this guide it should be easy to extrapolate how to set up the service in a load balanced and highly available cluster.

In earlier versions of ADFS, it was recommended to install it on dedicated servers. This was partly because ADFS ran inside IIS and required quite a lot of resources. Since ADFS no longer reqiures IIS, there is much less overhead, and you can now install ADFS on your domain controllers. Keep in mind that you cannot use Windows Network Load Balancing (NLB) with DCs, and must use an external load balancer if you require high availability in this configuration.

Start by installing the Active Directory Federation Services role with Server Manager.


After completing, click “Configure the federation service on this server”. In the new window that opens, choose default option which is “Create the first federation server in a federation server farm”. Even though you do not plan to create a farm, even a single server is still a farm and you can at any time extend your one-server farm to a bigger farm by adding additional nodes.

Choose the account used for the action. I recommend using a Domain Administrator, but you can get away with using an account by granting write permissions to a container in AD.

After choosing the account, it’s time to import the certificate and setting the federation server farm name. The certificate can be a wildcard (like mine), or with a subject. The federation server farm name must match the subject of the certificate. The certificate must be 2048-bit or more.

Click import and type the password for the pfx file. If you do not have the certificate available as a pfx container, you must convert it to this format. An easy way is to use IIS on a different host and import and export it from there.

After importing the certificate, depending on the certificate type, choose a federation server name and a display name. The display name can be changed at a later stage, but the federation server name can not.

On the specify service account page, there are two options. The first option is to create a group managed service account (GMSA). This option requires at least one Windows Server 2012 domain controller in the domain where the GMSA is created. The GMSA option is the easiest and automates both password management and servicePrincipalName. The second option is to use an already existing GMSA or a regular user account. The wizard will automatically configure SPN for the user, if it has permissions. The user will automatically be granted the necessary permissions.

Next, choose the type of configuration database. Here too there are two options. The default option is using Windows Integrated Database (WID). WID is mostly the same as SQL Server Express, and to my experience, this is sufficient for most customers and actually recommended when the federation server farm contains less than 8 servers. If installing more than 8 servers in the federation server farm, choose SQL instead. Note that there are some security features that requires SQL server.

Next yourself through the following screens.



Voila! You have deployed your first ADFS server. Now let’s continue configuring DNS and testing the server.

Start by creating a A-record (Do not use a cname record, as this will give you errors with windows authentication / single sign-on!) that points to the server’s IP address. If you are doing a highly available setup, point the A record to your load balancing IP address.

Now, use the url https://sts.goodworkaround.com/adfs/ls/IdpInitiatedSignon.aspx to test your federation server. Start by testing from a domain user on a domain joined client. You should see something like the following.

If you have added the site as a Intranet Site in security settings, you should get Single Sign-On (SSO) and get directly to the following.

If your browser do not trust the site or do not support Windows authentication, you will be requested for credentials.

Now that the ADFS server is tested, let’s continue on and installing the Web Application Proxy (WAP). The WAP will be used to present ADFS to the internet. You can use any kind of reverse proxy to do this, such as TMG or F5. The WAP server requires to resolve your federation server name to your federation server. It is best practice to have the server running the WAP standalone and not part of the same domain as the ADFS servers. This because the WAP server is directly presented to the internet.

WAP is new in 2012 R2 and is a part of the Remote Access role. Use Server Manager to install the Remote Access role.

Next, next, next to the Role Features page and choose Web Application Proxy.

Start the Web Application Proxy wizard.

In the wizard, read the text and click next.

Type in the federation server name and administrator credentials. These credentials will only be used once in order to create a proxy trust, and they are not stored.

Import and choose the same certificate as on your ADFS server. This can also be different, but that’s just one more certificate to keep valid.

Hit “configure” and you are done.

After finishing the wizard, the Remote Access Management console will automatically start. Create a new pass-through publishing by clicking publish in the right menu.

Fill in your information. The external and internal url must be the same.

Now you have published ADFS. What you now must do is to make the WAP accessible from the internet and point the federation server name in public/internet DNS to the WAP. In my case this means pointing sts.goodworkaround.com to the WAP server.

Now you should verify that https://sts.goodworkaround.com/adfs/ls/IdpInitiatedSignon.aspx is available and working from the internet.

Federating Office 365

Your ADFS setup is now ready to be used with Office 365. You can follow the same guides for configuring your ADFS with 2012 R2 as with 2008 R2 and 2012. Anyway, here is how.

Start by installing the Microsoft Online Services Sign-In Assistant and the Microsoft Online Services Sign-In Assistant. You can find instructions for this here at TechNet. It can be a good idea to install this on the ADFS server, but you can also do this from other computers as long as they can contact the ADFS server.

After installing these two components, on the ADFS server start a PowerShell as administrator and type the cmdlet Import-Module MsOnline. After successfully importing the module, continue with Connect-MsolService. You will be asked for credentials. Type a global administrator i Office 365.

If running the PowerShell on another computer, use the Set-MsolADFSContext cmdlet to point to the ADFS server.

In order to federate domains, they must be verified in the Office 365 portal. You can check this with the Get-MsolDomain cmdlet. This should show the domain as verified.

If the domain is verified, use the Convert-MsolDomainToFederated with the DomainName parameter to federate a domain. You should also use the SupportMultipleDomains parameter, or you will not be able to use the same ADFS servers to federate other domains in the same tenant. Here is the whole PowerShell.

Data hosted with ♥ by Pastebin.comDownload RawSee Original
  1. ImportModule MsOnline
  2. ConnectMsolService
  3. GetMsolDomain
  4. ConvertMsolDomainToFederated DomainName goodworkaround.com SupportMultipleDomains:$true

Testing Office 365 sign-on

After you have successfully federated the domain, you are ready to test signing into Office 365 via federation. In order for this to work you should already have set up Windows Azure Directory Synchronization Tool, and your UPN suffixes should match federated domains.

No matter whether a user have an Exchange Online license assigned or not, we can test federation by going to http://outlook.com/goodworkaround.com. This should now automatically redirect to your ADFS server. If you use this URL externally, you will get to ADFS through WAP. If you use this URL internally, you should get to ADFS directly, and possibly have single sign-on. Log on with a upn such as marius@goodworkaround.com and you should be redirected to Outlook Web Access (if you have no license, you should get an error from OWA that you do not have a mailbox).

It is also a good idea to test the proxy by testing other sign-on options than web redirect. My suggestion is that you grant a user Global Administrator in the Office 365 portal and try to sign into the Microsoft Online PowerShell with the UPN marius@goodworkaround.com and the password.

Hope this helps someone! If you have any questions, use the comment section below. I have done this so many times that there might be some steps I forget to mention.

http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365_1320_part-2.aspx

How To Install ADFS 2012 R2 For Office 365–Part 2

  • Comments3
  • Likes

In part one we installed the ADFS server on our corporate network, and tested that it was working.

Now we need to make the ADFS infrastructure available to the Internet in a secure fashion, so that Office 365 will be able to contact the ADFS proxy to authenticate user requests.

In part three we will add the ADFS infrastructure to the Office 365 configuration,

Planning And Prerequisites

Install And Configure ADFS Proxy OS

In this installation, the ADFS proxy server will be placed into the DMZ, and installed as a workgroup machine since the Tailspintoys organisation does not possess a separate management forest in the DMZ. Ensure the machine is built as per your standard build process, is secured and all Microsoft updates are installed.

You will want to install the April 2014 Windows 2012 R2 update to light up additional pieces of ADFS functionality, but we will save that for a later blog post. If you do want to take a peek at this now, the PFE Platform folks are rocking it over here – please subscribe to their RSS feed too!

Install And Verify Certificate

As discussed in part one, you will need a certificate from a trusted third party. Ensure that you check with the CA to ensure that you are able to install the certificate onto multiple servers as this is blocked in some license agreements. This is something that you must check directly with the CA.

If you are allowed to install the certificate from the ADFS server, then this simplifies matters else you will require an additional certificate. The name must match the ADFS namespace that you selected through the ADFS design process.

Name resolution

Since the ADFS server will be in a network that may not have access to the internal DNS zone information, ensure that it is able to resolve the ADFS namespace to the internal ADFS server. A swift update to the local hosts file may suffice, just remember to add this to your build documentation.

External DNS Record

Create external DNS record for the ADFS proxy server. This A record will exist in the external DNS zone of you are using split DNS. In the Tailspintoys enterprise (cough, cough this lab) the internal DNS zone is held on AD integrated DNS zones. The external zone is at a commercial ISP, so the external DNS record was created at the commercial ISP so it resolves to the external IP of the ADFS proxy when I am at Starbucks.

Open Firewalls

Having the external DNS record point to the ADFS server’s external IP address will not allow traffic to flow unless the firewalls are configured to do so. In enterprises the ADFS proxy server will be installed into a DM so there will be an internal and external firewall. Both must be opened to allow SSL traffic over TCP port 443. In addition to this the ADFS server will also need access to the CRL distribution points on the Internet to verify certificate validity.

Exchange administrators should be used to this now as they have see Exchange updates take a long time to install on Exchange servers do not have access to crl.microsoft.com. In the case of ADFS, the server should be able to hit the CRL of external CAs.

Installing Web Application Proxy

Let’s fire up the Add Roles Wizard from server manager!

Windows 2012 R2 Add Roles And Features Wizard

As noted in the previous post, there is no longer a separate ADFS proxy role in Windows 2012 R2. The Remote Access feature provides VPN, Direct Access and Web Application Proxy (WAP) functionality. It is the latter that we need to install.

Select Remote Access and let’s go find the droids we are looking for…

Installing Windows 2012 R2 Remote Access Role Service

Unless you want to add any features, like telnet * for troubleshooting purposes later, click next.

Installing Windows 2012 R2 Remote Access Role Service

The Remote Access role selection process starts. Unlike in days of old when installing a feature would install all of the bits, and by extension potential vulnerabilities, Windows now wants to only install the bare minimum. This is a paradigm shift compared to the early days of IIS where it would install everything and then you have to spend time stripping stuff back out. Index extension attack anyone?

image_thumb23

In our case we just want to install the Web Application Proxy role service, so select that and click next

Windows 2012 R2 Select Remote Access Role Service

Confirm the choice, and then install.

Windows 2012 R2 Confirm Remote Access Role Service

Once the necessary WAP role services are installed, we are then able to launch the Web Application Proxy Wizard to configure WAP.

Windows 2012 R2 Remote Access Role Installation Complete

Configure Web Application Proxy

We need to configure the WAP proxy with the necessary information so that it knows it will be publishing our internal ADFS server and how to access ADFS.

Configure 2012 R2 Web Application Proxy For ADFS

On the screen below is where most configuration issues arise with this process. What a lot of folks do is interpret the Federation service name as the display name of the ADFS server. That will not get you very far unfortunately…

Windows 2012 R2 ADFS Proxy Configuration - Beware Federation Service Name

The federation service name field does NOT want you to enter the display name of the ADFS server farm. The display name in the previous example was “Tailspintoys STS”. and this can been checked by looking in the ADFS console

Server 2012 ADFS Role Properties - Showing Display Name And Federation Service Name

If you look closely at the ADFS properties, the federation service name is actually the FQDN of the service. In our case this is adfs.tailspintoys.ca so let’s enter that along with credentials on the ADFS server so we are able to access ADFS.

Windows 2012 R2 ADFS Proxy Configuration - Federation Service Name Correctly Filled In

In the same way that we require a SSL certificate on the ADFS server, the same is true on the ADFS proxy as clients will establish SSL sessions to this machine which will then be bridged to the internal ADFS server.

Since the certificate was installed and verified as part of the preparatory work, we select it and move on.

image_thumb31

Verify the details, and click configure.

Windows 2012 R2 ADFS Proxy Configuration Verify Details

The wizard starts to configure the ADFS proxy

Windows 2012 R2 ADFS Proxy Configuration Starting...

And shortly thereafter completes!

Windows 2012 R2 ADFS Proxy Configuration Complete

Verifying ADFS Proxy Installation

At this time we should have a functional ADFS proxy server that is able to provide internet based users with access to our ADFS server’s authentication services. But as always, we need to test!

To open up the Remote Access management console, use the Remote Access Management shortcut in administrative tools.

If you have immediately launched this after installing the ADFS proxy it may take a few seconds or a refresh to show up. The other top tip is not to look for a published web app. Remember that WAP can be used to publish various applications to the internet, but in this case we are just wanting to use the base ADFS proxy components.

To check that the ADFS proxy is running, click onto the Operational Status in the left hand tree

Server 2012 R2 Remote Access Management Console

Selecting the operational status, will then show how the ADFS proxy is currently running. You can also jump to Perfmon or Event Viewer from this node.

image_thumb36

Should the ADFS proxy have an issue the console will light up like a Christmas tree. In this case I deliberately stopped the “Active Directory Federation Services” service on the ADFS proxy, please click to enlarge the image:

Less Than Happy ADFS Proxy Server

And as expected with the ADFS proxy crippled users will not be able to authenticate, even if they try an alternative browser!

No ADFS Love Here For You!

Even though the Windows service is name the same on both the ADFS server and the ADFS proxy, note that the executable path is different:

Server 2012 R2 ADFS Proxy Service Details

Server 2012 R2 ADFS Server Service Details

Verify ADFS Proxy Configuration

In event viewer on the ADFS proxy, open up the application and services logs and check that the proxy is able to retrieve it’s configuration from the ADFS server. This can be seen here, click to enlarge:

ADFS Proxy Application And Services  Event Log

With the full event details shown here:

Server 2012 R2 ADFS Proxy - Retrieving Configuration From ADFS Server

Verify Federation Service Metadata

Using the same URL as before, open Internet Explorer and navigate to your ADFS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml

The intent here is to ensure that we are able to get to the site externally. If you are not able to see the ADFS text rendered in the browser, start with ensuring that the firewalls are not dropping traffic.

Verify ADFS Sign-In Page

Browse to the ADFS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

(Note that I did not full screen the window before grabbing capture else it would be too small)

Sign In To The Tailspintoys STS

Clicking the Sign In button will prompt for credentials:

Sign In To The Tailspintoys STS

If you successfully authenticate then you will be rewarded with this stellar screen:

Now Signed  In To The Tailspintoys STS

And if are unable to type a password (like me doing demos) then you will get this less than stellar result:

OOOOpseys -- Signed  In Failed  To The Tailspintoys STS

In part three we will finish this off, and instruct Office 365 to leverage the shiny ADFS infrastructure to authenticate users.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s