locked
Does ADFS 2019 support Windows Hello for Business? RRS feed

  • Question

  • I'm trying to get Windows Hello for Business (on-prem only, no cloud integration) to work in my lab environment following the directions here: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust 

    I've gone through and rebuilt the lab from scratch three times - once using Windows 2016 for the ADFS server where WHFB worked as expected, and twice where the only change was using Windows 2019 for the ADFS server. Neither of the times with 2019 worked. Further, after the second failure with ADFS 2019, I uninstalled it and then installed ADFS 2016 making no other changes and clients were immediately able to enroll, so it makes me think that there is either a bug in 2019, or additional configuration steps are required that aren't documented.

    In the labs with ADFS 2019, the Windows 10 Enterprise 1803 or 1809 clients never present the enrollment wizard. This error appears in the Hello for Business event log: "The Primary Account Primary Refresh Token prerequisite check failed." (event id 7201)

    Device registration appears to be at least partially successful because an object is created in the device container in AD and a registration certificate shows in the certificates MMC - just like in the successful lab using 2016.

    Running "dsregcmd /status" on the client gives the following output:


    +----------------------------------------------------------------------+
    | Device State                                                         |
    +----------------------------------------------------------------------+
                 AzureAdJoined : NO
              EnterpriseJoined : YES
                  DomainJoined : YES
                    DomainName : CORPLAB
    +----------------------------------------------------------------------+
    | Device Details                                                       |
    +----------------------------------------------------------------------+
                      DeviceId : 9884a0b6-6b06-4b62-9a17-d446f13bc89a
                    Thumbprint : D18A88EF55F6453AB256B63B0BF143A5DED8A1BF
     DeviceCertificateValidity : [ 2018-12-31 18:51:50.000 UTC -- 2028-12-28 19:01:50.000 UTC ]
                KeyContainerId : 81748970-9c3f-46e9-9e4c-8a9cfd6ad6de
                   KeyProvider : Microsoft Software Key Storage Provider
                  TpmProtected : NO
    +----------------------------------------------------------------------+
    | Tenant Details                                                       |
    +----------------------------------------------------------------------+
                    TenantName :
                      TenantId : 383a3889-5bc9-47a3-846c-2b70f0b7fe0e
                           Idp : login.windows.net
                   AuthCodeUrl : https://sso.corp.lab/adfs/oauth2/authorize
                AccessTokenUrl : https://sso.corp.lab/adfs/oauth2/token
                        MdmUrl :
                     MdmTouUrl :
              MdmComplianceUrl :
                   SettingsUrl :
                JoinSrvVersion : 1.0
                    JoinSrvUrl : https://sso.corp.lab/EnrollmentServer/device/
                     JoinSrvId : urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A
                 KeySrvVersion : 1.0
                     KeySrvUrl : https://sso.corp.lab/EnrollmentServer/key/
                      KeySrvId : urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A
            WebAuthNSrvVersion : 1.0
                WebAuthNSrvUrl : https://sso.corp.lab/webauthn/383a3889-5bc9-47a3-846c-2b70f0b7fe0e/
                 WebAuthNSrvId : urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A
        DeviceManagementSrvVer : 1.0
        DeviceManagementSrvUrl : https://sso.corp.lab/manage/383a3889-5bc9-47a3-846c-2b70f0b7fe0e/
         DeviceManagementSrvId : urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A
    +----------------------------------------------------------------------+
    | User State                                                           |
    +----------------------------------------------------------------------+
                        NgcSet : NO
               WorkplaceJoined : NO
                 WamDefaultSet : NO
    +----------------------------------------------------------------------+
    | SSO State                                                            |
    +----------------------------------------------------------------------+
                    AzureAdPrt : NO
           AzureAdPrtAuthority :
                 EnterprisePrt : NO
        EnterprisePrtAuthority :
    +----------------------------------------------------------------------+
    | Diagnostic Data                                                      |
    +----------------------------------------------------------------------+
             AadRecoveryNeeded : NO
                   KeySignTest : PASSED
    +----------------------------------------------------------------------+
    | Ngc Prerequisite Check                                               |
    +----------------------------------------------------------------------+
                IsDeviceJoined : YES
                 IsUserAzureAD : NO
                 PolicyEnabled : YES
              PostLogonEnabled : YES
                DeviceEligible : YES
            SessionIsNotRemote : YES
                CertEnrollment : none
                  PreReqResult : WillNotProvision

    If you've gotten ADFS 2019 to work with WHFB, can you tell me if you had to do anything else not in the standard documentation?

    Thanks for any help that anyone can provide.

    Monday, December 31, 2018 8:37 PM

Answers

  • Alright, let's try that on your ADFS server:

    Add-AdfsScopeDescription -Name ugs
    $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers "http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope" | ?{ $_.ClientRoleIdentifier -eq "38aa3b87-a06d-4817-b275-7a316988d93b" }).ObjectIdentifier
    Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
    Restart-Service ADFSSRV

    Then restart also the client and try again. Let us know!


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Wednesday, January 23, 2019 2:15 PM

All replies

  • One other piece of data - whenever a user logs into a client (and WHFB tries and fails to start the enrollment wizard), the ADFS 2019 server logs event 1021 with the follow text:

    Encountered error during OAuth token request.

    Additional Data

    Exception details:
    Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

    Searching for this event or message text isn't coming up with useful results for me, but maybe someone else recognizes what the issue is. Again, thanks for any help you can provide.

    Wednesday, January 2, 2019 7:52 PM
  • Let me know how this goes. I just installed a 2019 server and was about to use it for ADFS and Hello, but maybe I will stick with 2016 for now.
    Wednesday, January 2, 2019 8:32 PM
  • I've done one further test that has me fairly convinced that this is a bug in ADFS 2019. I went back to the lab with ADFS 2016 where Hello enrollment was working correctly and added a new ADFS 2019 server as an additional farm node then promoted it to be the primary node. I could no longer enroll new clients with WHFB and the ADFS 2019 server generates the same OAuth error that I described above. (Note that I never removed the 2016 node from the farm so the "level" is still 2016)

    I'm hoping that someone from MS sees this thread and can confirm whether there are any known issues with on-prem Hello in 2019 or any undocumented steps required to get it working. Absent that, I'll probably have to put this aside unless I can get internal approval to open a ticket for a non-production issue.

    Thursday, January 3, 2019 2:28 PM
  • I'm also having this issue. Upgraded to ADFS 2019, same OAuth error, had to revert back to 2016.

    Please fix, Microsoft! We're using WHfB and this is blocking us from upgrading to 2019.

    Thursday, January 17, 2019 8:48 PM
  • What version of ADDS do you use?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, January 22, 2019 2:05 PM
  • I've tested with both 2016 and 2019 ADDS servers. The only variable that seems to make a difference is whether the ADFS server is 2016 or 2019 - WHFB never works on ADFS 2019 regardless of ADDS version.
    Tuesday, January 22, 2019 3:01 PM
  • Can you share the AD FS debug logs?

    Do you have any authentication error message on your DCs?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, January 22, 2019 3:14 PM
  • I don't see any authentication errors on the DC when I log into the client and expect the enrollment wizard to start. On the ADFS 2019 server, in the App&Services/AD FS/Admin event log there is one error at that same time, event ID 1021 with the same message text that I posted above about the "Encountered error during OAuth token response..." There don't appear to be any related events in the Application, Security, or System logs.

    If there is another log location to look at or diagnostic to run, I'll be happy to give it a shot. Thanks for looking into this.

    Tuesday, January 22, 2019 3:36 PM
  • Yep, maybe the AD DS debug logs. I think it is called Trace logs, you have the details here: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-logging

    Enable it, repro and disable it. And upload the content somewhere as ETVX if you don't mind?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, January 22, 2019 8:09 PM
  • Okay, here's the Tracing/Debug log export: https://1drv.ms/u/s!AtgOpmw07w7mrMBhTO4PAyhOcBad6g

    Wednesday, January 23, 2019 12:08 PM
  • Alright, let's try that on your ADFS server:

    Add-AdfsScopeDescription -Name ugs
    $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers "http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope" | ?{ $_.ClientRoleIdentifier -eq "38aa3b87-a06d-4817-b275-7a316988d93b" }).ObjectIdentifier
    Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
    Restart-Service ADFSSRV

    Then restart also the client and try again. Let us know!


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Wednesday, January 23, 2019 2:15 PM
  • That works! Thanks for that. My only other question is this: right now I'm testing all of this in my lab so I'm happy to run the PowerShell and tweak whatever. But in production, if I had to open a ticket for any ADFS issue after running the above script, will I still be in a supported state since it looks like we fiddled with permission settings that don't seem to be documented? Alternately, will the permission tweak in the PowerShell script above be rolled into a future monthly CU?

    Again, many thanks for taking the time to assist.



    • Edited by BTW97 Wednesday, January 23, 2019 3:40 PM Spelling
    Wednesday, January 23, 2019 3:32 PM
  • I have been told that it is supported yes.

    The public KB will be posted in Feb/Mar time frame.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, January 25, 2019 10:16 PM