Before we start talking about password synchronization, I would like to make sure you're aware of SSO capability Google Apps Business has which allows you (among many other things) to login your users based on the credentials they used when they logged-in to authorization authority such as Microsoft Active Directory.
While there is a lot of information on the subject, I couldn't find a single place where you can get a clear guide on how to synchronize user account's passwords between Active Directory and Google Apps.

There is a lot of confusion out there about this specific issue and I wanted to set a clear perspective on how to achieve password synchronization in literally few hours.

You'll need a server (can be Virtual Machine too, off course) to install the Google Apps Directory Sync. While Google suggest using Windows XP or Vista, I successfully was able to use Windows 7, Windows 2003 Server, Windows 2008 Server, including the R2 edition.

Step 1

Prerequisites to complete this exercise:

  • Active Directory domain (can be based on Windows 2003, 2008 or 2008 R2 version)
  • Google Apps Business Edition (Standard Edition doesn't have API, meaning you can't run Google Apps Directory Sync)
  • Google Apps Directory Sync configured to sync user accounts between Active Directory to Google Apps (GADS)
If you never done installation and configuration of GADS, I recommend first watching excellent Barry Schmell's video tutorial.

As well you can review my post on this blog - "GADS Tips & Tricks" for more in-depth from-the-field information on configuring Google Apps Directory Sync tool. Please note that I am constantly updating this post with new information, so please bookmark this (permalink) and re-visit from time to time..

To make this approach work, you'll need to enable "store passwords using reversible encryption" for all of your users (or at least those for which you're planning to sync passwords). This can be done either manually or using Group Policies (GPO).

You can see more information on this mechanism at this excellent article. Personally, I don't think it's such a big deal as sometimes people tend to think, as most domain controllers are set behind firewalls and multiple layers of security but still you should be aware of it.

Step 2

Once you've got everything in place, you can continue to the next step. It would be setting a password filter (in a form of DLL file) on all of your domain controllers in the Active Directory forest. The purpose of password filter is to catch password's changes by users (or when administrator resets them).

You should download the filter from sha1hexfltr project of Anderson RandelYou'll see there both 32-bit and 64-bit versions. If you using Windows 2003 32-bit or 64-bit you should use sha1hexfltr.dll_32bit_win2k3 and sha1hexfltr.dll_64bit_win2k3 from Jan 2010 accordingly.

But, if you're using Windows 2008 or Windows 2008 R2, the latest version won't work. You'll need to use previous version from Oct 2009, which is completely fine. I never ran into any issue with it. If you're not planning to debug Randel's code, you can safely skip DEBUG versions ;)

To install the filter, use those instructions:

On Windows 2003/2008 32-bit based domain controllers, put the dll file (make sure you correctly renamed the file to have dll extension) into your windows\system32 directory and register the file using regedit.exe and go to: 

HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Control -> Lsa

Modify 'Notification Packages' by adding sha1hexfltr to the end of the list (Do not include the '.dll' part.)

You'll need to restart the domain controller to have the dll being loaded into the memory of your server. To test that you've did everything correctly, go to command line (cmd.exe) and write:

rundll32.exe sha1hexfltr.dll,about
You should see a popup window with "test this" message.

On Windows 2008/R2 64-bit based domain controllers, you"ll need to put the dll file (again, after you correctly renamed the file to have dll extension) into your windows\system32 and windows\SysWow64 directories and register the file using regedit.exe and go to: 

HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Control -> Lsa

Modify 'Notification Packages' by adding sha1hexfltr to the end of the list (Do not include the '.dll' part.)

Please note, certain files on 64-bit version of O/S will be "blocked" by the operating system. To unblock, please right click the file (in both system32 and SysWow64 folders), choose "Properties" and then "Unblock".

You'll need to restart the domain controller to have the dll being loaded into the memory of your server. To test that you've did everything correctly, go to command line (cmd.exe) and write:

%SystemRoot%\SysWOW64\rundll32.exe sha1hexfltr.dll,about

This is because Windows 2008/R2 64-bit have two versions of rundll32.exe and only 32-bit version is in system path, so you'll need to explicitly call 64-bit version to check the installation.

Step 3

When you're done with password filter installation, each time user changes it's password or administrator resets the password, the password filter will update division attribute of that specific user in the Active Directory with a hash of the password. A division attribute isn't used by default, thus you wont have a problem with using it.

Now, what is left is to sync division attribute with Google Apps's password (for each user) and this is being done by configuring "Extended Attributes" page (under Users section) in Google Apps Directory Sync configuration.

Click to enlarge

On the "User Password Sync" screen, select synchronize password "For new and existing users". For Password Attribute use "division" (without quotation marks). Password Encryption Method should be on "SHA1". All the rest is irrelevant for our task.

Run the synchronization task as you usually do (sync-cmd.exe) with correct configuration file (-c parameter) and in "apply mode" (-a parameter).

You should have now passwords being synched between Active Directory and Google Apps!

If something isn't perfectly clear, please don't hesitate to provide feedback using comments or by writing me to vadim AT enterprise-expert DOT com.
Posted
AuthorVadim Solovey