Google Apps, AD and SSO

We're a small shop running Google Apps (Enterprise) for our email needs. Love it. Internally, we're using Windows AD (2003). No complaints there either.

I'd like to get some method of SSO going between AD and Google Apps such that AD is the only place my folks have to manage (and periodically CHANGE!) passwords.

I've looked over google's "tfm"s in the past, but I guess I just don't quite get it. Has anyone does this? If so, would you be willing to share how? Can it be done without a huge amount of complexity and expense?

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.

I too would love to see a better answer to this one.

I played around with Google Apps Directory Sync to sync Google users from Active Directory users. It looked swell, right up to the point where I read that AD's LDAP implementation keeps the password in a encrypted binary field, which Google's Sync tool cannot access.

Google's other SSO solution seems to turn the tables, so that Google is the authoritative source of credentials. We're not interested in that; what would happen on our LAN if our Internet access is down?

So right now my best solution is a Google Apps spreadsheet with user names & passwords, which we then export to CSV, and bulk import to Google Apps. This does not handle password changes. So far the best we have is to educate our users to change both the Google & Windows password to the same new password when Windows password policy forces a change.