There are a couple things you can do with Google Apps.
You can setup a SAML server connected to your AD network and then setup Google to authentication your Google Apps access against the SAML server. We have used a php application called simpleSAMLphp because we already have servers setup to run PHP and we have developers with php skills. The drawback of using a SAML solution alone is that you can only login to accounts through the web. This means you can't access your mailbox through imap/pop, and you can't login to Google talk with any old XMPP client.
Using SAML does not automatically create accounts in the Google Apps domain. You also will probably need a tool that will synchronize accounts for that you can use the Google Apps Directory sync tool. This will allow you to create accounts, but it still will not sync passwords by default because the Windows Password hashes are not reversible and Google can't do anything with them.
It is possible to use something like PasswdHk to intercept password changes in your AD and then store the password in a format (unsalted sha1) that the Google directory sync utility can use to set the Google Apps passwords. But this does add a bit of security risk since Google will only accept unsalted md5 or sha1 password hashes through its Provisioning API, and to sync with Google, you basically must store these hashes. If you are to use this, it is very important to keep these hashes secure.
Hmmph. You had me all excited about
SAML until the bit about imap/pop.
That'd kill all the folks using
windows mobile and blackberry clients,
wouldn't it? Any clever alternatives
there?
If you are willing to accept the risk of storing the password hashes then are able to combine the SSO and the directory syncing together to get a working system.
As an alternative someone could develop a Intranet portal where users in your domain would go to initialize their Google account and set the password for the Google account. I had considered developing something like this, but couldn't get my coworkers to agree that it was the way to go.
The basic idea is this, build a webapp that
- Lives on your intranet and authenticates against your active directory
- Has a function that will take the username and password that the user used to login to the intranet site and get any other information you need from the AD, and then use the Google Provisioning API to add/update the users account.
Building the tool really shouldn't be too difficult, I had estimated to hack out something basic it would only take 12-16 hours of development time. The advantage of this solution is that it gives you 100% Google Apps functionality, the downside is that it somewhat inconveniences the end-user.
This is pretty simple...
If your public DNS host provides forwarding you can simply create the base A record and have it forward to portal.microsoftonline.com.
If you don't have this ability just setup a simple new website on your public facing web servers or even proxy servers that hosts that domain name. Once you have that you can setup the IIS Rewrite Module to redirect requests to the Microsoft portal and it should do what you want.
We did this as well to provide a "customized" URL for users to access, not to mention any laptops could store the URL and it would work internally and externally, just with different authentication mechanisms.
Sample Rewrite:
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<YOUR FEDERATION SERVER>&wreply=https:%2f%2foutlook.com%2fowa%2foffice365.com%2f?exsvurl=1&ll-cc=en-US
Best Answer
I wrote a script that changed all ImmutableIDs on AzureAD to match their primary email at GSuite.
I don't think it's elegant but GSuite's SAML configuration only allows sending primary email, first name, or last name as the NameID field.
As long as NameID == ImmutableID everything works.