I have local AD and AD on azure and I have ADFS and ADFS proxy server setup to authenticate users on local AD. I have followed all the steps on microsoft site to setup trust between Azure AD and local AD. However it says Dir Sync is necessary in order to achieve SSO for users in local and cloud AD. I don't want to use Dir Sync and I want my ADFS to be able to authenticate users from my local AD and Azure AD as well.

Can anybody let me know the steps in order to achieve it.


Assuming this is for O365 or Intune - DirSync is a required component. DirSync will allow same sign-on, meaning the passwords are the same in both environments. Adding ADFS will allow single sign-on, meaning users will seamlessly authenticate without being prompted for credentials. DirSync is a foundational component for both same sign-on and single sign-on.

You can't do single sign-on to an Azure AD tenant with ADFS alone.

  • actually MDMarra that isn't strictly true. You can use Windows Azure AD Powershell module and set the immutableID directly on objects without dirsync and still get SSO. This is what some customers using O365 without an on-premise AD (Unix/Linux based infrastructures in Universities) do. – maweeras Jan 16 '14 at 22:35

I had the same question and the comment from maweeras put me on the right track. I did a little reasearch, got it working, and here is what worked for me.

Not sure this is the "supported" solution, because they really seem to like their DirSync. However, it makes sense it's supported for the reason maweeras mentioned - namely allowing non Active Directory infrastructure to still have SSO into Office 365.

Here's what you need to do:

  • SSO enable the domain on the Office 365 side, by running the Convert-MsolDomainToFederated powershell applets. You've probably done this.

  • Create the user accounts you want to SSO enable on the Office 365 side by hand or powershell.

  • Once you've created them, you need to use the ObjectGUID on your AD account's object as their Immutable ID on the Azure side.

    I used these as reference, but I'll include the info in case these URL's disappear in the future:



  • You need to base64 encode the ObjectGUID for your user and set that. The GUID you encode should not include the brackets:

    The script here do the conversion for you: http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1

    AD Object GUID (In "Registry Format") 748b2d72-706b-42f8-8b25-82fd8733860f

    Encoded: ci2LdGtw+EKLJYL9hzOGDw==

    You set that on the account on Azure via powershell:

    Set-MsolUser -UserPrincipalName user@azuredomain.com -ImmutableId "ci2LdGtw+EKLJYL9hzOGDw=="

  • Make sure the UPN on your user account (on your AD domain side) matches the user@azuredomain.com UPN that Office 365 has on their side, or you'll get a weird error on the Azure Side. I think the error code is 8004786C

  • If you don't have the UPN suffix available to set on your user in your AD environment, you must add that suffix via "Active Directory Domains and Trusts". Or if you wanna be clever set another attribute on your AD account and have ADFS send that attribute over as the immutable ID. If you don't know what I mean - then just set the UPN. :)

  • The Microsoft Office 365 will not show up as an option in an ADFS IDP initiated drop down menu on your server. Looks like it's SP initiated and you must trigger the SAML dance by going to their portal first:https://portal.microsoftonline.com

  • You can use something like Fiddler to grab the SSL conversation and then parse out some information http://community.office365.com/en-us/wikis/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx in order to have more of an IDP initiated feel, where the user clicks on your link and routes all the way through into a nice smooth login to Office 365 without entering anything.

  • Why do you want to go through these gyrations, anyway? – Evan Anderson Jan 27 '14 at 23:08
  • Probably not for everyone. But in our case we just wanted to test SSO for a small subset of users and we didn't wanna dedicate a machine to running DirSync. – Matt Feb 4 '14 at 18:39
  • Seems reasonable. DirSync will run on a non-dedicated machine (and a DC, at that). I do admire your ingenuity for coming up with a way to do this on the "bare metal" of the Azure AD w/ the MSOL Powershell module. – Evan Anderson Feb 4 '14 at 20:37

Does this help at all? http://technet.microsoft.com/en-us/library/dn296436.aspx

It has been a while since I have done what you are asking, but that was in my notes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.