This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hello!
I implementing Windows Hello for Business on-premises - On Premises Certificate Trust Deployment (Active Directory + AD FS + AD CS = without Azure AD) in my organization.
Using the manual: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust
ADFS: Windows 2019
ADSC: Windows 2016
AD(Forest/Domain/Scheme): 2016
During the integration process, strange problems were revealed. Some clients don't register in my domain's Workplace "CN=RegisteredDevices,DC=domain,DC=local" automatically!
At the moment, I am watch a client with the Windows 10 LTSC 1809 operating system (including the KB4570333 update). TPM module version is 2.0. It may have been previously attached to Azure AD, but now his only need to attach it to the on-premises Active Directory infrastructure!
Question: how can I automatically delete all registration bindings to Azure AD accounts on the client computer? How to destroy external registration correctly? How do I properly clear the device registration from the command line, group policy, registry, or other non-interactive method?
At the moment, I can't attach the client to the local infrastructure ...
I'm trying to do it in a hard way:
dsregcmd::wmain logging initialized.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO
5. 1. remove Settings.dat in C:\Users<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\
5. 2. remove All the files under the folder C:\Users<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Account
6. remove C:\ProgramData\Microsoft\Crypto\Keys
7. Running dsregcmd /debug /join
dsregcmd::wmain logging initialized.
DsrCmdAccountMgr::IsDomainControllerAvailable: DsGetDcName success { domain:domain.local forest:domain.local domainController:\co-dc01.domain.local isDcAvailable:true }
PreJoinChecks Complete.
preCheckResult: Join
isPrivateKeyFound: undefined
isJoined: undefined
isDcAvailable: YES
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: undefined
elapsedSeconds: 0
resultCode: 0x0
Automatic device join pre-check tasks completed.
TenantInfo::Discover: Join Info { TenantType = Federated; AutoJoinEnabled = 1; TenandID = xxx-xxx-xxx-xxx; TenantName = fs.domain.local }
GetComputerTokenForADRS: Get token for enterprise DRS
GetComputerTokenForADRS: Token request authority: "https://login.microsoftonline.com/common"
AdalLog: Token is not available in the cache ; HRESULT: 0x0
AdalLog: Authority validation is enabled ; HRESULT: 0x0
AdalLog: Authority validation is completed ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken get refresh token info ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken- refresh token is not available ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken- returns false ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::UseWindowsIntegratedAuthEnterprise ; HRESULT: 0x0
AdalLog: HRESULT: 0x4aa90010
AdalLog: HRESULT: 0x4aa90010
AdalLog: HRESULT: 0xcaa9002c
AdalLog: HRESULT: 0xcaa9002c
AdalLog: HRESULT: 0xcaa9002c
LogFatalAuthError: AdalMessage: ADALUseWindowsAuthenticationNonHybrid failed, unable to preform integrated auth
AdalErrorCode: 0xcaa9002c
AdalCorrelationId: {xxx-xxx-xxx-xxx}
AdalLog: HRESULT: 0xcaa9002c
AdalLog: HRESULT: 0xcaa9002c
AdalLog: HRESULT: 0xcaa9002c
AdalLog: HRESULT: 0x4aa90010
AdalLog: HRESULT: 0x4aa90010
AdalLog: AggregatedTokenRequest::UseWindowsIntegratedAuthEnterprise ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken- returns false ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken- refresh token is not available ; HRESULT: 0x0
AdalLog: AggregatedTokenRequest::AcquireToken get refresh token info ; HRESULT: 0x0
AdalLog: Authority validation is completed ; HRESULT: 0x0
AdalLog: Authority validation is enabled ; HRESULT: 0x0
AdalLog: Token is not available in the cache ; HRESULT: 0x0
AdalLog: HRESULT: 0xcaa1000e
AutoEnrollAsComputer: Unable to retrieve access token. GetComputerTokenForADRS failed with error 0xcaa9002c.
DsrCmdJoinHelper::Join: Federated enterprise DRS join failed with error 0xcaa1000e.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO
8. Running dsregcmd /status
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+AzureAdJoined : NO EnterpriseJoined : NO DomainJoined : YES DomainName : DOMAIN+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+NgcSet : NO WorkplaceJoined : NO WamDefaultSet : ERROR+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+AzureAdPrt : NO AzureAdPrtAuthority : NO EnterprisePrt : NO EnterprisePrtAuthority : NO+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+Diagnostics Reference : www.microsoft.com/aadjerrors User Context : SYSTEM Client Time : 2020-10-13 00:59:17.000 UTC AD Connectivity Test : PASS AD Configuration Test : PASS DRS Discovery Test : PASS DRS Connectivity Test : PASS Token acquisition Test : FAIL [0xcaa9002c/0xcaa1000e] Correlation-id: {xxx-xxx-xxx-xxx} Fallback to Sync-Join : ENABLED Previous Registration : 2020-10-13 00:58:11.000 UTC Registration Type : fed Error Phase : auth Client ErrorCode : 0xcaa1000e Correlation Id : {xxx-xxx-xxx-xxx}+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+IsDeviceJoined : NO IsUserAzureAD : NO PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : YES CertEnrollment : none PreReqResult : WillNotProvision
I'm reaching within the product team and will come back to you.
Hello!
Thank you for trying to solve the problem!
Can you tell us how long it usually takes to wait for a response from the product team?
If necessary, I can provide additional technical information (logs).
Side questions in the meantime:
Is Windows Hello for Business working fine on a device that was never joined to an Azure AD domain?
if short - Yes.
In more detail, even most of the devices installed in Azure AD (we use Microsoft Teams, they use its registration) are successfully registered.
There was a problem computer, but deleting the folder helped "C:\ProgramData\Microsoft\Crypto\Keys". After that, it successfully registered in the domain as a device. By the way, can you tell us what purpose this directory is used for?
Are you users also out of the Azure AD Connect Sync? Or is that gone too?
Yes, all our users sync with the cloud via Azure AD Connect Sync ...
Why moving away from the Hybrid model here? It seems that you have Azure AD already, so what is the reason to move to an on-premises?
I was afraid of the architecture of work that requires a constant connection to the Internet
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration#hybrid-azure-ad-joined-in-federated-environments
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication#hybrid-azure-ad-join-authentication-using-a-certificate
Is Azure AD becoming a priority infrastructure element over on-premises AD controllers?!
If in the morning there is a failure with the Internet or with ADFS and thousands of employees come to work, start entering pin codes, biometrics, then Windows Hello will definitely try to get a session key from the Internet?! And won't get it?! What will happen? If the crash occurs, new computers will also not be able to register in the local AD? If there is no Internet (faulty ADFS), it is temporarily possible to log in using local cache data to clients, how long will this last? Does the local cache exist? New users can't log in?
They can't change the pin code?!
Please specify in addition, only what authentication methods need to be enabled on ADFS for use on Windows Hello in Intranet and Extranet. So that both device registration and user authentication work? Unfortunately, the documentation does not explicitly state anything... For the on-permissive scheme, all Extranet was turned off, and in Intranet, everything was turned on except Microsoft Passport Authentication. Worked. But there were warnings in the event log that there are no additional properties, the Microsoft Passport Authentication method is required. We have enabled absolutely all authentication methods. And what and for which tasks are used in the architecture of Windows Hellow?
When "Azure AD Hybrid Joined" you do not need Azure AD for the authentication. If you have a line of sight with a DC, you will use the DC. If you have no line of sight, then you will use your cached credentials. In the context of WHfB, Azure AD is used for the registration and provisioning of your WHfB credentials. Once this is done and Azure AD Connect Sync has written the key on-prem, you don't depend on AAD to login.
You do depend on AAD to obtain an AAD PRT and get a real SSO experience with Azure AD workloads (such as Office 365).
When Azure AD Joined you need Azure AD for the authentication. But if Internet is down, you can still connect to your machine with cached credentials. Also, if your machine has a line of sight with a DC, you will also get a Kerberos ticket for on-prem SSO.
Also, ADFS is not required to access to Azure AD with SSO. PRT will give you SSO on machines even if you don't have ADFS.
Thank you so much for this detailed comment!
But it seems you have me even more confused :)...
Once this is done and Azure AD Connect Sync has written the key on-prem, you don't depend on AAD to login.
Can you tell us in which folder this key will be stored? Device registration or user registration together (or is the user key stored only in the local DC in the msDS-KeyCredentialLink attribute)?
Also, ADFS is not required to access to Azure AD with SSO. PRT will give you SSO on machines even if you don't have ADFS.
Then why do I need AD FS? If in a hybrid architecture, we get the TGT Kerberos from the local DC, and the PRT client directly over the Internet will try to get through Azure AD?! What is the role of ADFS? Clients will get all the information from the AD properties described by SCP. ADFS will only write the user's key in msDS-KeyCredentialLink?!
So, in order for thousands of computers to get PRT in the process, they must have access to the Internet (may violate internal security regulations)??? PRT get the scheme does not work like this: PC < - > ADFS < - > Azure AD ? In this case, PRT is needed only for device registration and for regular operation of Windows Hello?
Hum, this goes in many directions...
ADFS is not required to access Azure AD with Single Sign On with Azure AD. It used to be the case like years ago. Now to get SSO we can:
Also, for that last point, we you are Azure AD joined, you also get a TGT if your machine can access a DC. Else you don't. But if you did, then you also have SSO with on-premises applications (for the domain joined machine, you always get SSO to on-prem applications).
And YES you need Internet to get a PRT.
But the point of the PRT is to access Azure AD workloads (such as Office 365).
So no internet = no Azure AD workloads, so you don't care about the PRT in that context.
Regarding the key storage, it is irrelevant. Device Registration and Windows Hello for Business processes take care of things without having you removing manual files.
I suggest you post a clear list of questions in a new post as it is very hard to follow in this comment section. Your questions might help other users and they should be available in a way it is easy to search.
You asked "Why moving away from the Hybrid model here?" I started asking dozens of questions that I had after reading the documentation. You answered them in great detail! If you make an article out of your answers and post it here https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works#technical-deep-dive people will have fewer questions and doubts about which architecture model to choose. Yes, in my case, I may have to change the architecture to a hybrid one. But the question in the post was actually in another - added a comment to Miss sandyzeng's answer.
Sorry, if this technical resource is not accepted to reason and ask questions ... but thank you so much for your time! You put my thoughts in order!
One more small question :)
So no internet = no Azure AD workloads, so you don't care about the PARTY in the context.
Will Windows Hello work on domain computers without the Internet with a hybrid model? :) Allows me to set a pin code? Or write "something went wrong". Or the Internet is required for registration device only. But if the computer with the Internet is registered, then i can safely remove the Internet and never connect! And then the pin code installation and pin code change will work?
No, in Hybrid you will require Azure AD connectivity for the device registration and for the provisioning. Then you will need Azure AD Connect to sync the key back to your user object in AD on-prem which also requires an internet connectivity for your Azure AD Connect server.
Glad it helps :)
Your question isn't related to Windows Hello for business hybrid, more for doing Hybrid Azure AD join.
Please first check out this Microsoft documentation, how to plan and configure hybrid Azure AD join for federated domain
Based on your error code, there might be misconfigured on your ADFS farm. Check if Windows Integrated Authentication is enabled for Intranet, is working correctly for Intranet and WSTrust windows endpoints are enabled in ADFS.
Regards,
Sandy
Your question isn't related to Windows Hello for business hybrid, more for doing Hybrid Azure AD join.
Hello there!
My question was exclusively about the "on Premises" model. Mr. piaudonn and I got into a discussion about the "Hybrid" model, but I have a problem right now with the "on Premises" model.
Question: how can I automatically delete all registration bindings to Azure AD accounts on the client computer? How to destroy external registration correctly? How do I properly clear the device registration from the command line, group policy, registry, or other non-interactive method?
Check if Windows Integrated Authentication is enabled for Intranet, is working correctly for Intranet and WSTrust windows endpoints are enabled in ADFS
AdditionalAuthenticationProvider : {CertificateAuthentication}
DeviceAuthenticationEnabled : True
AllowAdditionalAuthenticationAsPrimary : False
EnablePaginatedAuthenticationPages : False
DeviceAuthenticationMethod : All
TreatDomainJoinedDevicesAsCompliant : False
PrimaryIntranetAuthenticationProvider : {FormsAuthentication, WindowsAuthentication, CertificateAuthentication, DeviceAuthentication,
MicrosoftPassportAuthentication}
PrimaryExtranetAuthenticationProvider : {}
WindowsIntegratedFallbackEnabled : True
ClientAuthenticationMethods : ClientSecretPostAuthentication, ClientSecretBasicAuthentication, PrivateKeyJWTBearerAuthentication, WindowsIntegratedAuthentication
Please tell me if there is a way to reinstall the AAD client on the local client completely? Or do an automatic full reset on the client computer?
Get-AdfsEndpoint | foreach {if (@("/adfs/services/trust/2005/windowstransport", "/adfs/services/trust/13/windowstransport", "/adfs/services/trust/2005/usernamemixed", "/adfs/services/trust/13/usernamemixed", "/adfs/services/trust/2005/certificatemixed", "/adfs/services/trust/13/certificatemixed") -ccontains $_.AddressPath) {Write-host $($_.Enabled) $($_.AddressPath)}}
True /adfs/services/trust/2005/windowstransport
True /adfs/services/trust/2005/certificatemixed
True /adfs/services/trust/2005/usernamemixed
True /adfs/services/trust/13/certificatemixed
True /adfs/services/trust/13/usernamemixed
True /adfs/services/trust/13/windowstransport
Please tell me if there is a way to reinstall the AAD client on the local client completely? Or do an automatic full reset on the client computer?