Google Apps, AD and SSO

Question

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?

Solution 1

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.

Solution 2

Here is a password filter that stores the hash in ad. http://code.google.com/p/sha1hexfltr/ It securely saves the hashes in ad. No SSO needed, No new servers needed!

Solution 3

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.

Solution 4

You can use LemonLDAP::NG to do that. See http://lemonldap-ng.org/documentation/latest/applications/googleapps

Solution 5

Hmm, nobody does the SSO thing? I confess I'm a little surprised!

Just to get things rolling: I've had PingConnect suggested via other channels. Anyone used it?

View more solutions

Comments

[l0c0b0x]

We're doing this, but I'm not entirely up and up on the whole process. You'll have to wait until Monday so I can ask one of our programmers.

[Chris_K]

@l0c0b0x: I'm all ears :-)

[l0c0b0x]

Read Zoreache's answer :)

[Corey]

serverfault.com/questions/15898/…

[Chris_K]

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? Maybe I'm beginning to see why this is isn't as common...

[Zoredache]

Your comment about the Google SAML service isn't accurate (2nd para). SAML allows you to have a service on your local network do the authentication. Your AD would be the the authoritative source for authorization. What you are supposed to do is run the directory sync and the SAML integration in parallel, they aren't very useful separate.

[Frank]

Great, thank you for the correction. After your comment, I searched some more, and found this nice overview of the SAML authentication flow code.google.com/apis/apps/sso/… .

[Chris_K]

Thanks for the edit and the additional info. I have much to ponder now.

[Zoredache]

Google released a new password sync product called Google Apps Password Sync (GAPS) that should now handle this.