The last couple of days I’m working on a issue with a customer related to joining Windows 10 workstations to AzureAD. This customer is using Dell Hardware and Windows 10 1703 (Creator’s Update) and a federated Azure AD with Intune MDM. When the failing workstations have installed Windows 10 and the user tries to add the device to AzureAD the user cannot login to ADFS. In the OOBE stage of the deployment the user enters his username and based on that it’s redirected tot the customers ADFS environment. The login form of ADFS loads and after entering the users credentials the login page returns. So the user stays in the ADFS login page (looping). Both on the Windows 10 client and the ADFS environment no errors are logged in the event logs.

So let’s summarize the scenario before the start of any investigation:

• Customer is only seeing this behavior on Dell Hardware;
• Customer is using Windows 10 1703 (Creators Update);
• Customer is using AzureAD federated with their ADFS environment ( Level 2016);
• No errors are visible in the event viewer on Windows 10 and ADFS servers;
• Issue is visible when connecting from internal (directly ADFS) and external (through WAP);

During the investigation of the issue we found the following extra information:

• ADFS give only his internal token and not the MicrosoftOnline token to the user which tries to login;
• We’ve tested multiple Azure AAD Tenants with ADFS environments (2012R2 and 2016), no change;
• The issue is not only visible in OOBE but in full OS mode it’s also not possible to join to AzureAD;
• On a falling workstation the user is able to logon to portals like https://portal.office.com through ADFS;
• We investigated most of the BIOS options like TPM, SecureBoot, UEFI and Trusted Execution but none of them changing the behavior;

After further investigation we found out that the time of the failing clients were out-of-sync. Most of them had an time of 10 hours in the future. The first thing we check was the time zone but the time zone on the client was exactly the same as on the working clients. We also check the time source of the Windows 10 clients when they are deployed and all are using the CMOS as their time source. So at this moment we have the following failing scenarios:

For the first scenario we’ve implemented a workaround during the deployment of Windows 10. During the deployment we’re configuring the client to synchronize his time with a NTP server and not with the CMOS. But this workaround is not working for clients which are installing Windows 10 from the Windows 10 source ISO and also this workaround is not working for scenario 2. Currently we’re working with Microsoft Support to find the Root Cause of these issues. Currently it could be Hardware, BIOS and/or Windows 10 related. Based on the outcome of this case I will update this blogpost.

For now I’m interested in if you have ever seen this behavior. If so, could you please drop me a note so we can share information about the issue and see if the issue is similar!

UPDATE 18-07-2017: After investigating this issue for some weeks it looks like we’ve found a root cause and have a working workaround and a possible fix. 🙂 We’re using SCCM te deploy Windows 10 1703 to our devices. We see that during the task sequence the system time is changed to the current time in the Pacific Time Zone (-10 hours). When full Windows boots the time difference is noted and Windows tries to sync the time with time.windows.com (over SSL). Since this kind of traffic is not allowed at the customers this fails and we have the time difference of 10 hours.

Workaround: During the Task Sequence configure NTP servers, so that the Windows 10 client can sync during the inital boot in OOBE.
Solution: Allow SSL traffic to time.widows.com for the initial time sync during the boot in OOBE. (currently this solution is tested at the customer)