Setting up Microsoft ADFS3.0 with Google GSuite is a bit of a black art as the process is not documented in detail by either party and although there's not a great deal to do from the Google side, setting up the ADFS claim can be tricky.
This is where the community comes in. A super blog post from iCutsman takes you through the process step by step.
https://icutsman.wordpress.com/2016/08/06/googleappsandadfs/
One feature not mentioned in this very detailed post is the ability to filter the SSO action based on networks.
From the Google admin console it's possible to define networks for with SSO will be active based on the CIDR notation. A client accessing the logon page from an identified network will be presented with the SSO screen, otherwise the standard Google logon is presented.
One feature not mentioned in this very detailed post is the ability to filter the SSO action based on networks.
From the Google admin console it's possible to define networks for with SSO will be active based on the CIDR notation. A client accessing the logon page from an identified network will be presented with the SSO screen, otherwise the standard Google logon is presented.
For instance, in the example above 10.0.0.0/8 would identify your internal network as using the address range 10.0.0.0 to 10.255.255.255. Clients attempting to logon to Google from devices within this range will be handed off to the 3rd party identity provider, in this case Microsoft ADFS, all other users get the Google logon.
The default situation has no network defined.
In this situation, if you restrict the ADFS service to the 10.0.0.0/8 network the effect will be that users will only be able to logon to Google when internal to your company or organisation.
No comments:
Post a Comment