Windows 10, How to do Office 365 SSO

[HCC]

Hi,

 

On a blog post back in May Microsoft alluded to the idea that you can add link Windows 10 to Office 365 and get single sign on:

Traditional PC devices, joined to an existing Active Directory domain, will have single sign-on access to cloud-based services like Office 365, the Windows Store, or any other Azure Active Directory-aware application. Windows 10 understands that the Active Directory account is associated with a synchronized Azure Active Directory account. (Device management continues to be provided using Active Directory Group Policy and System Center Configuration Manager.)

 

How do you achieve this though?

This hints that it can't be done until Server 2016, and a new System Center are released

Come on Microsoft - How is Windows 10 now enterprise ready, when you haven't released the infrastructure software needed...

 

Anyone had any success just using azure login? In the Feed#2 on page 22 it says that a Primary have done it this way. I'm just thinking that without group policy it's asking for trouble, on shared devices in a secondary like ours.

[HCC]

Hi,

Looks like they updated the info on the page in March,

 

Has anyone else tried this yet? Would it allow for the company store, and office 365 SSO without Federated AD, System Center, or Server 2016.

[Jamoire]

We have had it running on a couple of machines as a pilot, signs the user into the Store, Office 365 Sway etc automatically fine. We had it going via the Directory Sync tools rather than ADFS so it takes a little while for it to register, the only issue we found was when we rebuilt a machine and keep the old AD name it didn't seem to re-register with Azure AD so the SSO wouldn't work.

 

Haven't had chance to try and solve it though so not sure how much of a problem it is.

[Jamoire]

https://jairocadena.com/2016/01/18/how-domain-join-is-different-in-windows-10-with-azure-ad/

 

That's the information I used when setting it up if I remember correctly.

[HCC]

OK, So I ran the powershell command Initialize-ADSyncDomainJoinedComputerSync detailed here https://azure.microsoft.com/en-gb/documentation/articles/active-directory-azureadjoin-devices-group-policy/ worked out the [connector account name] is the MSOL_guid Domain User from the domain users container. I've also set the GPO to enable the workplace join.

This has created a scheduled domain join task on the Windows 10 computers, but it isn't working. There is an message which says: Task Scheduler successfully completed task "\Microsoft\Windows\Workplace Join\Automatic-Device-Join" , instance "guid" , action "%SystemRoot%\System32\dsregcmd.exe" with return code 2147942401. If I run the command dsregcmd.exe /status I can see the computer hasn't joined Azure.

 

I'm not sure how to fix this. It could be something in the Azure Portal, since it says SSO 'Not Planned' on the domain page or do I need to run any other commands on the Azure AD connect server? I'm not using ADFS, so I can't run the 'claim rules'

 

Has anyone else come across this problem and fixed it? I tried to log it with 365 support, but they said it was an azure issue, and you need premium azure to get assistance with that.

[Blue_Cookeh]

OK, So I ran the powershell command Initialize-ADSyncDomainJoinedComputerSync detailed here https://azure.microsoft.com/en-gb/documentation/articles/active-directory-azureadjoin-devices-group-policy/ worked out the [connector account name] is the MSOL_guid Domain User from the domain users container. I've also set the GPO to enable the workplace join.

This has created a scheduled domain join task on the Windows 10 computers, but it isn't working. There is an message which says: Task Scheduler successfully completed task "\Microsoft\Windows\Workplace Join\Automatic-Device-Join" , instance "guid" , action "%SystemRoot%\System32\dsregcmd.exe" with return code 2147942401. If I run the command dsregcmd.exe /status I can see the computer hasn't joined Azure.

 

I'm not sure how to fix this. It could be something in the Azure Portal, since it says SSO 'Not Planned' on the domain page or do I need to run any other commands on the Azure AD connect server? I'm not using ADFS, so I can't run the 'claim rules'

 

Has anyone else come across this problem and fixed it? I tried to log it with 365 support, but they said it was an azure issue, and you need premium azure to get assistance with that.

 

Same problem, gave up since documentation and troubleshooting was so scarce on the Internet :/

[sturgeo]

Might give this a try since we use O365 authentication for FireFly and apparently having to log in again is hugely inconvenient

[HCC]

Hi,

 

I managed to solve it.

I had a look at how the system works by creating a certificate and uploading it to AD. This got me thinking about how Azure Connect then sends the computers details to Azure. I forgot that when I first set it up as dirsync years ago, I also set up OU filtering...

The problem was that the Windows 10 computers were in a new OU that wasn't being uploaded to Azure.

I set all the W10 Computer OUs to sync using the instructions here: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnectsync-configure-filtering/#organizational-unitbased-filtering

Then I had to force a full sync using the command "Start-ADSyncSyncCycle -PolicyType initial" in powershell on the Azure connect server.

 

After a restart of a Windows 10 test computer, I can now SSO using IE or Edge for Office 365 and Firefly. yay

 

Hope this helps anyone else who gets stuck.

[sturgeo]

Are you using ADFS?

 

I've upgraded to AD Connect & ran various powershell scripts, set the GPO to enable the scheduled task, running dsregcmd /status claims the device isnt AzureAdJoined, however in the event log i can see warnings saying that the device is joined but the current logged in user isn't

 

I can see what you mean about the documentation being sparse!

[sturgeo]

Right after manually triggering the task dsregcmd /status is showing my machine as AzureAdJoined, all looks ok however all User States are no.

[CHiLL]

We are a Windows 8.1/Server 2012 domain, using ADFS and we can use SSO from our domain clients when using IE11 with no problems.

However, I have just installed Windows 10 2016 LTSB and have another client on Windows 10 2015 LTSB and SSO does not work on either. It always prompts the user for their password, despite also using IE11. The command "dsregcmd /status" shows the machine as AzureAdJoined NO.

I've checked our OU syncing, and we are only syncing the user OUs, not the workstation OUs. Do the workstation OUs need to be synced, despite it working on 8.1 without that syncing?

Edited October 13, 2016 by CHiLL

[HCC]

Hi,

 

Not using ADFS (looks a bit complex to set up and maintain), so there is a lag before the SSO first works, based on when Azure connect syncs and the policy applies.

 

As it says here https://azure.microsoft.com/en-gb/documentation/articles/active-directory-azureadjoin-devices-group-policy in the prerequisites Windows 10 build (build 10551 or newer) is needed. What is the LTSB build number?

 

Yes you need to sync the 10 workstations, this is why it didn't work for me.

[sturgeo]

I upgraded dirsync to azure AD connect and i guess its still set to using password hash, is this correct?

Not sure why it thinks im not using an Azure AD account as all accounts sync, not done anything with certificates though.

 

Azure AD portal doesn't show my internal domain at all, only my public one & the onmicrosoft one, all users login to office 365 with their email address which is username@...

 

CHiLL, try manually running the Automatic-Device-Join scheduled task, although it is set to run at logon it doesn't trigger.

[alfatec]

How do you check if your SCP is setup in Active Directory and where in Azure AD do I see the Sync'd computers?

[rictus]

We tried SSO using ADFS and found issues. Especially if for some reason the ADFS is not contactable from the outside world. Then there's no way to sign in at all!

 

Also - we wanted to avoid using the Onedrive sync app, especially for classroom computers, so this formed part of a workaround for this issue too.

 

What I've done as a workaround that we're trialling currently, is to use a GPO to cause a fixed-size I.E. window to open at logon using the user's onedrive URL (with a wildcard for the logged on users name). Once they've signed in, it remembers the credentials and on next logon, the other GPOs which map their 'homedrive' letter to their Onedrive, do folder redirection of documents to homedrive, and shortcuts to Outlook webapp and the Office365 portal all now sign straight in because that initial pop-up has saved credentials. All the relevant sites do need to be in trusted sites in IE.

 

Path to user onedrive is: \\ORGANISATION-my.sharepoint.com@SSL\DavWWWRoot\personal\%username%_ORGANISATION_COM\Documents (where if your domain is mycompany.com, replace ORGANISATION with mycompany, COM with com - you get the idea!!)