Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In part 19 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we installed the Web Application Proxy (WAP) component on the two servers that are going to act as proxy servers for the AD FS servers in our Active Directory forest. We also imported the required trusted third party certificate and created the necessary DNS records for the federation service in external DNS as well as add it to the hosts file.

Let’s get going…

Publishing AD FS on the Web Application Proxy Servers

In our last article, we prepared the WAP servers for publishing the AD FS servers in the Active Directory domain to the Internet. Now we will create the publishing rule itself. In order to do so, on the first WAP server, click in the flag in the upper right corner of the “Server Manager” and then select “Open the Web Application Proxy Wizard” as shown in Figure 1.

Note:
If the Web Application Proxy post deployment configuration task is not listed under the flag in the “Server Manager”, click “Tools” and then select “Remote Access Management” in the menu.

Image
Figure 1: Launching the Web Application Proxy Wizard

On the “Welcome” page, click “Next”.

Image
Figure 2: Web Application Proxy Wizard – Welcome page

On the “Federation Server” page, enter the federation endpoint in the “Federation service name” text field. In my case, this is “fs.azurelab.dk”. Also, enter the credentials of a local administrator account on the AD FS federation servers.

Click “Next”.

Image
Figure 3: Specifying the federation endpoint and required credentials

On the “AD FS Proxy Certificate” page, we need to select the certificate we wish to use for the AD FS Proxy servers. Notice that you can only select already imported certificates and do not have an “import” option, which is why we imported the certificate via the “Certificates” MMC snap-in in our previous article.

As you can see in Figure 4, I am using a wildcard certificate for this purpose, which is fully supported. With the certificate selected, let us click “Configure”.

Image
Figure 4: Selecting the certificate that we will use for the AD FS Proxy servers

On the “Confirmation” page, we can see the PowerShell command that has been generated based on our selections and will be executed when we click “Configure”.

Image
Figure 5: Confirmation page

We are taking to the result page and will need to wait a minute or two for the wizard to complete the configuration. If it fails with an error like “Trust relationship could not be established…” or similar, make sure the AD FS service is running on the AD FS servers and that they are resolved correctly by running NSLookup on the AD FS Proxy servers. If not you need to check the hosts file we modified in the previous article. Another reason could be your certificate (invalid, not trusted etc.). Finally, make sure you use an account that has local administrator permissions on the AD FS servers. It does not need to be the AD FS service account though.

Image
Figure 6: Results page – Settings are being configured

The first WAP (AD FS Proxy) server has not been configured successfully and we can close the wizard.

Image
Figure 7: Results page – WAP was configured successfully

After closing the wizard, let us click on “Operation Status” to check the health of WAP on this server. As can be seen, the WAP server and the sub-components are all green in my case.

Image
Figure 8: Operation Status Health

Now repeat the above steps on the second WAP server.

With the second WAP server configured, we can now see both WAP servers in a cluster from both servers as shown in Figure 9.

Image
Figure 9: WAP Servers listed under Cluster Servers

Verifying Federation Service Access from the Internet

With the external DNS record in place, let us verify we have access from the Internet to the WAP (AD FS Proxy) servers and that a user can authenticate with success. To do so, I will open Internet Explorer on an external client and browse to the AD FS sign-on page using the “https://fs.azurelab.dk/adfs/ls/IdpInitiatedSignon.aspx” URL. As can be seen, I am presented with the page as expected.

Image
Figure 10: AD FS Sign-On Page

Now let us try to authenticate by clicking the “Sign in” button. After a few seconds, I’ll be prompted for credentials as shown in Figure 11. I will just add the credentials of a random domain user and click “Sign in”.

Image
Figure 11: Authenticating against the Active Directory domain

As we can see in Figure 12, the user is authenticated with success verifying access from the Internet as well as authentication works as expected.

Image
Figure 12: Domain User authenticated with success

Customizing the AD FS Sign-In Page

Back since the first version of AD FS, we had the option of customizing the sign-in page so that it matches the specific requirements set by the respective organization. Especially with previous versions of AD FS, this was the case as the AD FS team, to say the least, had not put much effort into creating a nice looking sign-in page. Figure 13 shows the default sign-in page on an AD FS 2.0 Proxy server. Yes one can definitely understand why an organization would want to beef this page up with a company logo, some more descriptive text and perhaps a privacy/security notice.

Image
Figure 13: The old AD FS 2.0 Sign-in page

With the AD FS 3.0, the default sign-in page has been improved significantly for both the administrator and end users and is probably sufficient for many organizations out there, but for those organizations that require some form of customization, this is of course still possible. And actually the customization options are much richer than in previous versions and are now configured using PowerShell commands, which in itself is a huge improvement. We can insert logo and illustration using PowerShell and even set a specific theme using .css files (customizing the entire experience and behavior of AD FS pages including error and access denied pages). And of course you can cater it to different form factors (mobile devices, tablet etc.). So unlike earlier versions, we no longer have to mess with webpage code directly.

Not only can we customize the sign-in page, we can customize the appearance of the web pages to tailor the user experience very precisely and also create standard links pointing to support, home pages and privacy links in the IT organization.

Since this article series is not about AD FS customization per se, I will not go through the steps on how to create a new theme and customizing error and access denied page. Instead, I highly recommend to check out this and this TechNet page on the subject, which provides an excellent explanation as well as step by step instructions for all customization options there is in AD FS 3.0.

Other AD FS Adjustments worth mentioning

AD FS 3.0 do not only provide improvements and changes related to customization of sign-in pages, but also a long list of other configuration options. Again, I will not go through all of them in this article, but there are two options that really stand out and have been missed by organizations at large scale.

The first is support for updating a password. A user now has the option of changing her password without being connected to the corporate network. Those of us that have worked with Exchange know this feature has been available for ages via the Outlook Web App (OWA) client. But it is good to see the feature in AD FS as well. Unfortunately though, the option is only available for workplace joined devices. But we can just use OWA then right? No unfortunately not in a federated scenario as your source of authority is the Active Directory domain on-premises. Hopefully this gets changed in the near future otherwise you need to look into the write-back option which is now an option in a federated scenario. We will look into this later on in this article series.

The other option I want to highlight is the possibility of enabling a so called extranet lockout feature, which protects the organization against brute force password guessing attacks. You can read more about this feature and how to enable it here.

AD FS Site Resilience with Azure Infrastructure as a Service

One last thing I want to touch on is site AD FS site resilience. Although not that relevant in my specific scenario since I use an availability set and a load balanced set for my Azure IaaS based AD FS servers, a lot of organizations deploy the AD FS infrastructure on-premises while only having one datacenter. If you deploy AD FS in a single datacenter, you introduce a critical single point of failure as an unavailable AD FS infrastructure equals no access to any of the Office 365 workloads. If you deploy AD FS on premises and only have one datacenter available at your disposal, it is worth considering using Azure IaaS as a fail-over datacenter. The details on such a scenario is outside the scope of this article series, but I can recommend you checkout this whitepaper on the subject. I have designed such a solution for a couple of enterprises with success, but it is important you follow the guidance closely.

This concludes part 20 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

If you would like to read the other parts in this article series please go to:

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top