Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


Office 365 – Login with Local Domain Credentials – No Need for ADFS

Post Author: Joe D365 |


A few weeks ago, Microsoft released a new version of DirSync. For those of you don't know, Dirsync is a tool that enables you to easily sync your Active Directory users and changes to Azure Active Directory.

The biggest change that we saw in this new version is password synchronization. With the newest version of the Dirsync software installed, you are now able to sync password hashes from your local Active Directory to the cloud, thus enabling users to login with corporatelocal domain credentials without the need for an ADFS server. The best part is that if you have installed and set up Dirsync already, there is just one more box to click to enable password synchronization.

Office 365 Single Sign-On - No ADFS

The password synchronization feature works by sending a hashed value of passwords from your local domain out to the Azure Active Directory environment. A couple key notes about this new feature:

  • Plain text passwords are NOT synchronized
  • Reversible-encryption is NOT required in your local active directory
  • No schema changes are required in your local active directory.

What does this mean? It means this is very secure.

The benefits of this new solution from Microsoft are twofold:

  1. Smaller companies that run a few servers are able to run the Dirsync application anywhere in their environment, EXCLUDING the domain controller. This eliminates the associated costs of a separate Active Directory Federated Services (ADFS) server.
  2. There is cost and time savings realized by your IT department avoiding patching, maintenance, and troubleshooting of an ADFS server.

We tested and successfully implemented the solution. In the test, we used two Windows Azure virtual machines running Windows Server 2012 – one domain controller and one server to run DirSync – and a new Office 365 trial account.

DirSync's standard sync interval is three hours, but you can run manual syncs or even change the sync interval.

Manual Sync:

Start-OnlineCoexistenceSync

Change sync interval:

Navigate to:
C: Program FilesMicrosoft Online Directory SyncMicrosoft.Online.DirSync.Scheduler.exe.Config
Edit the tag

The values in this tag follow the format hours : minutes : seconds. Also note that the synchronization process can take some time depending on how much information needs to be synced.

When passwords are changed in the local Active Directory, we were able to use the new password to log in to Office 365 within 30-60 seconds.

We also explored what happens when accounts are deleted. After DirSync is enabled, any account that is deleted within Active Directory will be deleted in the Online Service Portal after the next directory synchronization. If you try to re-create the account in Active Directory after this, there will be a new account in Office 365, and the account will not be mapped back to the old account in the cloud. Accounts created within AD cannot be deleted on the cloud side, but you still assign and remove licensing for the online dashboard.

Looking for more nitty-gritty details on this solution? Checkout this recently published TechNet article:

http://technet.microsoft.com/en-us/library/dn246918.aspx

Still have questions? See if they are answered in this wiki:

http://social.technet.microsoft.com/wiki/contents/articles/17370.best-practices-for-deploying-and-managing-the-windows-azure-active-directory-sync-tool.aspx

Need help configuring DirSync? Just give a call and we'll be glad to help.

Happy CRM'ing!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

10 comments on “Office 365 – Login with Local Domain Credentials – No Need for ADFS”

  1. This doesn't sound like true SSO, even the MS article you linked at the end makes a point of saying this isn't SSO, just a way to keep both sets of usernames/passwords the same. Still seems like the only way to avoid getting prompted for login credentials for individual Office 365 components is to use ADFS. Is this true?

    1. Hi Todd - Correct. We are still prompted for a user name and password. So SSO in the sense we have a single user and single password 🙂 For truly automated SSO without any prompts we then need ADFS. There are a few other things that are gained by having ADFS too.....

      1. ADFS is a much better solution, but does add complexity. I like the fact you can the login pages to give a bit of branding to user experience.

  2. This isn't SSO at all. It's password synchronization. SSO has a very specific meaning in IAM. Password synch is not SSO.

  3. Your are right and Wrong.
    DirSync with Password Sync is a SSO too.
    But the difference between ADFS and DirSync is that ADFS is a "Single Sign On" (SSO), and DirSync is a "Same Signe On" (SSO).
    In the first case with ADFS you only need to open your Windows session to acces to all your ressources without having to reauthentificate again, in the second case, you will have to reauthentificate to acces to the other ressource after opening your Windows session, but using the same ID (user and pass).

  4. Single Sign-on (SSO) is a property of access control of multiple related, but independent software systems.If the federated application isn’t properly designed, it will accept the cached version of the token used in the previous session and continue operating just like someone never logged out.http://www.gluu.org/

  5. We have local ADs at our four office locations with same local
    domain names. Could you please guide us if we can link all these local
    ADs which have the same domain names to our office365.

    In addition, will the SSO work if the user is not connected to the office local LAN.

    1. Hi Rocky - Yes - you can have different local ad domains such as abc.com, def.com and have these domains be part of your office 365 tenant. You do need to 'validate' the dns for all domains used. As for SSO, the user does NOT need to be part of your local lan in order to authenticate. If you are replicating the password hash, a user can login to o365 using corporate credentials and NOT be in your local lan.

PowerObjects Recommends