If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 3)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 9)
Introduction
So far in this article series we have done a lot of work to set up the various infrastructure components and make it possible for users to join their personal devices to the workplace. Now that all of that work is done and we have verified that the claim app that we previously set up is working correctly, it is time to actually perform a workplace join.
For the purposes of this article series, I have set up a client computer that is running Windows 8.1. This computer is not domain joined and will represent a user’s own personal device. Even though I am using a PC operating system, I could have just as easily used a tablet or other device.
Before the Workplace Join
As you will recall, we previously set up a Web app that represents a Web based line of business application on our corporate network. With that in mind, let’s get started by trying to access that app from our Windows 8 desktop. If you are following along and using the same setup that I am using then the URL is: https://web.byod-lab.com/Claimapp/
When you attempt to access the claim app, there are a few things that happen. First, you will see a certificate error similar to the one that is shown in Figure A.
Figure A: You should receive a certificate error when you attempt to connect to the claim app.
If you choose to continue on to the Web site then you are prompted to enter a username and password. When you enter a domain user’s username and password, you are taken into the claim app, as shown in Figure B. However, the claim app only displays user claims because those are the only types of claims that are included in your security token. Furthermore, if you close and re-open the app then you are prompted to log in again because there are no single sign on capabilities.
Figure B: The claim app is accessible but the certificate error remains and only user claims are displayed.
Fixing the Certificate Error
As you will recall, a certificate error was displayed on the Windows 8.1 device when I tried to access the claim app. This error occurred because I used an internal enterprise certificate authority, and Windows 8.1 does not trust my home grown certificate authority by default (nor should it). As such, we need to tell the client computer that it is OK to trust the certificate authority. Not only will doing so correct the certificate error, but it will also make it possible for the device to be workplace joined.
The way that we fix the certificate error is by downloading and installing a CA certificate. The CA certificate tells the device that it is OK to trust the certificate authority that provided the certificates used by ADFS and by the claim app.
As you may recall from one of the earlier articles in this series, our domain controller is configured to act as an enterprise certificate authority and features a Web interface that can be used for issuing certificate requests. If you are using the same naming conventions that I am using, the URL for this Web interface is https://DC.BYOD-Lab.com/CertSrv. Otherwise the URL is https://<your domain controller’s fully qualified domain name>/CertSev/
Enter the certificate authority’s URL into your browser and then log in as a domain administrator when prompted. When the Web interface appears, click on the option to Download a CA certificate, certificate chain, or CRL, as shown in Figure C.
Figure C: You must download a CA certificate.
On the following page, choose the option to download a CA certificate. When prompted, choose the option to open the certificate. Next, click on the Install Certificate button, shown in Figure D. If prompted, the certificate should be installed for the local machine. On the following screen you must install the certificate to the Trusted Root Certification Authority store, as shown in Figure E.
Figure D: Click the Install Certificate button.
Figure E: You must install the certificate to the trusted root certification authority store.
Once your certificate has been imported, close the browser, re-open it, and go to the certificate authority’s URL. This time you should not receive a certificate error.
There are two things worth noting about the process of downloading a certificate. First, you don’t have to download the certificate separately for every device. You can download it once and then make it available to your users.
The other thing to consider is that if your network infrastructure is configured to use certificates from a well-known commercial certificate authority then you will be able to skip this portion of the process since the mobile devices should already trust the certificate authority by default.
Attempting a Workplace Join
At this point, the client computer is finally ready to be workplace joined. The exact method that you will use will vary depending on the operating system that is running on the device. The instructions in this section assume that Windows 8 is being used.
With that said, move your mouse to the upper right corner to reveal the various charms and then click on Settings. When the Settings pane appears, click on Change PC Settings, followed by Network, and Workplace. When the Workspace screen appears, enter the user’s ID, as shown in Figure F, and then click Join.
Figure F: Enter the user ID and click Join.
You should now be prompted for your password. Upon successfully entering your authentication credentials you should see a message indicating that the workplace join was successful.
What Went Wrong?
Hopefully you were able to successfully workplace join your device. If not though, don’t despair. As you have already seen, there is a lot of work that goes into enabling workplace join and there is a lot of room for things to go wrong.
I had originally intended for this to be the last article in the series. However, I have been seeing a lot of posts in various message boards from people who are having trouble making workplace join work correctly. That being the case, I want to spend Part 9 of this article series discussing some troubleshooting techniques.
If you want to begin the troubleshooting process on your own, there are two main things that tend to go wrong with regard to workplace join. By far the more common of the two problems is that the certificates are not configured correctly. Workplace join simply cannot work unless the certificates are properly configured.
The other somewhat common problem that people seem to experience is related to DNS name resolution. Your DNS server must be able to resolve the various host names that are used within the environment that we have set up. I will walk you through some troubleshooting steps in the next article in this series.
If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 3)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 9)
