Windows Server 2012 R2 and BYOD (Part 7)

by [Published on 5 June 2014 / Last Updated on 5 June 2014]

This article continues the discussion of Windows Server 2012 R2 BYOD environments.

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

In the previous article, we set up a simple Web application that could be used for testing purposes. In this article, I will show you how to link this Web application to the Active Directory Federation Service. By the time that you reach the end of this article, all of the infrastructure will be in place and you will be able to service BYOD workplace join requests.

I also showed you how you could set up a simple Web app that you could use for testing purposes. Although the app is fully functional at this point, we still need to make the Active Directory Federation Services aware of the app.

Configure the Web App to Work With Your Federation Server

In order to configure the Web app to work with your federation server, open File Explorer on your Web server and navigate to C:\Program Files (x86)\Windows Identity Foundation SDK\3.5. Upon doing so, double click on the FedUtil.exe file. Windows will then launch the Federation Utility.

This utility requires you to enter an application configuration location and an application URI. The application configuration location should be set to C:\inetpub\claimapp]Web.cfg. The application URI must match the URL that you set up in the previous article. For example, on my server the URI is https://web.byod-lab.com/Claimapp/. You can see what this looks like in Figure A.

Image
Figure A: You must enter an application configuration location and an application URI.

Click Next and Windows will ask you whether or not you want to use the Security Token Service. Select the Use an Existing STS option. You will also have to enter your Active Directory Federation Server’s metadata location. The URL that you will need to enter will vary depending on how you have configured your environment. If you are using the same naming convention that I am then you will enter https://adfs.byod-lab.com/federationmetadata/2007-06/federationmetadata.xml. You can see what this looks like in Figure B.

Image
Figure B: You must enter a location for your Active Directory Federation Service’s metadata.

Click Next and you will be prompted to choose whether or not you want to use certificate chain validation. Choose the Disable Certificate Chain Validation option and click Next.

You will now be prompted to configure token encryption. Choose the No Encryption option and click Next.

At this point, you should see the Offered Claims page. Click Next to accept the defaults. When you do, you will be taken to a summary screen. Select the check box labeled Schedule a Task to Perform Daily WS-Federation Metadata Updates and then click Finish.

Testing the Redirection Process

At this stage in the process, it is a good idea to open Internet Explorer and enter the URL for your Web app. As you may recall, I configured my demo servers to use the following URL: https://web.byod-lab.com/Claimapp/

When you enter this URL, you should be redirected to the Active Directory Federation Service server. You can verify the redirection by looking at the URL. Although the redirection process should work, the Active Directory Federation Service should cause your browser to display an error like the one shown in Figure C. This error occurs because we have not yet configured a relaying party trust.

Image
Figure C: The Active Directory Federation Service server should produce an error.

Configuring a Relay Party Trust

The last step in the server side configuration process is to create a relaying party trust on the Active Directory Federation Server. To do so, log into your Active Directory Federation Service server and then choose the AD FS Management command from the Server Manager’s Tools menu. This will cause Windows to open the AD FS Management console.

Navigate through the console tree to AD FS | Trust Relationships | Relaying Party Trusts. Now, click the Add Relaying Party Trust command, found in the Actions pane. This will cause Windows to launch the Add Relaying Party Trust Wizard.

Click Start to bypass the wizard’s Welcome screen. When you do, you will be taken to the Select Data Source screen. Select the option to Import Data About the Relaying Party Published Online or on a Local Network. Upon doing so, you will need to enter the metadata URL for your Web app. This is a similar URL to the one that you used earlier, except that you will need to make reference to an XML file that was created by the FedUtil.exe tool. If you are using the same naming conventions that I am, the URL will be https://Web.byod-lab.com/claimapp/federationmetadata/2007-06/federationmetadata.xml. You can see what this looks like in Figure D.

Image
Figure D: You must enter the location of the federationmetadata.xml file.

Click next, and you will be prompted to provide a display name. Click Next to accept the defaults.

You will now be taken to the multifactor authentication page. Choose the I Do Not Want to Configure Multi-Factor Authentication Settings for this Relaying Party Trust at this Time option and click Next.

The next screen that you will see is thew Choose Issuance Authorization Rules screen. Choose the Permit All Users to Access this Relaying Party option and click Next. Click Next once more on the Ready to Add Trust screen. Click Close to complete the wizard.

When the Add Relaying Party Trust Wizard closes, the Edit Claim Rules Wizard should open. Click the Add Rule button. You will now be prompted to choose a rule type. Select the Send Claims Using a Custom Rule option and then click Next. You will now be prompted to enter a custom rule. You must call the rule All Claims and the rule should look like this:

C:[ ]

=> issue(claim = c);

You can see what this looks like in Figure E. Click Finish, followed by OK to complete the process.

Image
Figure E: You will have to create a custom rule.

Another Test

At this point, I recommend going back to your Web server and attempting to access the Web app URL once again. This time, you should be prompted for a set of credentials. When you enter your credentials, you should be taken to the claim app, which you can see in Figure F.

Image
Figure F: This is what the claim app should look like.

Conclusion

As you can see in the previous figure, we were able to redirect a request that was intended for our Web server to the Active Directory Federation Server. The Active Directory Federation Server provided the necessary claim and then relayed the request back to the Web server. The Web application shown in the previous figure serves as proof that the process is working.

As of right now, we have all of the necessary infrastructure in place to facilitate end user requests from personal devices. In the next article, I will conclude the series by showing you how to import a certificate into an end user device, and how to perform a workplace join on the device. The workplace join will allow the end user’s device to access the Web application that we have set up in spite of the fact that the device is not actually joined to the Active Directory domain.

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

Advertisement

Featured Links