Using in-house software/scripts to login to Office 365 post federation. Skip to main content
https://support.okta.com/help/answers?id=9062a000000quouqac&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Nick ReidNick Reid 

Using in-house software/scripts to login to Office 365 post federation.

We have in house software that is logging in to Office 365 with both IMAP and EWS. After I set Okta to do the authentication for Office 365 will these logins still be supported? I will also want to ensure there is no MFA challenge for these specific logins, can I put the user in a group that is excluded.
Best Answer chosen by Nick Reid
Chris LauretanoChris Lauretano
Typically with these sort of non-human accounts, you'd set the login ID (userprincipalname) to be on a non-federated domain, like @[yourcompany].onmicrosoft.com (this default domain can't be federated). Since the federation configuration is per-domain, enabling federation for the [yourcompany].com domain will only redirect users signing in with email addresses in that domain to Okta.

Things like service accounts, resource mailboxes, and third party apps that integrate with email (like your help desk, bug tracking, etc systems do) can all be handled in this way. You'll have to reconfigure the client-side or communicate to users to change the username to the non-federated domain. This doesn't have to impact the primary email address for the account, that can continue to be in the domain you federate.

All Answers

Chris LauretanoChris Lauretano
Typically with these sort of non-human accounts, you'd set the login ID (userprincipalname) to be on a non-federated domain, like @[yourcompany].onmicrosoft.com (this default domain can't be federated). Since the federation configuration is per-domain, enabling federation for the [yourcompany].com domain will only redirect users signing in with email addresses in that domain to Okta.

Things like service accounts, resource mailboxes, and third party apps that integrate with email (like your help desk, bug tracking, etc systems do) can all be handled in this way. You'll have to reconfigure the client-side or communicate to users to change the username to the non-federated domain. This doesn't have to impact the primary email address for the account, that can continue to be in the domain you federate.
This was selected as the best answer
Nick ReidNick Reid
Hi Chris,

Thanks for the useful advice. I will make sure i'm using the internal tenant logins for these accounts before I federate to Okta. I have done a little bit of testing with some of our scripts and it looks like things such as powershell's send-mailmessage will still work using federate domain names in the username used to login. 

thanks 
Nick
Nick ReidNick Reid
After doing some more testing it looks like you don't actually need to use the internal tenant domain for non-human logins. With programmatic access to Okta you can just use the federated domain.This was true for Secure_IMAP, and EWS.