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.
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 [email protected] -ImmutableId "ci2LdGtw+EKLJYL9hzOGDw=="
Make sure the UPN on your user account (on your AD domain side) matches the [email protected] 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.
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.
