Sync Active Directory Password with Google Apps working
I started a long journey of setting up google apps for an organization and found out the hard way that when you synchronize accounts using googles apps directory sync tool (GADS). http://www.google.com/support/a/bin/answer.py?answer=106368
That passwords, are not synced. The full reason for this is explained at the end of this article. It’s long whinded and there be dragons.
For a short summary, here is what is required.
1. Secure the Division attribute: By default this field is visible to ANY authenticated user, this means you have put all passwords into unsalted SHA1 hashes and any user with the knowhow could poll for the entire domains userbase and get all their passwords. Again understanding why this is bad is explained at the end of this article.
2. sha1hexfltr – this DLL is installed on all writeable domain controllers (DC’s), it captures/intercepts any password resets AFTER it is installed and makes a SHA1 hash of the password and puts it in the division attribute field. This is accessible from LDAP, this makes it ideal because LDAP is how the Google Apps sync tool gets all its info to the Google servers.
3. Sync account creation: It may seem obvious but some people make some glaring mistakes about this part of the process and are just so happy it is working, they forget to finish off an important part of this process.
1. Secure the division attribute so people can’t crawl it
I used to try and do this by attempting to lock down the division attribute. This, as it turns out is not possible to do (or if it is, it isn’t easy).
so the new approach for this is found here: http://angrytechnician.wordpress.com/2011/05/04/securing-your-google-apps-sha1-password-hashes/#
2. Install DLL on domain controllers (write DC, not on read only RODC)
download link here
Installation procedure for 2008 R2 64bit/32bit
Downloaded older Oct 2009 64bit dll for 2008 (the one that doesn’t specify win2k3)
2 - Copy the file to the ‘Windows/System32’ directory.
Why you don’t need to put anything in the syswow64 directory
It’s for 32bit apps running on a 64bit architecture, irrelevant when you have the 64bit DLL
3 - Register the filter
• Click Start -> Run
• type ‘regedit’ -> click ‘OK’
• 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. )
• Reboot for the filter to take effect.
Was able to run before and after the reboot, handy to run before in case you are like me and running on automatic, don’t check a servers architecture and copy/install the 64bit DLL on a 32bit server.
in a command window and it responded “test this” hooray.
Note: sometimes windows can lock these downloaded files, you may need to right click -> properties and unlock the file so it isn’t prevented from being readable.
Why can’t I just use LDAP synchronizing in realtime like my VPN appliance etc.
LDAP is not supported in this manner with google, due to the distributed nature of their setup. This is not feasible, they must hold copies of passwords as you will not all hit the same server and may change servers at any time. They probably hold your mail on tens if not hundreds of servers worldwide at once, how are you supposed to get authentication working in that type of distributed nature from your one little LDAP server? Let alone creating a massive single point of failure for your setup, googles 99.99% uptime goes out the window if your LDAP server can’t talk to their systems and all of a sudden no-one can logon to see their mail.
Why cant Googles apps tool just get my passwords out of active directory?
You cannot retrieve your passwords because Active Directory (in its current iteration) stores passwords as an LM hash and an NT hash and stores them in the Security Accounts Manager (SAM).
If you are reading this, find out it is on for your system and want to disable it. You should read this article, http://support.microsoft.com/kb/299656 you can prevent LM storing from happening at all.
This goes a long way to you being a better admin and securing your network against attacks. These are the kinds of things that separate the systems that earn Microsoft the name of being unsecure from those that don’t. As with any system, it’s only as secure as the person administering it. Be aware that legacy systems can be affected by this so be very sure this will not break functionality, (that is what your test domain that everyone has is for right? right?)
What not to do
Don’t have an admin account that can be removed, at the least your sync tool has two options. When a user is dropped from AD (delete the GAPPS account or suspend it) always suspend. There is a 10 day turnaround on an account that is deleted. You heard me right, go on, do it now. Go into your console, create a new user account, great, now delete it, now try to recreate it. Oh that error message is not fun when you thought you would just delete and recreate a user to save the headache of something that would have taken you 10 minutes to resolve.
This could be CATASTROPHIC to your environment if you get this wrong.
Make sure that the account is well labeled and all admins are well aware of the impacts of moving or doing anything to this account.
If admin account gets suspended
to request a reset, doesn’t require you to be able to send email which you may have broken.
Password resets are set to go to an alternative in the google apps cpanel, make that something you can access easily. I just created a free gmail account called firstname.lastname@example.org
- DO NOT turn on “store passwords using reversible encryption”
Here is why
Someone happily discussing how easily this allows you to export all passwords as clear text.
I also discovered an article talking about the initial setup with screenshots if you are having trouble getting that far through this process. http://sgoodger.wordpress.com/2010/04/14/google-apps-directory-sync-and-ad-passwords/#comment-162