Google Apps Directory Sync Download

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.

Aug 24, 2015 - Download and install Google Apps Directory Sync - Google Apps Administrator Help. GoogleAppsDirectorSync Admin Guide. Decide what data. Google Apps Directory Sync Administration Guide Release 3.2.1 Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 www.google.com. Jan 3, 2019 - Google Cloud Platform and Google Apps share the same authentication. Upload the certificate that you have downloaded from Azure portal.

Google Weekly Newsletter

See how to get the most out of Google Docs, Google Apps, Chrome, Chrome OS, Google Cloud Platform, and all the other Google products used in business environments. Delivered Fridays

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.

Google Apps Sync For Outlook

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?

Set Up Google App Sync

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