Google Apps: The Whole Kit and Caboodle

Bethel's Information Services will be presenting the experiences with moving to Google Apps, sign-up for NCCE 2012 in Seattle, WA and check out the session. I will be a co-presenter at this session for the technical aspect.

Google Apps has become the "Whole Kit and Caboodle" for Bethel Schools. In 2010, BSD left its current communications platform for Google Apps. Belly up to the bar and hear the tale of our decision making process, planned transition/implementation, provided support/training, and achieved results (expected and otherwise).

Google Apps: The Whole Kit and Caboodle

NCCE 2012


Google Password Sync: Windows Server 2008

Alright! Finally, I sat down and decided to find out what the issues people were having with running the GoogleHashUpdater in Windows Server 2008.

My Current Test Setup: 
Windows Server 2008 R2 64bit 
Hashing Password Filter RC4 64bit
Google Data API <--- Very Important!!!

1) You need to create an attribute field to house the password hash for the user
2) The password filter needs to be installed on all Domain controllers, but can be installed on one to test with.
3) Complex passwords need to be enabled in the Group Policy

  • Download the filter (see above)
  • Download the Google Data APII (see above)
  • Install the Google Data API on each domain controller
  • Copy the following files from the Google Data API installation folder "C:\Program Files (x86)" to "C:\Windows" of each domain controller:
    • Google.GData.Apps.dll
    • Google.GData.Client.dll
    • Google.GData.Extensions.dll
  • Create the attribute “hashedPassword” (type: Case Sensitive String) with AD Schema Editor
  • You need to create a x500 OID also. Use this tool to figure out and OID ( )
    • Copy the script
    • Open Notepad, Paste
    • Save as oid.vbs
    • Run oid.vbs
    • Prompt gives base OID, and explains adding a number for a attribute
  • Once the attribute is created copy “HashingPasswordFilter.dll” into C:\Windows
  • Import the registry key, “HashingPasswordFilter.reg”
  • Enable Logging for Debugging
    • HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Fusion
      • DWORD "EnableLog" = 1
  • You will also need a user to update the users in AD, we already had a user we used for our scripts, but you need Allow log on locally and log on as a batch job.
  • Edit ini file with login information, copy to “C:\ProgramData”, make sure it is readable only by administrators
  • Copy “GoogleHashUpdater.exe” to the process path specified in “HashingPasswordFilter.ini”
  • Edit Group Policy under password policies to make sure Complex Passwords are enabled (this is required)
  • Reboot Controller.
  • You can confirm the install worked by Checking the log file “C:\ProgramData\HashingPasswordFilter.log”
  • Also, you can check System Information to make sure the module is loaded.
  • You can open command prompt and run "GoogleHashUpdater.exe" to confirm it's working. If it crashes, make sure you have Logging Enabled. Once you tell it to close program it will spit out an error of what is missing or erroring.
Once a user changes their password it will update the “hashedPassword” attribute for that user. Also the GoogleHashUpdater should go update the user too. (We aren’t using that yet, a few bugs still with that)
Currently we are syncing passwords nightly, users login via Single Sign-on (CAS by Jasig) so passwords aren’t too important at the moment, only for IMAP and Mobile Syncing.

Install on all Domain Controllers or it won’t work properly.

I hope this helps those who have been contacting me. I'm glad the solution was an easy fix. Let me know if you have anymore questions.