Single Sign On (SSO).
In the last in a series of posts that outline a cloud based approach to managing Google G Suite and Microsoft Office365 in a multi-domain setup we take a closer look at single sign on (SSO).
Before we go into details it’s worth outlining the project objectives with respect to SSO.
The Trust uses Office365/Azure AD to deliver a unified user account database across forty schools. Each school has its own DNS domain namespace and local AD accounts are synced to Azure AD from each site using the Azure Active Directory Connect tool.
Some of the larger schools also operate Active Directory Federation Service (ADFS) onsite. This allows a user to authenticate directly with local AD and then access Office365 without being prompted for a second set of credentials.
The objective is to extend SSO from Google to Azure to support the adoption of Chromebooks and related G Suite services across all of the schools in the Trust without any reliance on local ADFS service.
Unlike user provisioning, implementing SSO in such a complex set-up can break things and make users very unhappy.
For this reason it’s important to run a small Proof-of-Concept (PoC) to test the configuration before going live on thousands of accounts. The situation is further complicated by the fact that SSO can only be turned on or off for a single Google organisation which means that testing affects every account in that domain, not just a subset of users. This is bad for one school but seriously bad if your Google organisation holds forty schools.
Fortunately the Trust had access to a G Suite organisation that was marked for deletion so this provided an ideal environment to run a PoC.
Creating the SSO object in Azure proved fairly simple. Unlike user provisioning which requires an object for each domain, SSO is covered by a single item which takes about ten minutes to configure. Once it’s built you have an ADFS instance in the cloud that’s configured to handle Google authentication requests for all your Azure AD accounts. Fortunately there’s little risk at this stage because, until the Google domain is redirected to the new service everything works as normal.
This is where the spare domain comes in useful. By setting up the G Suite PoC domain to point to the new Azure service you create a environment that can be used to prove the whole solution, including the Chromebooks if you have a few spare spare management licences.
Initially it’s worth testing using a standard Chrome browser session. Opening https://drive.google.com with a PoC organisation account should present an Azure logon page to complete the authentication. Similarly logging out and requesting a password change should direct to appropriate Azure web form.
Once you have this working you can update the Chrome device policy to pass-though the logon request to Azure. This is process is well documented by Google was well as the earlier post.
At this point the power of a cloud based federation service approach becomes apparent. The endpoint will authenticate any G Suite account against Azure if there's an matching account in the tenancy. Interestingly this even works if the school runs local ADFS. The request is accepted by Azure and then passed through to the local ADFS with Azure acting a bit like a request router.
During the PoC phase one unexpected problem emerged that's worth closer examination.
Chromebooks require Forms based Authentication (FBA) when they talk to a federation service, after all it’s the ‘form’ that provides the logon dialog box.
When connecting directly to Azure that’s not a problem but local ADFS instances can be configured to replace FBA with Windows Integrated Authentication (WIA). WIA provides a much smoother experience for internal users moving between Office 365 and local resources.
A standard ADFS configuration does not list Chrome as one the the browsers that support WIA (even though it does) so it’s fairly common for ADFS administrators to add Chrome to the list of supported User Agents so that desktop Chrome users can have the same slick WIA experience. Unfortunately this action makes a Chromebook very unhappy. After failing to respond to the WIA request it throws up a default form in order to capture the user logon information which looks and behaves in a very ugly manner.
Fortunately the fix is fairly simple. The User Agent that is added to ADFS has to be altered slightly from “Mozilla/5.0” to "Mozilla/5.0 (Windows NT”.
The second version only specifies Chrome running on Windows as having WIA support and therefore ADFS defaults to sending a form to the Chromebook and order is restored. The fix is documented in more detail in this code snippet,
Conclusion.
The Trust has been running with this configuration from the beginning of the new school year in September 2018.
The Azure tenancy and Google organisation are linked using the SSO object with all G Suite logon requests handled by Azure or routed back to the local ADFS instance. Google accounts are auto-provisioned by Azure without running Google Cloud Directory Sync on each site. The Trust is slowly developing the capability of the provisioning script to to add more intelligence into account management. Students now use Chromebooks to access the Office 365 webapps along with a number of other SaaS services.
If you're interested in trying this out yourself, so long as you have access to a test Google Organisation to allow you to make mistakes without affecting production users you can’t go far wrong. Contact me for any further information.
Lastly many thanks to Sumit Tank for handling this project with the Trust IT team and having the courage to believe that might even work.
Before we go into details it’s worth outlining the project objectives with respect to SSO.
The Trust uses Office365/Azure AD to deliver a unified user account database across forty schools. Each school has its own DNS domain namespace and local AD accounts are synced to Azure AD from each site using the Azure Active Directory Connect tool.
Some of the larger schools also operate Active Directory Federation Service (ADFS) onsite. This allows a user to authenticate directly with local AD and then access Office365 without being prompted for a second set of credentials.
The objective is to extend SSO from Google to Azure to support the adoption of Chromebooks and related G Suite services across all of the schools in the Trust without any reliance on local ADFS service.
Unlike user provisioning, implementing SSO in such a complex set-up can break things and make users very unhappy.
For this reason it’s important to run a small Proof-of-Concept (PoC) to test the configuration before going live on thousands of accounts. The situation is further complicated by the fact that SSO can only be turned on or off for a single Google organisation which means that testing affects every account in that domain, not just a subset of users. This is bad for one school but seriously bad if your Google organisation holds forty schools.
Fortunately the Trust had access to a G Suite organisation that was marked for deletion so this provided an ideal environment to run a PoC.
Creating the SSO object in Azure proved fairly simple. Unlike user provisioning which requires an object for each domain, SSO is covered by a single item which takes about ten minutes to configure. Once it’s built you have an ADFS instance in the cloud that’s configured to handle Google authentication requests for all your Azure AD accounts. Fortunately there’s little risk at this stage because, until the Google domain is redirected to the new service everything works as normal.
This is where the spare domain comes in useful. By setting up the G Suite PoC domain to point to the new Azure service you create a environment that can be used to prove the whole solution, including the Chromebooks if you have a few spare spare management licences.
Initially it’s worth testing using a standard Chrome browser session. Opening https://drive.google.com with a PoC organisation account should present an Azure logon page to complete the authentication. Similarly logging out and requesting a password change should direct to appropriate Azure web form.
Once you have this working you can update the Chrome device policy to pass-though the logon request to Azure. This is process is well documented by Google was well as the earlier post.
At this point the power of a cloud based federation service approach becomes apparent. The endpoint will authenticate any G Suite account against Azure if there's an matching account in the tenancy. Interestingly this even works if the school runs local ADFS. The request is accepted by Azure and then passed through to the local ADFS with Azure acting a bit like a request router.
During the PoC phase one unexpected problem emerged that's worth closer examination.
Chromebooks require Forms based Authentication (FBA) when they talk to a federation service, after all it’s the ‘form’ that provides the logon dialog box.
When connecting directly to Azure that’s not a problem but local ADFS instances can be configured to replace FBA with Windows Integrated Authentication (WIA). WIA provides a much smoother experience for internal users moving between Office 365 and local resources.
A standard ADFS configuration does not list Chrome as one the the browsers that support WIA (even though it does) so it’s fairly common for ADFS administrators to add Chrome to the list of supported User Agents so that desktop Chrome users can have the same slick WIA experience. Unfortunately this action makes a Chromebook very unhappy. After failing to respond to the WIA request it throws up a default form in order to capture the user logon information which looks and behaves in a very ugly manner.
Fortunately the fix is fairly simple. The User Agent that is added to ADFS has to be altered slightly from “Mozilla/5.0” to "Mozilla/5.0 (Windows NT”.
The second version only specifies Chrome running on Windows as having WIA support and therefore ADFS defaults to sending a form to the Chromebook and order is restored. The fix is documented in more detail in this code snippet,
Conclusion.
The Trust has been running with this configuration from the beginning of the new school year in September 2018.
The Azure tenancy and Google organisation are linked using the SSO object with all G Suite logon requests handled by Azure or routed back to the local ADFS instance. Google accounts are auto-provisioned by Azure without running Google Cloud Directory Sync on each site. The Trust is slowly developing the capability of the provisioning script to to add more intelligence into account management. Students now use Chromebooks to access the Office 365 webapps along with a number of other SaaS services.
If you're interested in trying this out yourself, so long as you have access to a test Google Organisation to allow you to make mistakes without affecting production users you can’t go far wrong. Contact me for any further information.
Lastly many thanks to Sumit Tank for handling this project with the Trust IT team and having the courage to believe that might even work.
No comments:
Post a Comment