One of the benefits of Windows 10 devices that are registered with Azure AD is the convenience and security that comes with Windows Hello and Microsoft Passport for Work. In this post I’ll delve into the technology of Microsoft Passport for Work with Azure AD and how it relates to devices and strong user authentication.
Microsoft Passport for Work is supported on all three types of devices registered with Azure AD to authenticate to work apps. In this post I will focus primarily on Azure AD joined and domain joined devices.
Quick note on personal devices
For Windows personal devices running the November 2015 update, Microsoft Passport for Work is limited to protecting certificates for traditional apps (like VPN) with the associated user’s gesture that unlocks the credential (read further in this post for details). These certificates are deployed typically by the Mobile Device Management (MDM) system.
The Microsoft Passport for Work provisioning experience won’t show up during Add Work or School Account unless an MDM has been configured in Azure AD for auto-enrollment. In this case, a user working on the device won’t authenticate to Azure AD using the Microsoft Passport for Work credential. A future update of Windows will have this support.
On the other hand, the credential in a Windows 10 device (including personal devices), can be used to remotely authenticate to an Azure AD joined or domain joined device. For more information please look for a future post about Microsoft Passport for Work 2Go: using your phone to authenticate to Windows.
Passwords today
There is a problem today with passwords. They are easy to clone and easy to steal. Issues in their implementation make them insecure, and users have a hard time balancing convenience and security. Users typically find “workarounds” to make their life easier when facing security requirements (e.g. a complex password may end up being written in some unsecure location).
Microsoft Passport for Work replaces user passwords with strong device-bound user credentials protected by a user’s gesture (a PIN or a biometric gesture like fingerprint or facial recognition i.e. Windows Hello).
For more details on the problems of passwords please see Problems with traditional credentials section in the Microsoft Passport guide we recently published in TechNet.
The Microsoft Passport for Work credential
The credential is an asymmetric key (private-public key pair) with their private key stored securely in the device in the Trusted Platform Module (TPM), and its corresponding public key securely registered with Azure AD. In the absence of a TPM the keys are software generated and stored encrypted.
The private key does not leave its secure location (if TPM available), it is not known to Azure AD or AD and it never goes into the network. It is only accessible by a gesture that the user knows (a PIN) or the user “is” (bio-gesture) which protects the key cryptographically by encrypting it using a “Hello”. A Hello is an authenticator which is unique to the gesture, the device and the user.
The public key is registered securely with Azure AD after both the device and the user have authenticated. The user must strongly authenticate by providing a second factor of authentication. This is important because the Microsoft Passport for Work credential is considered a strong credential when authenticating to Azure AD. The credential meets multi-factor authentication (MFA) policy and tokens obtained with this credential will have a corresponding related claim.
Once the credential is provisioned, it is used for authentication to Azure AD.
Provisioning the Microsoft Passport for Work credential
All starts with a device becoming registered with Azure AD. A device needs to be Azure AD joined, domain joined (which has auto-registered with Azure AD) or configured with Add Work or School Account before holding a Microsoft Passport for Work credential.
After an Azure AD joined or domain joined device has completed registration, on the next user sign-in to Windows the Microsoft Passport for Work provisioning experience will show up. Registration of the public key with Azure AD happens through the Azure Device Registration Service (Azure DRS).
This experience is a web driven experience rendered in the Cloud eXperience Host (CXH), a special host with access to particular WinRT APIs in the system. This is the same host that is used to render the experience for Azure AD Join.
The experience is launched after the user signs in to Windows if the following conditions are true:
- Microsoft Passport for Work policy signals provisioning. This means either of the following conditions:
- The device is Azure AD joined and Microsoft Passport for Work policy is not disabled (read it: in the absence of the policy being set the default behavior is to provision the credential).
- The device is domain joined and policy is enabled (read it: in the absence of the policy being set the default behavior is to NOT provision the credential). This is because there is preparation needed in the on-premises infrastructure for a domain joined device to be able to authenticate to a domain controller (DC) using the credential. After the required setup is made, the org. can enable the policy. I’ll mention some considerations about supporting AD on-premises authentication later in the post.
- The current session is not a remote session. Note that this doesn’t mean that Microsoft Passport Provisioning for Work won’t happen on virtual machines (VMs), but just that the provisioning experience won’t show up if the user is connected to the VM or physical device via a Remote Desktop Services (RDS) session (which includes connecting to the computer using Hyper-V Enhanced Session Mode, so you know in case you want to try this in your lab on a Hyper-V host).
Once the conditions listed above are met the user will see the provisioning experience. The experience is hosted in the following location:
https://account.live.com/aadngc
The user will see the following page:
Once the user clicks on the ‘Create PIN’ button a WinRT API part of dsreg.dll is called. This registration API performs two operations: 1) authenticates the current user to get a token to Azure DRS, and 2) generates the key pair and registers the public key with Azure DRS using the token obtained in (1).
(1) Authentication of user to Azure DRS
The registration API will first obtain an access token to register with Azure AD the public key that is about to be generated. The token is intended to Azure DRS which registers the public key with the corresponding user and relates it to the corresponding device object. To obtain the token, the API uses the Web Account Manager API:
Windows.Security.Authentication.Web.Core.RequestTokenForWindowAsync
This API invokes the corresponding implementation for the Azure AD plug-in. For more information on the Web Account Manager and its Azure AD plug-in please look for a future post about How SSO works in Windows 10.
Users will see an MFA challenge depending on some conditions:
- Users on domain joined devices will see an MFA prompt. This is using username and password credentials. Please note that the November 2015 update of Windows 10 doesn’t support Microsoft Passport for Work provisioning if the user has signed into Windows using a physical or virtual smart-card. We will add this support in a future update of Windows.
- Users on Azure AD joined devices will NOT see an MFA prompt if the user joined the device in the first place and provided MFA at the time of join (the attribute ‘RegisteredOwners’ on the device object holds this user). Azure AD will treat the device as a second factor of authentication if the device was registered with MFA for the user who joined it. Please note that this is current service behavior as of the publishing date of this post. We have received mixed feedback about regarding registered devices as MFA. In the future we may allow it under a setting that organizations can control.
- Users on Azure AD joined devices who did not join the device will see an MFA prompt.
For a federated organization the MFA challenge can come from Azure AD or from their internal STS (e.g. AD FS):
After the user authenticates and the API obtains the token, it then proceeds to generate and register the Microsoft Passport for Work keys.
(2) Microsoft Passport for Work keys generation and registration with Azure AD
The registration API relies on the Microsoft Passport crypto API (part of ncrypt.dll) to generate the key and to obtain attestation data if available. Please note that the current implementation of the client and service doesn’t support attestation validation yet. We will enable this functionality in a future update of the service and/or Windows.
The keys are generally not created at this moment but obtained from a pool of keys previously generated. Pre-generation of multiple keys happens upon boot of the device and occurs in the background. Given that these are RSA 2048 bit key pairs, depending on the TPM these may take some time to generate.
After the key pair is obtained, the PIN collection UI shows up and the user is asked for a PIN. A logical container is created and the private key is placed in it:
A container is a logical grouping of key material protected by a protector key which is associated with a gesture. In this case the PIN is associated with a protector key that is obtained at this time. This key securely wraps the Microsoft Passport for Work private key recently obtained. The PIN gesture is the one that can “open” the container and allow access to the key.
About key attestation
As I mentioned above, attestation validation is not yet implemented, however let me provide details on some of the mechanics behind attestation generation. Along with the corresponding public key, its related attestation data, if available, is also obtained using the crypto API. The attestation data consists of the Attestation Identity Key (AIK) certificate and a blob holding information about the user and the Microsoft Passport for Work key generated. The blob is signed by the AIK which is a special purpose RSA key that allows the TPM to offer platform authentication. The AIK in conjunction with the Endorsement Key (EK) and its certificate (from the manufacturer) is sent to Azure Certificate Services to generate the AIK certificate which has a trust that chains up to the TPM manufacturer. This trust chain is what the service will validate upon key registration.
The registration API will now take the Azure DRS access token and the key information and post it to Azure DRS to the following end-point:
POST http://enterpriseregistration.windows.net/EnrollmentService/Key
Azure DRS will find the user object in the directory and add the key information to a particular multi-valued attribute. The key information will contain a reference to the device ID (both user and device IDs are obtained from the token). A user object will have one key for every device where the user has provisioned a Microsoft Passport for Work credential.
About the user’s devices UI in the Azure management portal
One more thing that may be of interest. The UI in the Azure management portal that shows devices for a given user includes devices that the user has registered in a self-service manner (via Azure AD Join or Add Work or School Account). Windows 10 domain joined devices won’t show up given that no user participates in the registration of the device with Azure AD… except, if the user has provisioned a Microsoft Passport for Work credential, the domain joined device will show up in the UI under the user’s devices.
Authentication using the Microsoft Passport for Work credential
Finally after the credential has been provisioned it can be used to authenticate to Azure AD and to AD on-premises upon sign-in to Windows. For details on how this is accomplished please look for a future post on How SSO works in Windows 10.
Authentication to AD on-premises
In terms of the support of Microsoft Passport for Work authentication against AD on-premises, the device needs to be able to reach a DC running Windows Server 2016 (as of the date of this post it is in Technical Preview 4). There is no need to have a new Domain or Forest Functional Level in the on-premises AD.
As an alternative to deploying new DCs, logon certificates using the Microsoft Passport for Work key can be deployed. In this case down-level DCs will use the certificate for authentication (as it is today with virtual smart-cards) and users will enjoy the benefits of Windows Hello. Please note that in this case Azure AD will continue using the key for authentication.
To support logon certificates using the Microsoft Passport for Work key, it is required to have System Center Configuration Manager Technical Preview (domain joined devices) or Intune (Azure AD joined devices) (additional 3rd party MDMs may have this support as well).
For more details on deployment requirements to enable authentication to on-premises AD please see section Deployment requirements in the Microsoft Passport guide in TechNet. Please also refer to related TechNet documentation here for more resources.
Once again, thanks for reading this far and being interested in these features. Please let me know your questions or comments you have.
Until next time,
Jairo Cadena (Twitter: @JairoC_AzureAD)
Devices, Security and Identity in #Microsoft365 by Jairo Cadena 
Pingback: Azure Update (2016.03.10) | ブチザッキ
hello Jairo,
thank you for this blog, it’s a great resource! A little unrelated, but I cannot find an explanation anywhere: do you know why Windows 10 devices are not getting any device claims from AD FS? In our implementation we are using Azure DRS writing back devices to onprem. I can do conditional access for Windows 7/8 and iOS devices with AD FS 2012 R2, but there are no device claims issued to Windows 10 devices. Thank you!
LikeLike
Hi JJ, the way authentication in Windows 10 works against Azure AD or AD FS is different from Windows 7 and 8.1. In short, if you want to do device authentication on-prem at the AD FS you will need AD FS of Windows Server 2016 (today in TP4). Device auth in Windows 7 and 8.1 relies on client TLS to proof the device identity based on the device certificate placed in the user store at the moment of registration. Windows 10 relies on a new Authentication Provider component (similar to the Kerberos AP but for the cloud) to obtain an SSO token (Primary Refresh Token or PRT) from Azure AD (or AD FS in WS2016). This PRT contains the device ID. This component has access to the device certificate which in Windows 10 is placed in the machine store (not user store). Another component called the Web Account Manager which brokers authentication across applications and browser within the user’s signed in session, has access to the PRT which in turn provides the device identity to Azure AD and AD FS of WS2016 during authentication. I’ll have a post soon that describes in detail how this works behind the scenes.
LikeLike
great, thank you! Looking forward to your next post! 🙂
LikeLike
To add to JJ statement…
I see device claims being issued to Windows 10 devices if I use the “add work or school account”, effectively when workplace joining the device. If I do Azure AD join or Domain Join + AAD Join I don’t get any device claims. Is this the expected behavior?
From what I see, when we do workplace join we still provision a cert in the user certificate store. When we use either AADJ or AD+AADJ the cert is provisioned in the computer store.
These inconsistencies make configuration of access policies a nightmare and I hope you will have a better story with redstone…
LikeLike
Hi Clark, the expected behavior is that in all three cases, Domain Join and Azure AD Join for work-devices and Add Work or School Account for personal devices, device claims should be issued in tokens when users in those devices authenticate to Azure AD apps.
In the case of a work device, Azure AD Join and Domain Join, the registration is machine wide for any work user on that device. This is why the certificate is placed in the machine store. In the case of a personal device where the user does Add Work or School Account (marked as Workplace Joined) it is only that user in the device who has that registration. This is why the certificate is in the user store. Other users in that device will appear to Azure AD as coming from a non-registered device. The new components in Windows 10 have access to the certificate for authentication in each case.
In the cases you see authentication failing you can check the current state of the device by running ‘dsregcmd.exe /status’ in a Command Prompt window. You will see two sections, one ‘Device state’ and one ‘User state’. Under the device section check the value of AzureAdJoined which it has to be YES for a registered device. You can also check the tenant information and the domain information where the device is joined to. Under the user section you will see the authentication state. You can check the value of WamDefaultSet which needs to be YES before you can get SSO. This means that the user in the device authenticated successfully with Azure AD when signing in to the device. You can also check WamDefaultAuthority to show ‘organizations’ and the WamDefaultGUID to show AzureAd in parenthesis.
If you want me to take a look at some case in particular that is failing please contact me via email and we can take a look together.
LikeLike
Thank you Jairo,
it makes sense now.
LikeLike
I am Azure AD joining some Windows 10 devices but none of them is prompting for the PIN.
I didn’t disable Passport for Work (I don’t know where that setting would be in the Azure portal). Based on your statement: “in the absence of the policy being set the default behavior is to provision the credential”, I would expect to be prompted for the PIN in an ADJ scenario. Did I miss something?
LikeLike
Hi Clark, are you doing Azure AD Join from Settings or from OOBE? Microsoft Passport for Work provisioning happens upon sign-in of the user. If you are running it from Settings, the provisioning experience will show only until you sign-out and sign-in with you work account.
You can also try running dsregcmd.exe /status and check the values under User State in particular for WamDefaultAuthoriy, WamDefaultId and WamDefaultGUID which should point to ‘organizations’, ‘https://login.microsoft.com’ and ‘ (AzureAd)’.
LikeLiked by 1 person
I believe the problem is that we have integration with Intune and I don’t control that portion of the infrastructure.
LikeLike
I see. Yes, the experience won’t show on Azure AD Join if Intune has pushed down the policy to disable Microsoft Passport for Work. This policy will come down upon enrollment before user sign-in happens, effectively skipping the provisioning experience.
LikeLike
Hello Jairo,
Does Azure AD is aware about my device’s capabilities in terms of authentication when I want to register it (fingerprint reader, RealSense camera…) ?
Thanks
LikeLike
Hi Todd,
Azure AD doesn’t know about the device capabilities at the time of credential registration. What Azure AD will know with attestation is whether the private key has been hardware generated or not, but not about the gesture that protects it.
Now, having said that, we have worked with Windows Hello vendors to meet a minimum security bar for Windows Hello biometric modalities. We have published this information at https://msdn.microsoft.com/en-us/library/windows/hardware/mt587095(v=vs.85).aspx.
I will be interested in hearing from you (and others) if you have a specific use case in mind or a scenario that you would like to see enabled. We have entertained the idea of allowing admins to choose what a “valid” gesture is to provision the credential. We have our ears open to know if this is something critical for us to enable.
LikeLike
Hi Jairo!
Thanks for the great post and for the other great posts before this one!
I’m having a little trouble getting this to work and I cannot find any information on why it behaves as it does.
In my lab environment i have setup the Windows 10 device registration feature and the registrations seems to work fine. Store for Business work fine and SSO to other MS (like portal.office.com) also works fine.
But when i try to logon using in this case PIN i get an message saying “That option is temporarily unavailable, please use a different method to sign in”.
I have tried all domain combinations (at least it feels like that) :).
First before I knew that I need a WS2016 TP DC i just had a WS 2012R2 domain controller. Then i installed a WS2016 TP 5 and made it a DC. This changed the message i got at first from “There are currently no logon servern available to service the logon request” to the one i’m getting now.
I then demoted the WS2012R2 DC and made the WS2016 TP 5 the only DC, without any success.
Lastly I raised the Domain Functional Level to Windows Server Technical Preview, still without any better results.
Do you have any suggestions on what might be wrong?
Best Regards,
Tommy Herman
LikeLike
Hi Tommy, have you deployed Azure AD Connect? AAD Connect will bring back the MS Passport for Work public keys that are registered in user object in Azure AD back to on-prem for the DC to consume. If you have please send me an email to jairoc at microsoft.com and we can take a look.
LikeLiked by 1 person
@tommy: We had the same issue. You’ll need to make sure that your TP5 DCs have a Kerb Auth cert from your ePKI. Here’s the closest KB explaining this: https://technet.microsoft.com/en-us/library/mt732271.aspx
LikeLiked by 1 person
@Aaron: Great, thank you. I hade totally forgot about this thread. I went on vacation and cleared my memory 🙂 We postponed the integration at our customer until Server 2016 was released. I will test this out in my lab environment.
@Jairo: Sorry for not responding to you anwser, but my vacation got in the way 🙂
We have AAD Connect installed, but maybe Aarons solution will be the last piece in this issue.
Best Regards,
Tommy Herman
LikeLike
Hi, did this get resolved as I am hitting the same message “That option is temporarily unavailable, please use a different method to sign in”.
Everything looks ok as far as dsregcmd goes. I’ve tried removing the PC from AzureAD and allowing GPO to re-enrol it. This works and I get the PIN provisioning screens, so I am sure that AAD is working as far as that goes.
My domain is a 2012R2 functional level with a Server 2016 DC installed, the schema is reporting to be 87 which I believe is Server 2016.
I’m sure I am missing something simple, I am struggling to find information on the key-based implementation of Hello for Business vs the certificate authentication using SCCM of which there seems to be lots of info out there.
LikeLike
Hi
How can we disable thee pin and thus pin creation? I want this completely turned off, cause It confuse our users.
LikeLike
Trekveer, PIN creation is enabled by default on Azure AD joined devices. It is disabled by default on domain joined. To disable PIN creation on Azure AD joined devices, if you have Microsoft Intune you can disable the Microsoft Passport for Work policy as explained in this article: https://docs.microsoft.com/en-us/intune/deploy-use/control-microsoft-passport-settings-on-devices-with-microsoft-intune.
LikeLike
Jairo, please clarify what I’m doing wrong. What I would like to accomplish is Sign-In to a domain-joined device with Windows Hello Credential in a Hybrid Setup.
What I have done so for is that
1. Enabled our Windows 10 devices(version1607) that are joined to onpremise AD to automatically join Azure AD. I can see that the device is successfully registered by running the command get-MsolDevice + dsregcmd.exe /status. I also received an warning event in User Device Registration event log that says. This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Passport provisioning will not be enabled. User: SID of my User.
2. So, I tried to make an Initial Sign-In to Windows 10 on my domain-joined machine with my Azure AD UserPrincipalName, which is kind of odd but hey it worked. Should this Work?
3. After Sign-In I’m presented with create a work account PIN which good. I completed the PIN creation steps as istructed by the wizard.
4. Signed-off Windows and thought that I can do Sign-In to Windows with Azure AD UserPrincipalName and PIN, but that options is not there on the Sign-In page.
Is this expected behaviour regarding Windows Hello for Buisness and Domain Joined machine? Please explain?
Couple of more questions
1. What are the X509CertRequeired?
2. On a domain joined Windows 10 version 1607 that is Automatic Azure AD Joined, the dsregcmd /leave doesn’t seem to work for unjoin a device. Should it? User Device registration eventlog records this after the running dsregcmd /leave This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Passport provisioning will not be enabled. User: SID.
Kind regards
Mikael
LikeLike
Mikael, you should be able to sign-in to Windows as you have done before registering the device with Azure AD. For example NETBIOSDomain\user format should work (you wouldn’t need to use the UPN for the user in Azure AD).
Now, for Windows Hello for Business to work on a domain joined computer you will need either Windows Server 2016 DCs or SCCM 1606+. With WS2016 DCs the naked key created during PIN provisioning is used for auth whereas with SCCM a new certificate wrapping that key is deployed and used for auth against DCs. This can be controlled by policy. The X509Certificate value of the dsregcmd.exe output shows the value of this policy.
In an elevated command prompt can you run dsregcmd.exe /status /debug? What do you see under TpmProtected and KeySignTest under Device State? Also what is the value of WamDefaultSet and AzureAdPrt under User State? What are the values under the Ngc Prerequisite Check section?
LikeLike
Hi Jairo.
Here is the info you requested. I really appreciate for all the help you give.
—-Device State—-
TpmProtected=YES
KeySignTest=PASSED
WamDefaultSet=NO
AzureAdPrt=NO
—-Ngc Prerequisite—-
IsUserAzureAD=NO
PolicyEnabled=YES
DeviceEligible=YES
SessionIsNotRemote=YES
X509CertRequired=NO
PreReqResult=WillNotProvision
From what I can understand under the section called Ngc Prerequisite windows will not provision Hello for Buisness Credentials at the next user sing-in?
LikeLike
Solved it!!! I found the root cause. I whant to share this with you and others + as always I have some more questions for you Jairo. 🙂
In the eventlog named AAD/Operational i recieve “AAD Cloud AP plugin call Get token returned error: 0xC000006D” each time I do sign-in. When i saw that error it got me thinking if it has something to do with the implementation of AlternateLoginID. In our onprem AD, every user account UPN value is not the same as the UPN value in AAD and we have couple of dependency’s on it. So, I performed a quick test by changing the UPN value of my user Account in onprem AD so it matches the value on my account in the cloud. After that I sign-off/sing-on and bang I was welcomed with the create PIN wizard. That’s great. After I completed the setting a pin wizard I run the dsregcmd /status it shows correct output.
NgcSet : YES
NgcKeyId : {008D1295-6A4E-4CC7-AF8D-55313538B5B7}
WorkplaceJoined : NO
WamDefaultSet : YES
WamDefaultAuthority : organizations
WamDefaultId : https://login.microsoft.com
WamDefaultGUID : {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
AzureAdPrt : YES
Like you said in the last post, to have full benefit of Windows Hello for business onprem I need to have to have couple of 2016 Domain Controllers or select the other deployment option which cert-based key. We will see what we will come up with in..
In the meantime, I have a couple of questions that I hope you can help me out with?
Where is the AzureADPrt stored on the machine?
What lifetime does AzureADPrt have?
What will the end user-Impact be if the AzureADPrt is not time valid anymore?
Is it sent as a cookie to Azure AD when trying to access an Azure AD protected resource?
Is it a JSON and what kind of data does it contain?
How will the authentication flow with Azure AD be when a PRT is in the picture? Please, also take in consideration if your tenant is federated or not?
What more tokens are involved when accessing resources? What I have learned so far is that the following tokens exists… Access-Token, Refresh-Token and the PRT Token. What’s the usecase for each of these?
Thanks
LikeLike
Mikael, I am glad you found the problem. In respect to your questions, please take a look at my just published post about How SSO works in Windows 10 here: https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/.
LikeLike
Pingback: How SSO works in Windows 10 devices | [Azure] Active Directory by Jairo Cadena
After a number of days in the world of “Windows Hello for business” I’ve now got it working using key based authentication. After struggling to find any good guides on how to implement this I’ve written one here – http://www.itgeekrambling.co.uk/windows-10-windows-hello-for-business-key-based-configuration/ – hopefully this will help people in the future.
Cheers
Rob
LikeLike
THANK YOU! I have been trying to figure this out for quite some time now. I was going by the Azure documentation which seemed to imply the only requirement was AD DS 2016 (not AD CS).
LikeLike
Pingback: (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail « Jorge's Quest For Knowledge!
Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!
“That option is temporarily unavailable, For now, please use a different method to sign in”.
I was windows enterprise version of the user, today get Authenticator, they set the pin code and fingerprints, the results of these two methods can not be used for landing, I did not find a similar online, the closest article is you this, I What should I do?
LikeLike
I’ve seen this a few times, have a read of my blog which will hopefully give you some pointers to getting your problem sorted
http://www.itgeekrambling.co.uk/windows-10-hello-business-return-option-temporarily-unavailable-message/
LikeLike
I seem to find the problem this morning, I log on the computer two accounts, corporate accounts and private accounts, private accounts for downloading app, the main landing is the company account, never used a private account login, and my fingerprint And pin code set to give a private account, not the company account. I do not know why this will be set up, but now only so, thank you very much for your answer
LikeLike
“That option is temporarily unavailable, For now, please use a different method to sign in”.I was windows enterprise version of the user, today get Authenticator, they set the pin code and fingerprints, the results of these two methods can not be used for landing, I did not find a similar online, the closest article is you this, I What should I do?
LikeLike
Pingback: Setting up Windows Hello for Business with Intune – Micro-Scott – Blogging Windows and Device Management
Pingback: Windows Hello for Business: Registration and Authentication with #AzureAD | [Azure] Active Directory by Jairo Cadena
Pingback: Setting up Windows Hello for Business with Intune – Blogging about Windows Device Management with Intune