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
0 kommentar(er)
