Configuring the Connectors for Multiple Active Directory Domains (Deprecated)

Google Search Appliance software version 7.0
Windows Server 2003
Windows Server 2008



This document describes how to configure the Google Search Appliance 7.0 and related controllers to work in an environment with multiple Active Directory domains for authentication and group resolution by using the Google Search Appliance Connector for Active Directory Groups.

Note: In single domain environments you do not need to configure a connector for Active Directory Groups; the Google Search Appliance Connector for SharePoint contains one implicit instance of this connector to simplify the configuration.

Introduction

How does authentication work when there are multiple domains?

To better illustrate the problem of authenticating in a complex environment with more than one domain, consider the following example. In this example, there are two domain forests (domain1.com and domain2.com), where domain1.com also has a child domain (child.domain1.com).

Multiple domain authentication diagram

Prior to the Google Search Appliance 7.0, it was possible to resolve groups from at most two domains at the same time (for example, with LDAP configured for group resolution in the Global Catalog for domain1.com and the SharePoint connector configured for group resolution in domain2.com), however this approach was not ideal. For example, not all groups were resolved correctly, domain local groups could not be retrieved from the Global Catalog, cross domain relationships could not be resolved, and there were performance issues with performing group resolution at serve time.


The Google Search Appliance Connector for Active Directory Groups

Starting with Google Search Appliance 7.0, a new connector is shipped both onboard the appliance as well as part of the external installation of the SharePoint connector. It is called the Google Search Appliance Connector for Active Directory Groups.

Instead of performing group resolution against Active Directory at serve time, it crawls the domain controllers and caches this information in its internal database to ensure speedy and complete responses at serve time. This connector supports all Active Directory hierarchies:

  • multiple domains in multiple forests
  • all types of group membership
  • cross-domain group memberships
  • cross-forest group memberships
  • domain local groups resolution.

Connector Guidelines and Rules

To configure multi-domain group resolution you need to follow these rules:

  1. One Google Search Appliance Connector for Active Directory Groups for each domain (domain1.com, child.domain1.com, domain2.com).

  2. All connectors for Active Directory Groups connectors must be in the same Connector Manager. If you are using a connector for SharePoint, it also needs to be in the same Connector Manager.

  3. Do not use global catalog (always use ports 389 or 636).

  4. Use the Fully Qualified Domain Name (FQDN) of a domain controller (i.e. domain1dc.domain1.com NOT domain1.com).

  5. You need only one connector for group resolution in Universal Login Form (ULF) Authentication mechanisms because each connector is able to resolve users from all domains.

  6. If you are using SharePoint local groups you need to put the SharePoint connector in ULF Authentication mechanisms. There is no need to add any connectors for Active Directory Groups to ULF.

  7. In single domain environments you do not need to configure any connectors for Active Directory Groups, this functionality is included in the Google Search Appliance Connector for SharePoint.


Configuring the Connectors if there are no Local Groups

In our example we will have to configure three Google Search Appliance Connectors for Active Directory Groups to resolve all groups from the two forests (one for domain1.com, one for child.domain1.com and one for domain2.com).

Note: This configuration will not resolve local groups. If you are using local groups, please see Configuring the Connectors to Resolve Local Groups.

Multiple domain authentication diagram

  1. Create the Google Search Appliance Connector for Active Directory Groups for domain1.com.

    • Hostname: name of one of the domain controllers in the domain

    • Port: 636 or 389 (636 is preferred if you have SSL trust configured between the GSA and the domain controller)

    • Method: SSL (when port 636 is selected), Plain (when port 389 is selected)

    • Principal: username of a user from current forrest (i.e. either user from domain1.com or child.domain1.com)

    • Password: password of said user

    Active directory server connector configuration

  2. Create the Google Search Appliance Connector for Active Directory Groups for child.domain1.com.

    Notice that we can use the same principal for domains in the same forest (DOMAIN1\aduser):

    Active directory server connector configuration child domain

  3. Create the Google Search Appliance Connector for Active Directory Groups for domain2.com.

    Active directory server connector configuration domain2

  4. Set Up the Universal Login Form Authentication Rule.

    To authenticate any user from the three domains (domain1.com, child.domain1.com, domain2.com) you need to configure only a single ULF Authentication rule. Any one of the three configured connectors can be used.

    The connector uses a single database within the Connector Manager to store information from each domain (which is why all connectors for Active Directory Groups must be in the same Connector Manager). At serve time there is no functional difference between the connectors; any single one of them is able to resolve groups from all domains.

    Active directory server connectors tab


Configuring the Connectors to Resolve Local Groups

If you use SharePoint local groups, to perform group resolution you need to configure the Google Search Appliance Connector for SharePoint in addition to the Google Search Appliance Connector(s) for Active Directory Groups.

Consider that we add a SharePoint server into the environment to domain2—sharepoint.domain2.com:

Multiple domain authentication with SharePoint diagram

  1. Configure the Google Search Appliance Connector for Active Directory Groups for domain1.com.

    Active directory server connector configuration

  2. Configure the Google Search Appliance Connector for Active Directory Groups for child.domain1.com.

    Active directory server connector configuration child domain

  3. Configure the Google Search Appliance Connector for SharePoint in domain2.com.

    Instead of configuring another Connector for Active Directory Groups for domain2.com, we can use the built-in Active Directory features in the Google Search Appliance Connector for SharePoint.

    We will configure this connector as follows:

    Active directory server configuration for local groups

    Sections highlighted in red show which parts of the configuration are going to be used for the implicit internal connector for Active Directory Groups. The username, domain and password fields are going to be used as the principal and LDAP Configuration settings will be used to configure the hostname, port and connection method.

  4. Set Up the Universal Login Form Authentication Rule.

    To resolve Active Directory groups from domain1.com, child.domain1.com, domain2.com and SharePoint local groups from sharepoint.domain2.com we need to configure only one connector ULF rule: the Connector for SharePoint, which is crawling our site.

    Internally this connector will first contact the Connector Manager database to retrieve all Active Directory domains. Using this information it will resolve all SharePoint local groups the user belongs to.

    Active directory server connectors tab with SharePoint


Fine Tuning

One common pitfall when configuring the connector for Active Directory Groups is not configuring the connector against the FQDN of a domain controller (domain1dc.domain1.com in the example above) but against the domain name (domain1.com). This can cause unnecessary high load on your AD infrastructure.

Each domain controller maintains its own list of changes to the Active Directory objects, so every time the connector is load balanced to different domain controllers, it must resynchronize everything to ensure that the data is correct.

If this happens the connector logs will contain a warning for the administrator:

Directory Controller changed!!! Connected to [CN=NTDS Settings,CN=DOMAIN2DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain1,DC=com], but expected [CN=NTDS Settings,CN=DOMAIN1DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain1,DC=com]. Not able to perform partial updates—performing full recrawl. Consider configuring AdGroups connector to connect directly to FQDN address of one domain controller for partial updates support.

If you see this message in the logs, please consider configuring the Connector for Active Directory Groups to point to one of your domain controllers to ensure that partial updates can be performed, which will significantly lower the load on your infrastructure.

For additional information, see Polling for Changes Using USN Changed.

Was this helpful?
How can we improve it?