format for user names used by office 365 apps

Or even SMTP accounts that can send mail on behalf of the organization. Especially for backup accounts which often have full access to read all data in a tenant (and many people are setting this up with Global admin rather than something more restrictive). Almost everyone who is attaching to Office 365 services is doing so with basic authentication (which does not support MFA)–so it’s just a straight username and password.Īnd that sucks. Please note that instructions for configuring this registration will vary by application, so it is best to find out if your vendor supports this setup and follow their documentation carefully from there.īut here’s the problem: hardly any applications or devices out there on the market today support the App registration / OAuth consent method. Here is one example for reference, from an app called LionGard Roar, which I have configured to ingest certain data from Office 365.

So if you’re working with a modern app that supports OAuth, then you can just take this route, and follow their guidance for setting it all up. Azure AD admin center > Azure AD > App registrations Now, some apps and services out there have modernized their approach to this problem, and if they need to integrate with Office 365, they will have you setup an App registration, and use OAuth to grant consent so that the app can do what it needs to do, without using a password to sign-in.

Common examples include some type of copier/scanner device that sends mail from an account like Or, a backup account that needs to access the environment to read data out–placing a copy of mailboxes and/or files in some third party’s cloud location. Service accounts are accounts that do not have an actual “person” behind them–usually they represent some kind of device or application that needs to perform specific tasks in your Office 365 tenant. But… what about service accounts? The service account problem

Format for user names used by office 365 apps