Hi,
Hope you are doing good !
This article will help you for interview as well...
Choosing an Office 365 User Authentication Method
Authentication
With the exception of internet sites for anonymous access created with SharePoint Online, users must be authenticated when accessing Office 365 services.
· Modern authentication Modern authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML-based third-party identity providers with Office client applications, and smart card and certificate-based authentication. It also removes the need for Microsoft Outlook to use the basic authentication protocol. For more information, including the availability of modern authentication across Office applications, see How modern authentication works for Office 2013 and Office 2016 client appsand Using Office 365 modern authentication with Office clients.
Modern authentication is not turned by default for Exchange Online. To learn how to turn it on, see Enable Exchange Online for modern authentication.
· Cloud identity authentication Users with cloud identities are authenticated using traditional challenge/response. The web browser is redirected to the Office 365 sign-in service, where you type the user name and password for your work or school account. The sign-in service authenticates your credentials and generates a service token, which the web browser posts to the requested service and logs you in.
· Federated identity authenticationUsers with federated identities are authenticated using Active Directory Federation Services (AD FS) 2.0 or other Security Token Services. The web browser is redirected to the Office 365 sign-in service, where you type your corporate ID in the form a user principal name (UPN; for example,isabel@contoso.com). The sign-in service determines that you are part of a federated domain and offers to redirect you to the on-premises Federation Server for authentication. If you are logged on to the desktop (domain joined), you are authenticated (using Kerberos or NTLMv2) and the on-premises Security Token Service generates a logon token, which the web browser posts to the Office 365 sign-in service. Using the logon token, the sign-in service generates a service token that the web browser posts to the requested service and logs you in. For a list of available Security Token Services available, see Single sign-on roadmap.
Office 365 uses forms-based authentication, and authentication traffic over the network is always encrypted with TLS/SSL using port 443. Authentication traffic uses a negligible percentage of bandwidth for Office 365 services.
As an Office 365 admin, you might feel the only way to manage users (on occasions!) is with the whip. Unfortunately, that’s not allowed anymore, so you’ll have to get a bit more sophisticated with your management skills.
When users want to access Office 365, they have to be authenticated. Users in your organization will already have a username and password, most likely while using an internal Active Directory. Of course, you could create separate Office 365 user accounts for your users, but ideally you would make them “reuse” existing on-premises accounts.
I’ve put “reuse” deliberately between quotation marks, as technically speaking this is not entirely true for all possible scenarios. More about that later.
User management is very important. You don’t want the wrong users to have access to the wrong resources, or even worse, have hackers gain access to internal data by hacking user accounts. So, think carefully about authentication and authorization options when using Office 365.
Single Sign-On with Your Existing Active Directory
As mentioned above, you can make use of your existing authentication system (like Active Directory) when implementing authentication for Office 365. Before I explain the possible options, you must know that behind the scenes Office 365 uses Azure AD for authentication. Every Office 365 tenant has a separate Azure AD.
There are two possible options:
- Synchronized identities: Accounts are synchronized between Azure AD and your On-Premises directory. You can choose to sync passwords as well, or let users have a different password for both.
- Federated identities: In this model, users always authenticate against your internal directory. When signing into Office 365, users are redirected to your internally hosted identity provider, like ADFS. When signed in successfully, users are redirected to Office 365 and are logged in.
Option 2 is the preferred option and is the only option that allows for a seamless, single sign-on experience. However, Option 2 also requires additional on-premises configuration for the identity provider and is therefore the more complicated option.
Option 1 is the easiest solution to set up. In most cases, organizations begin with Option 1, and eventually move to Option 2.
Multifactor Authentication
Besides the two authentication options for identity management, the third way to manage your users is multifactor authentication.
The idea behind multifactor authentication is that a physical item is required when signing in. In most cases this will be a code sent via text or phone call, or is generated by a mobile app. When logging in with your username and password, a key generated by the multifactor device must also be entered.
In the scenario in which a hacker gains the username and password, they still cannot log in unless they have access to the user’s phone. It’s not impossible, but it makes it much harder for hackers to gain access to a user’s account.
In Office 365, you can configure multi-factoraythentication from the Office 365 Admin Center. You can choose which users you want to enable it for, and what to do if the client does not allow multifactor authentication. For example, non-browser clients like Outlook don’t support multifactor authentication yet, but by configuring a so-called app password, users can still use the application.
Office 365 multifactor authentication is based on Azure AD as explained before, and therefore also uses Azure multi-factor authentication.
When it comes to managing your Office 365 users, you have three options:
- Synchronized Identities: User accounts are synchronized between your internal directory and Azure Active Directory. Users have to login twice: once to your internal systems, and secondly to Office 365. Passwords can be synchronized between the two, so users don’t have to remember two separate passwords.
- Federated identities: There is only one user account, which in most cases will be your On-Premises directory account. When logging into Office 365, your identity provider (e.g. ADFS) will be used to authenticate a user. Single sign-on can be implemented such that users have to log-in only once.
- Multifactor authentication: After logging in successfully to Office 365, multifactor authentication requires them to enter a challenge response sent to them via text, a phone call, or generated by a mobile app. Only after entering the code, they can log into Office 365.
There is a fourth option I mentioned briefly earlier - namely, using separate Office 365 accounts, (so-called “onmicrosoft”-accounts, as the format isusername@tenant.onmicrosoft.com. This is only useful in demo purposes, or when you don’t have an internal directory, which is unlikely.
What Should YOU Choose?
As discussed, federated identities are, in most cases, the best solution, but it requires more configuration. When you initially sign up for Office 365, you may not want to do all of that right away. Beginning with synchronized identities and moving to federated identities at a future stage is a very solid approach.
Finally, multifactor authentication is a good thing, but requires users to enter a code every time they log in. You may want to restrict this to admins only however, in order to have the best balance between usability and security. Office 365 has awesome features like document management, version control, workflows, team sites, email, Lync, and more. However, if nobody uses it because of overly strict or overly complicated authentication requirements, it is useless.
Note: 