Overview: Hybrid scenarios allow enterprise users to seamlessly interact between SP Online and SP on-prem instances, provide search across on-prem and online sites, access data on-prem. while using Office365/SP Online, use Office 365 apps like Flow, Video, Graph and utilise OneDrive. Picking the right authentication allows users to have a seamless high-value experience bringing together secure access quickly. Pretty important and to make this happen you need to deal with access.
Organisations have internal authentication mechanisms such as Microsoft's Active Directory. Large organisations have a tough time migrating to the cloud and with the rapid changes in Security and the cloud this post aims to broadly define paths or options for architects such as myself to follow.
Options 1. Do nothing.
The 1st option is to ignore the cloud but I am going to presume you want to take advantage of Office 365.
Options 2. Only use the cloud/O365.
Office 365 is huge and for a small or new business, I would strongly look at only using O365 using Azure AD (AAD) credentials. This means no or little management of Active Directory (AD) and you can pretty much connect to the whole Microsoft SaaS offering quickly. Most large SaaS offering can work with Microsoft AAD. Generally, this option is not suitable for large enterprises.
Option 3. Internal AD and externally use Office 365 Azure AD.
Easy to implement as the internal and external credentials do not link. Your users do not get a single sign-on (SSO) experience. Users use the Azure AD credentials when working with Office 365 and your internal credentials when working on the internal network. The user needs two accounts and to know when to use them.
Option 4. Internal AD synchronized and creates similar accounts on Azure AD.
Pretty much the same option as option 3 but the usernames appear to be the same to the end users. There are a few variations in this space, you can simply create the accounts with the same name either manually, using a CSV import or using Directory Sync (DirSync). At this stage, the passwords and accounts are managed separately, the DirSync reduces effort and provisions and removes accounts in Azure AD to match the companies on-prem. AD. DirSync will reach the end of support in April 2017.
Option 5. Internal AD automatically syncronises with Azure AD including password sync.
You still have 2 accounts but the accounts on both sides are kept aligned using DirSync and password synchronization. The same password is stored both in your on-prem. AD and in Microsoft's Azure AD for each user. The advantage here is that the user name and password for a user is the same if using internal or external applications secured by on-prem. AD or AAD. This is not SSO enabled, the user needs to login to both AD's separately.
Option 6. Azure Active Directory Connect.
Similar to option 5 but the Azure AD Connect tooling does all the synchronization of accounts between on-prem. AD and AAD. This option/method is easier than option 5 and the latest approach but fundamentally it is the same approach with 2 identical accounts for each user.
Note: Only 1 AAD Connect per AAD B2C tenant. If you have multiple AD's (e.g. AD forest), you use a single instance of AAD connect to grab each AD's objects.
Note: AAD Connect can write back properties to AD on-prem. but it can't create objects/account.
Note: AAD Connect can selectively grab accounts e.g. exclude some OU's.
Note: Default replication is every 30 minutes, but he pswd hash syncs every 2 min, you can config Azure password rest to push back to on-prem. AD if you use password hash sync.
Options 7. Federate (ADFS)
When accessing SharePoint Online, you go to AAD as each SPO has it's own AAD. On AAD you may have ADFS, partners Ping Federation service, other organisations AAD to actually authenticate the user. So the login experience needs to know where to authenticate the user. To do this use MS and you can also build custom HRD. When the user enters the username or email, they are forwarded onto the appropriate ADFS or Federation service to authenticate the user.
Ariel Gordon describes HRD at Microsoft below:
Organisations have internal authentication mechanisms such as Microsoft's Active Directory. Large organisations have a tough time migrating to the cloud and with the rapid changes in Security and the cloud this post aims to broadly define paths or options for architects such as myself to follow.
Options 1. Do nothing.
The 1st option is to ignore the cloud but I am going to presume you want to take advantage of Office 365.
Options 2. Only use the cloud/O365.
Office 365 is huge and for a small or new business, I would strongly look at only using O365 using Azure AD (AAD) credentials. This means no or little management of Active Directory (AD) and you can pretty much connect to the whole Microsoft SaaS offering quickly. Most large SaaS offering can work with Microsoft AAD. Generally, this option is not suitable for large enterprises.
Option 3. Internal AD and externally use Office 365 Azure AD.
Easy to implement as the internal and external credentials do not link. Your users do not get a single sign-on (SSO) experience. Users use the Azure AD credentials when working with Office 365 and your internal credentials when working on the internal network. The user needs two accounts and to know when to use them.
Option 4. Internal AD synchronized and creates similar accounts on Azure AD.
Pretty much the same option as option 3 but the usernames appear to be the same to the end users. There are a few variations in this space, you can simply create the accounts with the same name either manually, using a CSV import or using Directory Sync (DirSync). At this stage, the passwords and accounts are managed separately, the DirSync reduces effort and provisions and removes accounts in Azure AD to match the companies on-prem. AD. DirSync will reach the end of support in April 2017.
Option 5. Internal AD automatically syncronises with Azure AD including password sync.
You still have 2 accounts but the accounts on both sides are kept aligned using DirSync and password synchronization. The same password is stored both in your on-prem. AD and in Microsoft's Azure AD for each user. The advantage here is that the user name and password for a user is the same if using internal or external applications secured by on-prem. AD or AAD. This is not SSO enabled, the user needs to login to both AD's separately.
Option 6. Azure Active Directory Connect.
Similar to option 5 but the Azure AD Connect tooling does all the synchronization of accounts between on-prem. AD and AAD. This option/method is easier than option 5 and the latest approach but fundamentally it is the same approach with 2 identical accounts for each user.
Note: Only 1 AAD Connect per AAD B2C tenant. If you have multiple AD's (e.g. AD forest), you use a single instance of AAD connect to grab each AD's objects.
Note: AAD Connect can write back properties to AD on-prem. but it can't create objects/account.
Note: AAD Connect can selectively grab accounts e.g. exclude some OU's.
Note: Default replication is every 30 minutes, but he pswd hash syncs every 2 min, you can config Azure password rest to push back to on-prem. AD if you use password hash sync.
Options 7. Federate (ADFS)
Active Directory Federation Service (ADFS) provides an Identify Provider and can pass claims based authentication between a trusted Identity Provider. This post does not explain passive Identity authentication but this is the more advanced option. There are a lot of federation services but ADFS tends to be the most common (ThinkTexture, Ping, SiteMinder).
Home Realm Discovery (HRD)
When accessing SharePoint Online, you go to AAD as each SPO has it's own AAD. On AAD you may have ADFS, partners Ping Federation service, other organisations AAD to actually authenticate the user. So the login experience needs to know where to authenticate the user. To do this use MS and you can also build custom HRD. When the user enters the username or email, they are forwarded onto the appropriate ADFS or Federation service to authenticate the user.
Ariel Gordon describes HRD at Microsoft below:
"How does Home Realm Discovery work?
In the cases above, apps direct users to Azure AD's common endpoint, and Azure AD shows a generic sign-in page. This page waits for users to enter their username then, as soon as the focus moves away from the username field, it makes a server call to look up the configuration for the user's domain. In case of a federated domain, the login page then initiates a redirect to the federation server, such as ADFS. Users then enter their credentials on the federation server's own login page which displays their organization's branding.
When we introduced Company Branding last year, we mimicked this UX behaviour: the Azure AD sign-in page starts off with generic branding then looks up the organization's branding elements after the server call is made. In both cases (federation and company branding) the goal is to ensure that users enter their credentials on a page that reflects their organization's brand.
When does it make sense to bypass Home Realm Discovery?
If your application targets users in a single organization, there's no need to use Azure AD's Home Realm Discovery and you can "accelerate" users to their organization's sign-in page. To do this, your application needs to pass a domain hint to Azure AD, effectively stating "I've already established that the user who's about to sign in is from <this organization>."
When Azure AD receives such a hint, it performs Home Realm Discovery on the domain name hint before rendering a single pixel. If the domain is federated, Azure AD immediately redirects users to the federation server. If the domain is managed, it checks whether Company Branding has been configured for the domain and displays it when found."
