Decide what data to sync from your LDAP server

Specify what domain you want to synchronize. You need to add the domain to the GADS configuration. You can reference the exact domain name in the Google Admin console.

Note: You can't sync domain alias addresses using GADS. Learn more about domain aliases and additional domains.

You can also use a domain name replacement. A domain name replacement is most often used for a pilot domain, but it can also be used if you are using GADS to move to a new domain. If you specify another domain in Configuration Manager, you can import a full list of users into a different domain.

Set up the new domain as a primary domain for Google Apps. Then, in the Configuration Manager LDAP settings, enter the new domain as your Google Apps domain, and specify a Google Apps administrator for that domain. In Google Apps Settings, set GADS to replace domain names in LDAP email addresses with this domain name. GADS changes the email addresses of all your users to the new domain during synchronization.

After your pilot period is complete, you can change the domain name (and Google Apps administrator) to your actual primary domain, and keep all other configuration options the same.

• Users: Look through your directory of users with an LDAP browser and ensure that you are importing the correct number of users. If you import more users than you have Google Apps licenses for, you may experience errors during synchronization. Learn more about Renewals and licenses.
• User profiles: If your LDAP directory server includes additional information, such as addresses, phone numbers, or contact information, you can synchronize this information as well.
• Aliases: You can synchronize one or more attributes for aliases from your LDAP directory into Google Apps address aliases.
• Unique ID: If your users are likely to change usernames (email addresses), set up a Unique ID attribute before you set up a synchronization so that user information is not lost when a user changes their email address.
• Passwords: GADS supports a limited set of password operations. If you have a Microsoft^® Active Directory server, you can keep your LDAP directory passwords synced to your Google Apps domain with Google Apps Password Sync (GAPS).
• Deleted and suspended users: By default, users not found in your LDAP directory are deleted from the Google Apps domain and suspended users are ignored. You can change the default setting on the user accounts page of Configuration Manager. If you set GADS to suspend users instead of deleting them, you have the ability to view and transfer user assets to take advantage of data recovery. Alternatively, you can delete suspended users, but you can only delete or suspend, not both.

You can organize your users in the Google Apps domain by mailing list or organizational structure:

• Mailing list: Decide which mailing lists you want to synchronize from your LDAP directory server to the Google Apps domain. Mailing lists in your LDAP directory server are imported as groups in the Google Apps domain.

  If you want to retain the mailing lists in the Google Apps domain:

  1. Find out what attribute contains the members of your mailing lists. This is often the member attribute or the mailAddress attribute.
  2. Find out if the LDAP attribute for mailing list members contains an email address or a user Distinguished Name.

  Some mailing list attributes contain a literal address and follow a format such as user@domain.com. Some contain a distinguished name (DN) reference and follow this format: cn=Terri Smith,ou=Executive Team,dc=domain,dc=com.

  GADS can synchronize mailing lists using either format, but you need to know which you’re using beforehand so you can configure GADS correctly.

• Organizational structure: By default, GADS synchronizes all users into a single flat structure. This works well if you have a small organization or if you want all users to have the same settings and rights. This also works well if you are testing a small group before a larger rollout.

  If you want to use an organizational unit hierarchy in the Google Apps domain, you can synchronize the organization hierarchy from your LDAP directory server. If you do, look through your organizational units with an LDAP browser first to make sure that you are synchronizing the right structure. You may have special organizational units that should not carry over to the Google Apps domain, such as an organizational unit for printers.

  If you want to create organizational units manually in Google Apps domain, you can set them up in the Google Apps domain and then set GADS to move users into those organizations without changing the existing organizations. You can select this option on the Org Units page in Configuration Manager. For every user search rule, specify the organization that should contain users for that rule, or an LDAP attribute that contains the name of the appropriate organization.

GADS can synchronize other LDAP resources such as shared contacts and calendar resources to the Google Apps domain.

• Shared contacts: Shared contact details are visible to every user on a contact list. Also, if you set up shared contacts, email address auto-complete is enabled in Gmail for every user in the list. To import addresses into your Google Apps domain as shared contacts, enable Shared Contacts on the General Settings page in Configuration Manager.

  Note: GADS only synchronizes shared contacts; personal contacts are not synchronized.

  After you synchronize shared contacts, it may take up to 24 hours for the changes to appear in the Google Apps domain.
• Calendar Resources: If you want to import calendar resources (such as conference rooms) from your LDAP directory to the Google Apps domain, you need to configure Calendar Resources synchronization so that the resources are visible to every user.

  You need to specify a naming format for your calendar resources, keeping in mind that the rules for calendar resource names are different than other synchronized information. Names can't contain spaces or special characters. For details, see Google Apps Calendar Resource API.

GADS supports a limited set of password operations. It can import passwords only in an LDAP attribute that stores passwords in plain text, Base64, unsalted MD5, or unsalted SHA-1 format. Other password-encrypted and salted hashes are not supported. Most directory servers do not support these formats natively, and storing your user passwords in these formats on your mail server may have serious security implications.

For password synchronization, GADS provides the following options:

• Implement Single Sign-On for your domain: Users will use the same passwords and authorization for the Google Apps domain and your LDAP directory server. You can set up a Security Assertion Markup Language (SAML) server for your account to manage Single Sign-On. GADS creates random passwords during synchronization in this case.

  Note: Single Sign-On only supports only web authentication. Other forms of authentication (such as IMAP, POP, and ActiveSync) do not support Single Sign-On and still require a Google Apps password.

• Use a plain text LDAP attribute for the default password for new users: Use this option if you want users to have separate one-time passwords. With this option, Google Apps passwords are separate from passwords on your LDAP directory server. You can use this method to create a temporary password from any LDAP attribute that holds data in plain-text format.
• Use a third-party utility to convert unsupported passwords to a supported format: Use this option if you need to have Google Apps use the same passwords as your LDAP directory server, but you are unable to set up a SAML server. Check the Google Marketplace for third-party tools to help with synchronizing passwords, but keep in mind that Google does not support third-party tools.
• Specify a default password for new users: With this option, every new user has the same password until they sign in and change it. Google Apps passwords are kept separate from passwords on your LDAP directory server. To use this option, set a default password for new users and then set GADS to synchronize passwords for new users and then force them to change their password.
  Because the password can sometimes be guessed by other users, this is not generally recommended as a secure option.

You need to decide how your LDAP directory server data maps to your Google Apps data and have a clear picture of how every user, group, and resource should be synchronized. You can set up this mapping to a flat hierarchy, an automatic one-to-one synchronization, or a manual set of custom rules. For details, see What is synchronized.

As the Google Apps administrator for Company, you decide that the existing organization hierarchy on the LDAP server should be copied to the Google Apps domain, and identify the organizational units that should be synchronized.

You decide that Company needs to synchronize:

• Organizational units
• Users
• Aliases
• Groups (mailing lists)
• Shared contacts
• Calendar resources

The mailing lists in the LDAP directory server use the member attribute to store the members of each mailing list, and the member attribute contains the full distinguished name (DN) of the mailing list members, rather than their email address. As the GADS administrator, you note this attribute, and notes that it is a reference attribute, not a literal attribute.

Because the LDAP user-profile information on the LDAP server is not in a standard format across organizations, as the Google Apps administrator you decide not to synchronize this information.

In the LDAP server, you create a custom attribute and populate the attribute with a randomly-generated one-time password. In your Google Apps domain, you set up a mail merge to send out these passwords to users along with information on how to activate their accounts.

There are some users in the contractors organizational unit that are no longer with the company and should not be synchronized. You consider the list and note that all of them match a regular expression because the user addresses all begin with “defunct”. Finally, you create exceptions for these users in the Google Apps domain.