<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008C3jVBSAZOkta Classic EngineOkta Integration NetworkAnswered2024-04-16T11:44:03.000Z2018-01-18T11:28:56.000Z2018-08-12T04:14:12.000Z

gdis0 (gdis0) asked a question.

January 18, 2018 at 11:28 AM
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.
  • 3 answers
  • 919 views

  • 0ts2h (0ts2h)

    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.
    Expand Post
    Selected as Best

  • 0ts2h (0ts2h)

    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.
    Expand Post
    Selected as Best

  • gdis0 (gdis0)

    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
    Expand Post

  • gdis0 (gdis0)

    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.
This question is closed.
Loading
Using in-house software/scripts to login to Office 365 post federation.