Error in ADFS during Workplace Join


  • I am building a demo environment for Workplace Join using the walkthrough I found on TechNet here http://technet.microsoft.com/en-us/library/dn280938.aspx. I jumped through a couple of hoops and have the claimapp site working for the lab environment.

    When I now try to join the workplace from Windows 8.1 I get an event 1021 on the ADFS Server stating that an error encountered during OAuth token request.


    The exception details say: "The cause may be that artifiact has timed out, or the authorization code was replayed, orthe authorization code is invalid."

    As there is no further documentation available I am stuck at this point. How do I fix this?

    Ray - Author of Windows 7 for XP Professionals

    Thursday, July 11, 2013 2:52 PM


All replies

  • Three things to check ... if you have CRL in your cert, can you resolve CRL URL?  And are you using a CNG cert?  And what Timezone are you set to on the ADFS Server?  Couple of known issues ... don't use CNG cert and set timezone to UTC or earlier.

    And you can resolve enterpriseregistration.domainname and get to the https://enterpriseregistration... URL in the event log?

    Thursday, July 11, 2013 10:24 PM
  • Three things to check ... if you have CRL in your cert, can you resolve CRL URL?  And are you using a CNG cert?  And what Timezone are you set to on the ADFS Server?  Couple of known issues ... don't use CNG cert and set timezone to UTC or earlier.

    And you can resolve enterpriseregistration.domainname and get to the https://enterpriseregistration... URL in the event log

    CRL is working fine. When the CRL expires I see event ID 102 on the client that says so.

    All systems run in the UTC +1 time zone. Are you saying that may cause the issue?

    I reset all the regional and formatting for all systems to US English.

    In the client eventlog I currently see event ID 100 saying: "Workplace Join discovery succeeded.". I think that means that enterpriseregistration.domainname is correctly resolved.

    According to this procedure I am currently not using CNG certs. I used the default RSA#Microsoft Software Key Storage Provider when setting up the CA.

    Ray - Author of Windows 7 for XP Professionals

    Thursday, July 11, 2013 11:09 PM
  • Although I also encountered the same problem, the problem was solved when setting the server's time zone as UTC.

    But is it necessary why to change a timezone setup to UTC?

    Thursday, July 11, 2013 11:19 PM
  • Yeah, Workplace Join is working after changing the timezone to UTC -8 (Pacific Time)!

    Thanks a lot. I hope you can add this to the procedure that I used to build the demo.

    Ray - Author of Windows 7 for XP Professionals

    Thursday, July 11, 2013 11:24 PM
  • Hi Adam,

    May sound like a strange question but is this hard-wired to using the contoso.com domain for the Preview or are particular suffixes excluded? I'm using Build 9431 and using a .local suffix for a test R2 setup and I get a warning message during enabling DRS

    WARNING: UPN values that are not included in the SSL certificate have been found in the enterprise. Users with these UPN suffix values will not be able to register their devices. To enable users with the corresponding UPN suffix to register their devices, provide a new SSL certificate containing the values listed below in the subject or subject alternative name.


    The CN on the cert is set to the AD FS URL and the SAN entries contain both the URL of the AD FS service endpoint and the deviceregistration.mydomain.local name. DNS entries with an A record for AD FS and CNAME for deviceregistration are also present.

    • The test user is using a UPN suffix of @mydomain.local and the AD CS CA is trusted by the client
    • Device authentication is enabled in AD FS
    • The client is connected on a local subnet
    • The certificate template is a V2 cert so I'm not using CNG
    • Timezone is set to UTC-8 on the client and on the AD FS R2 server
    • The CRL is reachable from the client

    DC and AD FS are co-located on the same server.

    On the client in the Workplace Join log is a "Workplace Join discovery failed. Exit Code 0x80072EFD. Error Message: A connection with the server could not be established"
    Could not connect to https://EnterpriseRegistration.mydomain.local...../contract?api-version=1.0"
    I'm also unable to reach the above URL from the AD FS server itself

    Thanks for any assistance you can provide.




    Sunday, August 04, 2013 9:35 PM
  • I encountered the same problem with you ,but I don't know how to solve it ,can someone help me?
    Tuesday, August 06, 2013 3:33 AM
  • Hi David,

    Just wanted to post back. I've setup a couple of environments since, first using the contoso.com examples and then with another domain. I'll post in the coming week, experiences with testing AD FS R2 on my blog, but in the meantime I wanted to state that yes it does work :-) What I would say in advance is to make sure that the supporting infrastructure is configured correctly before you begin the AD FS installation. By that I mean, that your AD CS is up and running, CRL's available, certificate templates configured (with no CNG templates) before you begin your AD FS setup. If you're experiencing the errors I described earlier and are getting errors during the DRS activation process, then I'd consider re-installing AD FS when the above preconditions are met (including timezone settings etc). If you follow the lab guide and you're familiar with AD CS then this should be doable. If you're not familiar with the latter then post back. My mistake was assuming that things such as server certificates could be reconfigured with SAN entries after the installation was done. That does not appear to be the case and DRS flips out. Hope this helps :-)





    Thursday, August 08, 2013 10:16 PM
  • Hi I have some certificate problem would like to ask for help...

    Which Certificate Template is for workplace join?

    And how to create this SSL Certificate?

    could you please help me. :)


    Tuesday, September 10, 2013 4:17 PM
  • You don't use a certificate template for workplace join. It's a self-signed certificate issued to the client during the join process by the enrollment service.

    I've just posted a blog article on the new release of AD FS in R2. Hope this helps answer your questions.





    Friday, September 13, 2013 11:38 AM
  • Thanks Mylo,

    Now my event log appear an error

    error code : 0x80072F19

    like your psot "Can’t reach the CRL CDP of the AD CS endpoint"

    did you have a sample of SSL certificate can mail me?


    how to fix it? :((

    is it a certificate problem?


    Sunday, September 15, 2013 4:05 PM
  • Hi Mickey,

    From the blog..

    "Ensure the Certificate Revocation List (CRL) on the Certificate Distribution Point (CDP) and your Authority Information Awareness (AIA) URLs are setup correctly and reachable from the Win 8.1 client."

    This is the error your client is reporting. It cannot see the CRL Distributiothe Point of the Certification Authority. I got round this by setting up IIS on the Web Application Proxy.

    The CDP is used to publish information about the validity of certificates issued by the CA. By default it will publish to LDAP and HTTP endpoints. Since your client is not part of the domain, the LDAP URLs are of no use, leaving you with publishing HTTP URLs for the CDP as suggested in the blog post, using an FQDN reachable from the client.

    Post your CRL Distribution Point info (it's in the graphic above) if you need more assistance.




    Monday, September 16, 2013 6:58 AM
  • Hi Mylo,

    This is my CRL Distribution Point.

    I can reach the url, but my client can't join workplace.

    the error code : 0x80072F19

    the same issue.

    Tuesday, September 17, 2013 3:15 AM
  • Mickey,

    Can you check if you can also obtain the Delta CRL from the IIS Server?

    In your case this should be http://DC1.contoso.com/CertEnroll/contosoCA+.crl

    If that doesn't work, checkout the solution described in this post

    Ray - Author of Windows 7 for XP Professionals

    Tuesday, September 17, 2013 8:35 AM
  • Hi Mickey,

    I used a named SSL certificate on my AD FS instance rather than a wildcard.. you need to watch the order also .. this works for me...


    SAN DNS 1= adfs1.contoso.com

    SAN DNS 2= enterpriseregistration.contoso.com

    As NextXPert pointed out and mentinoed in the blog post:

    "If you’re using Delta CRLs and IIS as the web server for your CDP, don’t forget to allow Double Escaping on IIS in the Request Filtering section. "

    Use the PKIVIEW MMC snapin on the DC/CA and check to see what's red-lining CDP-wise




    Tuesday, September 17, 2013 4:05 PM
  • Similar issues here, but not quite the same.

    Following the same guide as everyone else.

    I can get my client to access the CDP, and resolve enterpriseregistration.contoso.com, but the URL that is being returned to the client when it connects is a redirect to http://enterpriseregistration.contoso.com:80/enrollmentserver/contract.

    I don't see any vdir named enrollmentserver in IIS?

    What have I missed?


    Thursday, September 19, 2013 11:51 PM
  • Hi Chris,

    AD FS R2 uses kernel-mode (HTTP.SYS) .. there's no IIS being used. Can you run a netsh http urlacl and post the result back. The enrolment server runs on Port 443 (HTTPS) only so I don't see how you're get redirected over Port 80..




    Friday, September 20, 2013 6:19 PM
  • Thanks for the reply Mylo.

    OK, so I had misconfigured it, but have solved that one now.

    Boy - is this picky!

    I now have error 102 on the client, which is

    could not connect to:

    Although if I click the link in eventvwr, I get a response back with 2 lines of text (too much to write out!) but what basically looks like a response back from ADFS.

    I'll keep plugging away...


    Friday, September 20, 2013 7:48 PM
  • Hi Chris,

    Can you check the details view for the event in the event viewer?

    In my test lab it showed that there were issues with certificate revocation checking.

    Ray - Author of Windows 7 for XP Professionals

    Friday, September 20, 2013 8:39 PM
  • Thanks Ray,

    I can manually reach the CRL on the client, so I don't think it's that, although the error suggests it might be.

    It's more about the URL in the message below.

    this is what I see if I click the link above

    Friday, September 20, 2013 8:58 PM
  • Hi Chris,

    What do you see when you run the PKIVIEW snapin on the DC/CA .. is it all OK?




    Saturday, September 21, 2013 7:13 AM
  • Yes, all read 'OK'

    Saturday, September 21, 2013 9:47 PM
  • Chris,

    Can you make sure that you are able to obtain both the CRL AND the delta CRL?

    I also had some cases that it worked with a different Windows 8.1 client where I was not able to exactly point out where the process went wrong with the first Windows 8.1 client.

    Ray - Author of Windows 7 for XP Professionals

    Sunday, September 22, 2013 9:25 PM
  • CRL is accessible, cant check delta right now.

    could be a preview issue? Might try RTM

    Sunday, September 22, 2013 9:39 PM
  • could be a preview issue? Might try RTM

    The only issue I had with preview was about the time zone on the AD FS Server. I don't think this is related to that.

    Ray - Author of Windows 7 for XP Professionals

    Monday, September 23, 2013 7:33 AM
  • Thank you so much for you response.is my certificate problem,Now I have to solve the problem,everyting works fine.
    Wednesday, October 09, 2013 6:59 AM
  • Nice to hear.




    Wednesday, October 09, 2013 8:20 PM