Okta AD Agent + AADConnect - only a problem for *provisioning*?
I've read through the Office 365 Deployment Guide (version 7). I'm unclear about the warning regarding AADConnect.
My goal is to use WS-Federation for Office 365 so that my Office 365 users will be prompted for MFA when they access O365 resources. I've got the Okta AD Agent running on two servers now and I've successfully imported the user accounts. I'm hesitant to turn off AADConnect, though, because it's allowing users to set their AD password via O365, syncing some accounts that aren't needed in Okta, etc.
I only have one domain that will exist in AD, O365, and Okta. So I'm concerned about the bolded note that says "Do not run DirSync/AADConnect and Okta for the provisioning of user accounts in the SAME domain in Office 365." Is provisioning the only piece I'd have to worry about? We rarely add new users, and when I do, the process is to add them in AD, then wait for AADConnect to sync them to O365, then purchase an O365 license and add the license to the new user. I'm fine with that process. Will I break anything else about the federation if I keep Okta AD Agent and AADConnect running simultaneously, while using the License/Roles Management Only provisioning type? BTW, I am not using Okta Universal Directory, if that matters.
The note you've identified pertains to both Okta's Office 365 user management vs AADConnect. We highly recommend using one or the other. You can still use AADConnect for user management and Okta for SSO.
So if I'm using AADConnect for "user management" -- syncing my AD users with O365 -- does that mean I don't have to run the Okta AD agent at all? Would I still be able to use WS-Federation if there's no direct communication between AD and Okta?
You would normally still make use of the AD agent so that users when authenticating to Okta perform a Del Auth back to the AD. Once they are authenticated with Okta we create the federation token and pass the user back to O365 to complete the sign in flow. Hope that clears up your question?
Yes, that makes sense. So if I'm running both AADConnect and the AD Agent to get my user accounts populated in O365 and Okta, what exactly should I *avoid* doing, in line with the recommendations from the deployment guide and Darron's statement earlier about "using one or the other?"
What Darron was saying is that you should only use one product/technique to provision users from AD to the Azure AD used by Offdice 365. You can either use AADConnect to synch users directly from AD to Azure AD, or use the Okta AD Agent to synch users from AD to Okta and then use Okta provisioning to push users from Okta to the Azure AD (to perform the same function) but you cannot use both otherwise they will compete.
You should with whatever method chosen continue to use the Okta AD Agent for two things, 1) for synching users from AD to Okta and 2) for authenticating users to Okta (which in turn can provide the federated authentication to O365). Hope that provides the clarification?
Yes. So when I come to the provisioning piece of setting up the Okta-O365 integration, should I set provisioning as Disabled or should I enable it -- and if I enable it, which option should I choose? NOTE: There is a discrepancy between the PDF version of the deployment guide and the HTML version. The PDF version, on or about p. 28, describes some options that I don't see in the HTML version. This could explain why I'm getting confused -- I've been following the PDF version.