Enterprise Software optimize

Save time: Use Google Apps with Microsoft Active Directory

Moving to Google Apps doesn't mean having to recreate user accounts. Learn how you can leverage your existing Active Directory for easy setup.

Single Sign-on (the ability to use one account across multiple connected platforms) has been a holy grail for IT administrators for years now, and some have fared better than others in achieving this prize. I worked for a large bank in the late 1990's which pursued a single sign-on project to link OS2/Novell Netware/mainframe accounts (no, we were not dodging pterodactyls at the time, though it does seem like an eon or two ago - this was back when a pager was considered high technology). Once rolled out, this was a clunky, kludgy affair which basically worked only if you held your breath, wore a purple shirt, and had a shaman casting the appropriate spells to ease the process.

Modern times

Fortunately, things have come a long way since then and LDAP (Lightweight Directory Access Protocol) has been a big factor in this evolution. It's now common to configure systems to perform LDAP lookups against directory services to permit existing users to access new environments without needing a second account, nor to have to maintain different passwords (ahem, not that many users do willingly stop using one password for everything!)

In some cases these LDAP connections are used to actually synchronize separate accounts on different platforms so they are exactly alike, including the passwords. This can cloud the definition of "Single Sign-on" from an administrative perspective (since "multiple-but-identical" and not "single" accounts are used), but from the user's point of view it meets the criteria so long as they can change passwords in one place.

Arguably, the most common and well-known directory service is Microsoft's Active Directory. When considering a Google Apps migration you should know that you can use your current Active Directory with Google systems to import your user accounts so they will be generated in your Google Apps directory, eliminating any need to recreate these accounts if you opt to move to Google Apps. This isn't a one-shot process, either: regularly scheduled synchronizations from Active Directory can keep these accounts updated in Google (for instance if properties such as a user's mobile number change). This means you can keep Active Directory in-house and still rely on Google Apps. As a control freak, I find this immensely appealing.

Not using Active Directory? Google offers a similar option for other directory platforms such as Lotus Domino, open LDAP or several other solutions.

How does it work?

Google offers a free tool called Google Apps Directory Sync. This is a program which can be installed on any system in your internal network (Windows XP/7/2003/2008, Linux or Solaris. The tool synchronizes Google Apps users with Active Directory (or other directory) users, making them exactly alike, sort of like the Guy Fawkes impersonators at the end of the film "V for Vendetta".

The process occurs as follows (Screenshots for this article provided by the Google Apps Directory Sync tutorial video.)

Figure A

The screenshot above shows the communication path between Google Apps and your LDAP server, which for Active Directory would be your domain controller.

It should go without saying that providing an outside server with direct access to your domain controller through the firewall would be an extremely bad idea from a security perspective (sort of like telling the plumber who's fixing your sink to just pay himself from the uncounted pile of money in the safe).

Installing the Directory Sync tool on a separate machine alleviates this concern; it relies upon a trusted middleman, and LDAP data is NOT stored locally on this system. As an added bonus, the Directory Sync system very likely already has the necessary network access for this to work: the ability to perform LDAP lookups against the domain controller on port 389 and to connect to Google Apps via https on port 443, so you won't need to deal with NAT setups, VPN tunnels or firewall changes.

The synchronization can be customized so that only the desired Active Directory objects (e.g. test users for a pilot rollout) are copied to Google - you can do this in a number of ways, such as by OUs, groups or custom attributes. Additionally, it is a one way process, copying objects from Active Directory to Google; any changes made to these objects needs to be performed in Active Directory.

While a two-way synchronization can seem desirable for convenience sake, the one-way option offers you protection in the event of problems with your objects. Keeping things balanced evenly across disparate environments can be tough. As someone who has lost data which was configured to synchronize between a hard drive and USB drive - and suffered havoc when the data on the USB drive got corrupted and THEN overwrote the good files on the hard drive - I can appreciate this safeguard.

What do I need to do?

The full guide outlines the step-by-step details; my goal here is to provide a high-level summary to go over the basics. For starters you must have administrator rights both in AD and your Google Apps environments. A setting in the Google Apps Control Panel called "Enable provisioning API" must be turned on. (Figure B)

Figure B

The Google Apps Directory Sync utility must be installed on a designated system in your environment. You will then need to run the Configuration Manager, which configures your synchronization options. (Figure C)

Figure C

You can set up the connection to Google Apps either directly using administrative credentials or via the more secure oAuth option which utilizes a security token, the LDAP configuration, and which objects to synchronize. Options include the ability to synchronize OUs, groups, users, user profiles, shared contacts and calendar resources.

You can map objects in AD to objects in Google Apps - the Finance OU to a new "Finance" Group for instance. You can also configure notifications so you'll be aware of what worked/failed, as well as logging.

Best of all, you have the ability to run a "Simulated sync" to confirm everything will work properly via a test operation before you proceed; this will allow you to look for and correct any issues so you're not forced to fix things on the fly.

Once you're good with the setup and have run it successfully, the synchronization can be scheduled using the sync-cmd command line utility which can be scripted via the local task scheduler on the Directory Sync system.

There is also the option to use secure LDAP if you're ultra-vigilant (although please keep in mind this would only apply to the internal Directory Sync system's connection to your internal domain controller; the https connection to Google Apps is already encrypted - basically, it would be like hiring a police escort to walk your kids to the bathroom of your house). A word to the wise: having worked recently with secure LDAP via another venture, I have found it crucial to make sure the internal network infrastructure can support these connections and the appropriate ports are open.

So what about passwords?

Well, that's the tricky part. Passwords do not synchronize in the default configuration (the native Active Directory and Lotus Domino password formats are not supported). The Google Apps Password Sync utility is needed if you want passwords to work across AD-Google Apps. This requires all password changes to be performed in Active Directory.

How do the imported objects look in Google Apps?

They look like any other standard objects and appear in the Contacts section (this applies to both users and shared contacts), as shown in Figure D.

Figure D

How can I get started?

The full admin guide is available from the "Google Apps Directory Sync" support page. This page also contains multimedia presentations outlining the steps involved. This is a very straightforward setup which will provide you with plenty of flexibility and ease of administration should you need to implement it.

Also read:

About

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

7 comments
subir.kar
subir.kar

I configure google Active Dir Sync and test reports are well But users whcich is in my AD sync only when email ID will be providing in active directory .I want Users sync only through users not given email ID .Please help me

fvivaldelli
fvivaldelli

So, If I set this... all my passwords' employees will be copied to the cloud? Mine, my lawyers', my marketing guys... Really, I think that Microsoft offer setting my company mails to Office 365, and setting up AD Federation to achieve single sign-on is safer than this...

vpv
vpv

The company I work for just set the way back machine to 1980 and embarked on the tragic path to google craps. If you like bad browser software and reduced features then you'll be right at home. The lack of right-click context based menus is glaringly obvious when you attempt to use the product. The list of maladies is long but here's a summary: The Account sync doesn't work as well as advertised. The google aps sync for outlook doesn't work. Their answer for every issue is to install chrome You can't attach an agenda to a calendar invite!

darrylhadfield
darrylhadfield

It's free, sure... but only if you're paying for google apps. There are a significant number of organizations using Google Apps Standard, for which this tool will not work. @Rusty - Giggle Apps? If you're so lax in your implementation that you feel it's a risk, perhaps you're the one who needs a head examined. It's a tool, like anything else, and gApps actually has better security than most of the other cloud service providers out there... and it's a damn sight simpler to administer than MSE2k10 running on Server2k8R2Enterprise. Connecting the two isn't a bad idea at all - especially given that it's a one-way sync. RTFM FTW, my friend. @Michael Kassner.. Yeah, and you appear to not have gotten fully informed, either. Per Mat Honan himself: "In many ways, this was all my fault. My accounts were daisy-chained together. Getting into Amazon let my hackers get into my Apple ID account, which helped them get into Gmail, which gave them access to Twitter. Had I used two-factor authentication for my Google account, it’s possible that none of this would have happened.." Single Sign-on is simply an extension of the security that's already in place. Using a different password for every site, every service, every system... will only confuse security to the point that people start writing them down or using other tools - like SSO, but less secure - and you now have worse security than in the first place. Using basic security concepts - like the 2fac Auth that Mat Honan himself references (which, btw, I also use myself - in addition to app-specific passwords, and other tools as well to protect myself and my clients) are a natural extension of SSO that make sense... all while ensuring that security remains SECURITY and not just obfuscation. WAKE UP PEOPLE. Security is your own responsibility, and if something breaks, it's on your head, no-one else's. If you do full due diligence, then even Yahoo mail (okay, so this is a stretch!) can be a viable business tool... but it always, always, ALWAYS comes down to taking responsibility for your actions. As a former SIPRNET admin, no way in hell would I have used certain tools.. because my due diligence - done out of a sense of responsibility for the data entrusted to my systems - indicated it wasn't safe enough. As a private consultant who handles several law offices? gApps does a great job, as long as the policies are in place to ensure the lawyers in those practices understand what's okay and what isn't... but due diligence requires that I make it clear to the users what's okay and what isn't. Devil's Advocate: Sure, blindly turning on tools without configuration customization and due diligence would be a bad idea, and gApps, G's AD sync tool, etc... would be lunacy to implement. That said? Don't be an idiot. Research and deploy based on use case applicability.

rustys
rustys

Anybody with AD that uses giggle apps needs their collective heads read.

Mark W. Kaelin
Mark W. Kaelin

Have you tied Active Directory into your implementation of Google Apps?