Work Place Join Adventures

I’ve been working in my lab with Windows 2012 R2 AD FS and decided to test Work Place join functionality.

I configured my AD FS with device registration. You can read it here on how to do that.

I installed Web Application Proxy (WAP) and made it available via network to my Surface with Windows 8.1. You can read it here on how to do that.

Also, I configured proper DNS resolution so the device can resolve WAP via proper name. One of the above links talks about it as well.

Then I tried to workplace join my Surface device. It failed. I tried all kind of things to fix it, to no avail. So finally I contacted Microsoft Support and after a few hours of troubleshooting we figured out why it was not working and how to make it work.

What we discovered is that WAP and ADFS servers didn’t have SSL binding for the following name:

EnterpriseRegistration.myfeddomain.com:443

Tip: To see current bindings run this command:

netsh http show sslcert

So when Surface device tried to connect to registration URL, the connection was terminated by the WAP server.

I have four different test ADFS environments and decided to see if all of them had the same issue or not. So I ran that command in all four implementations and saw an interesting pattern.

When ADDS name of the domain where ADFS was installed matched Federation Service name, then the required binding was present. When ADDS name did not match the Federation Service name then the required binding was not there and work place did not work. Ok, if you not follow me, lets take a look at some examples.

Let’s say, my ADDS name is CONTOSO.COM and when I install ADFS, I give it the following name FS1.CONTOSO.COM. Name space of the ADDS and Fed Service is the same. If you look at SSL binding you will find EnterpriseRegistration.contoso.com:443

If we look at a different design, with the same ADDS Domain (CONTOSO.COM), but we install ADFS with different name, such as FS1.MYFEDDOMAIN.COM. If you look at SSL bindings you will not find required name for device registration.

When ADFS is installed with different name then the ADDS name, it does not create required SSL binding.

But, no worries. It is actually easy to add this binding and enable device registration to work. All you have to do is to run two PowerShell commands.

To make it work, first I had to run this on ADFS server:

Add-AdfsDeviceRegistrationUpnSuffix -UpnSuffix “myfeddomain.com”

It added EnterpriseRegistration.myfeddomain.com SSL binding to ADFS server.

Then I had to run this on WAP server to get the same binding registered as well:

Update-WebApplicationProxyDeviceRegistration

In my test environment I have my users in the following naming convention User@myfeddomain.com, and device registration started to work as expected.

Let me know if you got any questions.