Azure AD Connect vs Okta provisioning for Office 365 Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
OktaRSA AgentOktaRSA Agent 

Azure AD Connect vs Okta provisioning for Office 365

I know that there have been ongoing changes to the provisioning capabilities of Okta with Office 365. At this point in time, are there any limitations that still exist with using Okta for provisioning with Office 365 that do not exist when using Azure AD Connect?

I'm not sure if it changes the answer, but we are currently using an Office 365 Hybrid deployment.
Marc JordanMarc Jordan (Okta, Inc.)
Hi Peter,

Thanks for the great question.

We recently started an EA program that enhances Okta's provisioning capabilities for Office 365 by significantly extending the number of attributes (up to 140+) and adding support for Contacts, DL's and some other Exchange specific objects. For many customers, these enhancements provide enough fidelity to match and overtake AzureAD Connect (formerly DirSync) in terms of functionality.

Exchange Hybrid configurations (specifically) are not yet supported through Okta provisioning, however this is something we are working hard to address. There are some gaps today in our handling of proprietry exchange data when involved in a hybrid configuration, this also involves writing proprietry attributes back to on-premises. 

I'd love to hear a little more about your Hybrid configuration though if you're happy to share.
  • Is this a permanent configuration for your Exchange organization or are you currently in a migration state?
  • If your Exhange Organization will remain in Hybrid permanently, what use case has made that a requirement?
OktaRSA AgentOktaRSA Agent

I'm not familiar with the specifics, but I was told that we require on-prem mailboxes for our phone system. I'm going to see if I can get more specific information.

Out of curiosity, do you know why the writeback to on-prem is necessary? Does it have something to do with breaking the syncing of attributes, or is there something outside of the Office 365 environment that needs those attributes to be in AD?
Marc JordanMarc Jordan (Okta, Inc.)
Thanks for digging in on the specifics Peter,

If you scroll to the bottom of Microsoft list the reasons they need some specific attributes written back. In particular, things like ProxyAddresses when you have a mix of on-prem and online mailboxes is really quite important. 

Without fully supporting some of this functionality, we run the risk that certain routine functions that happen with mail routing, mailbox moves and other Exchange related features might not work as expected.
Rafael JaimeRafael Jaime
I am interested in knowing if the hybrid issues have been worked out yet by OKTA
Enrico MeierEnrico Meier
In a non-hybrid, Okta is a bit of a hassle and not very reliable. Attribute syncs like ProyAddress that worked one tiem stopped workign for no apparent reason and for weeks no solution/clue from support on how to solve it. I'd recommend to closely compare of AD connect. IF this keeps going, we might look into going back to AD connect. Also ADAL only works with AD connect and not with Okta or other providers, if that is important for you.
Graham CondonGraham Condon
The way we have it setup (3000 employee company) is using AAD connect for writing users and attributes to Azure (which writes to office) then we have Okta do all the license provisioning. This is where Okta REALLY shines in my opinion. Okta's abilties for license assignment is LIGHTYEARS ahead of Azure. I love that I can set a group and the license set I want them to have and its done, unlike Azure that cannot even see subgroups, everything has to be flat groups for Azure automations. Also, dont even try to use OUs for rules in Azure, it cannot see those either.