Google Search Appliance software version 7.0
Windows Server 2003
Windows Server 2008
- The Google Search Appliance Connector for Active Directory Groups
- Connector Guidelines and Rules
- Configuring the Connectors if there are no Local Groups
- Configuring the Connectors to Resolve Local Groups
- Fine Tuning
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.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.