locked
Workplace Join errors - ADFS and device registration... RRS feed

  • Question

  • On the client I get:

    Workplace Join operation failed. Activity Id: 74d3e342-b4bf-49c2-a7d5-af802ca31f69
    Exit code: 0x80180008
    Error Message: Unknown error.
    Registration Service URI: https://sts.{removed}/EnrollmentServer/DeviceEnrollmentWebService.svc


    On the server I get:

    The following exception occured while enrolling a device.

    Additional information
    Error: System.ServiceModel.FaultException`1[Microsoft.DeviceRegistration.WindowsDeviceEnrollmentServiceError]:
    WindowsEnrollmentServiceError (Fault Detail is equal to Microsoft.DeviceRegistration.WindowsDeviceEnrollmentServiceError)..

    and

    The Device Registration Service could not authenticate the caller.

    Additional information
    Failure Type: AuthenticationError.
    Failure Reason: Invalid JWT token..

    I followed all of the walk-through's...and service discovery is working. ADFS is working and authenticating users.
    Even when I try to do the workplace join, I get the messages above but the user also has a successful logon event in the event log.

    When I look through the trace logs for ADFS and DRS there are no errors. In fact, it looks like its all working.

    Help!

    • Moved by Awinish Thursday, January 2, 2014 1:24 AM
    Monday, December 30, 2013 1:20 AM

Answers

  • After building a new lab where everything functions as advertised I think I have found the cause of the error.

    I was using a wildcard certificate in my first setup. It had *.domain.com in both the subject and subject alternative name. I assumed that this would work when they say in the instructions that you should have enterpriseregistration.domain.com in the subject alternative name as well as a duplicate of the subject.

    Not so.

    So to be clear, the setup procedure will check that you have a valid certificate for the url enterpriseregistration.domain.com when you enable the DRS. A wildcard certificate is valid, but workplace join REQUIRES the subject alternative name contain the "enterpriseregistration" entry. If it's not there it will not issue a JWT token during workplace join. Oddly, browsing directly to the "otaprofile" endpoint in the DRS relying party entry works. I was able to enroll IOS devices by using the endpoint url directly.

    In short, even if you are using a wildcard certificate it still needs to look like this:

    subject: *.domain.com

    subject alternative name : *.domain.com

    subject alternative name : enterpriseregistration.domain.com

    • Marked as answer by Joshua Toon Thursday, January 2, 2014 11:46 PM
    Thursday, January 2, 2014 11:46 PM

All replies

  • Well,

    I have turned on all of the logging available in the device registration services config file. It looks like there is indeed an error when trying to workplace join a windows client. Here is the exception that is thrown:

    <Message>WindowsEnrollmentServiceError</Message>
    <StackTrace>
    at Microsoft.DeviceRegistration.WindowsDeviceEnrollmentService.AuthenticateCallerWithRetryHelper(Object messageRequest)
    at Microsoft.DeviceRegistration.WindowsDeviceEnrollmentService.RequestSecurityToken(Message messageRequest)
    at SyncInvokeRequestSecurityToken(Object , Object[] , Object[] )
    at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&amp; outputs)
    at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp; rpc)
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp; rpc)
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc&amp; rpc)
    at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
    </StackTrace>

    The thing is that I am able to register IOS clients successfully. I took a trace of both attempts. It shows the IOS client successfully enrolling and the windows device failing on the method "RequestSecurityToken".

    Right before this it looks like the service sends the client some OAuth endpoints. Right after that it fails with a "Invalid JWT token" message.


    • Edited by Joshua Toon Tuesday, December 31, 2013 12:03 AM
    Tuesday, December 31, 2013 12:00 AM
  • Hi,

    For AD FS related issue, please post in the following forum:

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=Geneva

    Regards.


    Vivian Wang

    Tuesday, December 31, 2013 6:39 AM
  • Vivian,

    ADFS is part of the operating system. It's the most actively developed part of the identity stack. Also, there are other ADFS questions in this forum.

    Maybe instead of just passing the buck to someone else you could actually look for an answer? Did you even check to see if I had posted it in that forum? I have. There haven't been any answers there either.

    Wednesday, January 1, 2014 12:18 PM
  • After building a new lab where everything functions as advertised I think I have found the cause of the error.

    I was using a wildcard certificate in my first setup. It had *.domain.com in both the subject and subject alternative name. I assumed that this would work when they say in the instructions that you should have enterpriseregistration.domain.com in the subject alternative name as well as a duplicate of the subject.

    Not so.

    So to be clear, the setup procedure will check that you have a valid certificate for the url enterpriseregistration.domain.com when you enable the DRS. A wildcard certificate is valid, but workplace join REQUIRES the subject alternative name contain the "enterpriseregistration" entry. If it's not there it will not issue a JWT token during workplace join. Oddly, browsing directly to the "otaprofile" endpoint in the DRS relying party entry works. I was able to enroll IOS devices by using the endpoint url directly.

    In short, even if you are using a wildcard certificate it still needs to look like this:

    subject: *.domain.com

    subject alternative name : *.domain.com

    subject alternative name : enterpriseregistration.domain.com

    • Marked as answer by Joshua Toon Thursday, January 2, 2014 11:46 PM
    Thursday, January 2, 2014 11:46 PM
  • Hi Joshua, 

    Thanks for posting your answer here. I've been fighting this error as well, although in my environment I do have the SAN certificate configured as you suggest here. The one thing that's idiosyncratic about my environment is that I'm using an alternate UPN suffix for my users and AD FS is published on a URL that matches the alternate UPN. My setup was originally like this: 

    certificate subject: sts.alternatedomain.com

    certificate subject alternative name: sts.alternatedomain.com

    certificate subject alternative nameenterpriseregistration.alternatedomain.com

    user: user1@alternatedomain.com

    Testing in this configuration I still get the 0x80180008 error. 

    I've also reissued my certificate with a third SAN for the primary UPN's namespace, so now I'm using: 

    certificate subject: sts.alternatedomain.com

    certificate subject alternative name: sts.alternatedomain.com

    certificate subject alternative name: enterpriseregistration.alternatedomain.com

    certificate subject alternative name: enterpriseregistration.primarydomain.com

    user: user1@alternatedomain.com

    This use of alternate UPNs is really valuable for Office 365 deployments, so I'm making sure that I test in this configuration, but right now I am having no joy. I'll try to update this thread if I crack it, but for now I thought I'd add to this thread that in some cases the two SAN URLs may not be sufficient without some further configuration. 

    Initial impressions are that event logging for DRS could be improved!

    Update: Still no luck with this 0x80180008 error from a Windows 8.1 machine, but I can join an iOS device successfully. Verbose logging revealed nothing of interest. 


    http://twitter.com/tristanwatkins http://tristanwatkins.com


    Friday, January 3, 2014 10:38 AM
  • Hi Joshua,

    That's weird.. Tristan and I have been talking about his particular case (equally valid) ... his specific requirement with UPN suffixes go beyond what I've tested to date, but I've used a single wildcard certificate on a Web Application Proxy in front of AD FS R2 without the SAN entries you mentioned and it works fine...

    In my case I've been Workplace Joining Windows 8.1 and iOS instances to an Azure test setup. The only thing installed on the WAP (beyond the client certs it uses to communicate with the R2 backend) is the wildcard certificate. There are no SAN entries for enterpriseregistration.mydomain.com, just the wildcard itself.

    FWIW, the AD is using a private domain (e.g. foo1234.net) and the Internet domain is registered (e.g. auth360.net).

    One thing I did notice is that DRS in pre-release is very unforgiving re: the setup if you haven't sorted your certificates out by the time that you install AD FS and enable Device Registration. The current test setup is RTM tho.

    Regards,

    Mylo


    http://blog.auth360.net

    Tuesday, January 7, 2014 10:58 PM
  • Yeah, I had that same unforgiving DRS configuration issue when I reissued my AD FS SAN certificate as above. I had to un/re-install AD FS and then it snapped back in to life. I'm building up a second environment in a different presently, so I may have more results in the next couple of weeks. 

    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Tuesday, January 14, 2014 5:12 PM
  • Just to qualify my earlier comments.. the Web Application Proxy is using a 3rd party wildcard certificate and the AD FS back-end has an SSL certificate complete with SAN for enterpriseregistration.mydomain.com issued from an internal PKI.

    As Tristan mentioned, DRS activation can be unforgiving and I suspect the certificate thumbprint is being written to the configuration database / AD as part of that activation process (or before), meaning that a subsequent change is not parsed... pure speculation on my part, but i'll go hunting in the meantime to confirm.

    Regards,

    Mylo


    http://blog.auth360.net

    Wednesday, January 15, 2014 11:09 PM
  • Out of curiosity, have you chosen this two certificate configuration for a specific reason? Or is there any reason your wildcard certificate would not work?


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Monday, January 20, 2014 3:44 PM
  • I actually configured it that way on the assumption that it wouldn't work on the farm without using a SAN entry for entrepriseregistration and also best practices re: using a different certificate keypair between the proxy and farm..


    http://blog.auth360.net

    Monday, January 20, 2014 3:50 PM
  • Interesting. Do you normally try to use a different authority for each of those certs if you can as well, or is that something that tends to fall out of any organisation's operational practices?

    if you ever do bottom out whether that SAN entry for enterprise registration is required, or if a wildcard will suffice, I'd definitely be interested to know.


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Friday, February 7, 2014 2:17 PM