Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, August 5, 2016 4:22 PM | 1 vote
Hi, I want to test Hello for Business with 1607. There's a wonderful guide for certificate based authentication available: https://blogs.technet.microsoft.com/mobilityguys/2016/07/18/enterprise-mobility-end-to-end-part-4-enable-byod-and-passport-for-work/
But I want it to work with the key based (TPM) technique. I can't find any step-by-step guide. Tried on my own and failed: I am able to set a pin for work (Hybrid AD, ADFS, DCs 2012/2016 mixed) but I am not able to logon with it (Error like "not possible in the Moment, try later...")
Regards, Michael
All replies (24)
Thursday, October 27, 2016 4:40 PM âś…Answered | 6 votes
We had the same problem, and I just managed to find the solution.
The documentation on this is really, really bad, but it seems that the public key is written to the Azure AD computer object when you go through the Hello for Business wizard. This key needs to be synced back to the on premise AD for the authentication process to work, which is something that Azure AD Connect is supposed to handle. The problem (in our case) was that we installed AD Connect long before the new 2016 DC, and so it didn't know about and didn't sync the necessary attribute back on prem when it did the device writeback. (The attribute name is msDS-KeyCredentialLink)
Open up Azure AD Connect admin tool, select "Refresh directory schema" and go through the wizard. Let it sync and verify that the device writeback works, and that the msDS-KeyCredentialLink attribute is populated on the relevant msDS-Device in the RegisteredDevices folder.
That fixed it for us!
Monday, August 8, 2016 2:07 AM
Hi Michael,
At first, have your check this documentation? If not, have a look to see if can give you some prompt
Manage identity verification using Windows Hello for Business
In addition, please understand build 1607 is released recently, as far as I know, some users have tested that TPM function exists a problem on decryption, Microsoft engineers have been working on it now. So there is a possibility that TPM function appears issue on Windows Hello login either, you can feed back this condition to Microsoft by built-in Feedback app.
Sincere regards
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Monday, August 8, 2016 4:56 AM
Sure, I know the documentation by heart, and tried to get the Feature running since 5 months or so.
There's a prerequisite table at https://technet.microsoft.com/en-us/itpro/windows/keep-secure/implement-microsoft-passport-in-your-organization but it does not state HOW to configure the Systems.
I have I complete AD Connect/ADFS/AAD/AD Environment running, including Domain Controllers on 2016 and 2012 R2. Both have DC Certificates from an internal PKI. So everything required in the table should be there. In Addition I have configured the new GPO "Hello for Business" as enabled. Without the policy I am not able to klick on the PIN Settings (which is against the documentation).
It seems like someone has changed the prerequsite table, because now it cites (available with the production release of WS 2016). So does this actually mean the Feature is not working in TP5? On the other side, certificate based Pins DO work, as written in the beginning of my thread, so the Header of the table does not differentiate that.
Regards, Michael
Thursday, August 18, 2016 10:15 AM
We have not heard from you in a couple of days. Please post back at your convenience if we can assist further.
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, August 18, 2016 10:34 AM
? How strange, I replied on 08.08. - no answer from MS...
Wednesday, September 21, 2016 7:17 AM
Sorry for late reply, have you check the function on the latest build 14393.187?
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Monday, September 26, 2016 4:51 AM
Yes, I did update the DC and Windows 10 to 14393.187, nothing changed - still not possible to Login with PIN. When creating the pin in Windows 10 it works, but I think it does not complete, as the message says it will be done in Background and I should continue to work.
Thursday, October 27, 2016 4:53 AM
Still no update on this? Seems that nobody in the world has a clue how to get Key based Setup up and running? Helloooooooo
MS wants to get rid off Passwords. But with such effort this will simply not happen...
Thursday, October 27, 2016 4:51 PM
Whooo horray! It works!! Frederik, that was the missing point!
When you think about it it's clear, and many people will have the same problem because they installed ADConnect on an 2012 R2 machine. It's self updating but not the Schema.
Thank you again Frederik!
@MS: Time to hurry up on docs!
Regards, Michael
Friday, November 4, 2016 8:42 PM
Thanks for finding this! There is no mention about this requirement anywhere else.
Friday, November 11, 2016 8:04 PM
Can someone clarify if ADFS is required? The implementing passport guide does not state ADFS as a requirement however, part 4 in the end-to-end guide states otherwise. Currently we have several 2016 DCs, AD Subscription and AD Connect. I Have ADCS installed and providing User and Computer certificates. I have enabled the GPO for Hello for Business and when I log in, I get the prompt to set my PIN. It goes through the process; however I am never able use a PIN (not even given as an option on the logon screen). I updated the Schema as mentioned as I had Azure Connect prior to all of this (2012 servers). The same article mentions device writeback but that is a Premium AD (we are using Office 365).
RegisteredDevices folder is blank but each computer in AD has the msDS-KeyCredentialLink attribute. Also review the event logs (User Device Registration). From start to finish I have 9 entries. From requesting a token, obtaining one, a NGC container being created (with a userID), followed by a Password sent be saved and the last one stating the key was successfully registered with Azure AD. I looked on Azure and under devices and my PC is listed. That said, I have two entries that appear to be errors (although they are marked as informational).
"The Web Proxy Autodiscovery Protocol (WPAD) did NOT locate the URL of a configuration file using DHCP and/or DNS discovery methods. The request will be sent directly to the server. WINHTTP_STATUS_CALLBACK dwInternetStatus is 2097152 WINHTTP_ASYNC_RESULT dwResult is 6 WINHTTP_ASYNC_RESULT dwError is Unknown Win32 Error code: 0x2f94"
"Unable to lookup Local Security Authority (LSA) authentication package. Package name: CloudAP. Error: The implementation is not capable of performing the request."
Per Part 4, I should have an Event ID 100 through 105, which I do not have. Mine starts at 323,325,108,109,203,336,214,350, and end at 300.
Totally banging my head on this one. Documentation is very lacking as others mentioned. They seem to make this seem easy to implement. Not so much :) Hopefully someone will be able to provide me with some details.
Oh yeah, ran the dsregcmd status. AzureADJoin is Yes, EnterpriseJoin is No. There is DeviceID and Thumbprint. IDP is login.windows.net TPMprotected is Yes. KeySignTest Passed. I can send screenshots of anything necessary to solve this. Thanks in advance.
Saturday, November 12, 2016 11:30 AM
As far as I can see, ADFS is not required as there's no SSO Action involved. AD Connect with Password sync should do it. There will be a latency as Lutz mentions. Start an AD-AAD sync with Start-Adsyncsynccycle after PIN creation.
But the article from Lutz has 2 Errors: 1st it's not the AAD Join Feature you have to activate, it's the device Registration Feature. 2nd, he forgets to mention that you have to activate the Device Writeback Feature in AD Connect. https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-feature-device-writeback/
That's the reason your Attributes are empty, and: it's NOT the Computer account gettings that attribute, it's the Device Registration record!
So my tip is to try Hello for Business with Key based Setup as I can't see a real value of cert-based Setup, except it's a LOT of more work and potential Errors coming with it.
With Keybased only, the steps are identical to Lutz' article, just ommit the Client certificates and all the NDES stuff. BUT: It's important that your DCs get trusted Computer certificates from your internal PKI that the Clients must trust also!
I work with that Feature productive since 2 weeks now and it seems that it's not 100% compatible with Direct Access, sometimes logon with Pin is not possible. And SSO with O365 seems also sometimes not working, browser based Access to OWA sometimes asks for passwords. This does not happen when logged on with a Password.
Also important: You MUST update your AD Connect Schema regardless of the history of your Domain Controllers and AD Connect Installation date. It's even needed in a completly new 2016 Domain and fresh tenant!
At the end it feels like a beta feature.
That's the counterside of DevOps.
Regards, Michael
Saturday, November 12, 2016 2:44 PM
Correct me if I am wrong. Does not device write back require a premium AD Azure account? You also mention the DC's needing the certificates. That might be the problem as right now I am only deploying the certificates to the workstations via GPO. Are the certificates just server certificates or are they different? I can create another GPO to push those to the DCs. the process I used to setup ADCS is strictly based off of the MVA videos on setting up a basic PKI environment. Thanks again for any assistance.
Saturday, November 12, 2016 3:30 PM
Yes you just need DC certificates, normally if you install an Enterprise PKI DCs will automatically enroll for a Domain Controller template type certificate. That's enough for Hello for Business.
Device Writeback is a AAD Premium Feature, but I am not 100% sure it's required (I can only say that the msDS-KeyCredentialLink is necessary and it's an Attribute in the registered device object AND the user object) . Last week I implemented HFB in an Workshop with Device Writeback, so I know it's working that way I discribed.
Regards Michael
BTW: Read your way through Jairo's blog: https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/
This is the best source of the inner workings of HFB.
Saturday, November 12, 2016 3:52 PM
Yes. Installed an enterprise PKI. Built a RootCA then a SubOrdinateCA. I'll have to look and see if the DCs have a certificate. Gotta be something I am missing since it does not work. :/
Monday, November 14, 2016 8:09 PM
Verified that all of my domain controllers had certificates including the "Domain Controller Authentication" certificate and "Kerberos Authentication". Still unable to get this to implement. Can someone verify rather or not this requires Azure AD Premium over that of the Office 365 Azure AD? I know writeback requires Premium.
Tuesday, November 15, 2016 5:43 AM
Why don't you try it? I described the steps already. Just order a EMS Trial subscription in Office Portal at no costs.
Regards, Michael
Wednesday, December 28, 2016 11:31 AM
After working on the same problem as you all did with the key based implementation I ran into the following blog which pretty much wraps it all up :-)
http://www.itgeekrambling.co.uk/windows-10-windows-hello-for-business-key-based-configuration/
By following this post I got it to work in three hours. This included the setup of a reference PKI environment for the distribution of the kerberos certs. This does, however, assumes a managed domain not federated.
Regards,
Thorwald
Thorwald van Elburg
Wednesday, December 28, 2016 1:58 PM
Thanks Thorwald. Unfortunately, I already followed this article and still no such luck. It simply refuses to work. I am starting to think this may not work with a SLD (Single Level Domain); although I have not been able to get that confirmed. I receive the PIN dialog and can go through the process of setting up a PIN, all the way to the "We'll be ready soon" dialog. Where things go astray is that in the event logs (User Device Registration), I only receive two events in the 100s (108 and 109). The rest are in the 300s (214,312,323,325,352,336,302, 350 and 352).
I tried with and without a AD Premium subscription. I attempted to setup device writeback, which per Microsoft is not necessary, however device writeback does appear to not work with SLD domains (per Microsoft). They have not yet confirm or denied if SLD is the problem with Hello 4 Business.
Next year (2017) looks like I am going to be forced to change the domain. With having a Hybrid Exchange environment, that just seems even more messy than with Exchange OnPremise; and lets face it, that was not pretty either.
Tuesday, January 10, 2017 5:47 PM
Wondering if anyone has found additional information on setting this up. I still have not been able to get this working on our network. I opened a ticket with MS as Device Writeback was not working but later was told that it was not necessary for this feature to be implemented. Since then, I confirmed that when the computer is joined via Azure AD, the PIN works as intended. It is only when the computer is part of our local domain which has AzureAD configured; that it does not work. The PIN dialog appears and I can go through the wizard. The computer is listed in AzureAD but shows as inactive.
Thanks.
Tuesday, January 24, 2017 2:08 PM
Hello, I am worked on thoose technologies from last year, I am experiencing with AD FS, SSO, Conditional Access and Multi Factor Authentication, I can confirm that Device Writeback is required, if you want to enable Conditional Access based on domain joined policy. Related to PIN, it seems the same scenario, with WIN 2016 AD FS we can enable features that support Windows Hello for Business.
Tuesday, January 24, 2017 2:16 PM
I can understand the need for Device writeback for conditional access; however that is not what I am attempting to use. It is pretty pathetic when Microsoft themselves cannot verify what is required and what is not. One tech from Microsoft states that it is needed another says otherwise. There is so much of this miscommunication and misguidance when it comes to MS.
Wednesday, May 3, 2017 3:07 PM
I've tried with and without device writeback, with and without AD Premium account and no change. I believe it may be due to our ADCS also having the NDES roll installed, I saw something that said NOT to install that roll and the itgreekreambling page also excludes this roll in his set up. unfortunately I can't turn that roll off in our environment, so now i'll try an inTune trial
Friday, February 14, 2020 3:02 PM
This post is a gem. Thank you so much for this clear explanation. One interesting bit in my experience was that I was still able to unlock apps with Windows Hello (e.g. 1Password) without the msDS-KeyCredentialLink populated/synced. It was only the Windows logon that was failing. I don't know why that would be different, but I'm happy to have it all working now.