Google Search Appliance Managing Search for Controlled-Access Content Google Search Appliance software version 7.
Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 www.google.com September 2012 © Copyright 2012 Google, Inc. All rights reserved. Google and the Google logo are registered trademarks or service marks of Google, Inc. All other trademarks are the property of their respective owners. Use of any Google solution is governed by the license agreement included in your original contract.
Contents Chapter 1 Overview ................................................................................................................... 5 About this Guide Which Sections of this Guide Should I Read? Chapter 2 5 6 Crawl, Index, and Serve ..............................................................................................
Customizing the Universal Login Form Using the Page Layout Helper Creating a Fully Customized Universal Login Form Chapter 3 50 51 51 Use Cases with Public and Secure Serve for Multiple Authentication Mechanisms ...........
Chapter 1 Overview Chapter 1 The Google Search Appliance makes documents in your domain discoverable through search. In addition to public content that is available to everyone, the search appliance can crawl and index documents that require a login and password or another form of authentication. To protect confidentiality at serving time, the search appliance determines whether the user performing the search is authorized to view each document before it displays results.
Which Sections of this Guide Should I Read? This guide helps you to answer the following questions: • How do I set up my search appliance to crawl and index controlled-access content? • Once I have indexed controlled-access content, how do I specify the content that is visible to a user during serve? Public content (access=p) is available in all search results, while secure content (access=s) is only visible to authorized users.
Access Method Access Type Suggested Crawl Method Suggested Serve Method Multiple login domains: more than one set of credentials are required to provide access to all content. Public only Forms Authentication (see “Configuring Crawl for CookieBased Access” on page 10) Cookie-based authentication (see “Cookie-Based Authentication” on page 20) Multiple login domains: more than one set of credentials are required to provide access to all content.
Chapter 2 Crawl, Index, and Serve Chapter 2 This chapter describes how a search appliance discovers content on your servers. It provides an overview of authentication and authorization methods used during crawl and index, and the methods available during serve. It also provides basic instructions for configuring a search appliance to crawl, index, and serve controlled-access content.
After the search appliance authenticates a user by establishing the user’s identity, the search appliance performs authorization checks to determine whether a user has access to the secure content that matches their search. For detailed information about authorization on the Google Search Appliance, see “Authorization” on page 38. A Google Search Appliance provides additional methods for enabling authentication and authorization that do not require user impersonation.
You can specify a different set of access credentials for each URL pattern in the Admin Console. The means by which you provide these credentials is different for each kind of authentication, but the general process remains the same. Configuring Crawl for Cookie-Based Access The search appliance supports cookie-based access (single sign-on, forms). For sites that require the use of a cookie for authentication during crawl and index, you can define your content with a forms authentication rule.
• The Crawl and Index process for content that uses HTTP Basic and NTLM HTTP is controlled by parameters under Crawl and Index > Crawler Access. To learn more about setting up crawl for HTTP Basic and NTLM HTTP, click Help Center > Crawl and Index > Crawler Access in the Admin Console. • If you are using HTTP, Google recommends that you use HTTPS for all requests for controlledaccess content because HTTP Basic passes user credentials as clear text.
By default, the search appliance uses its own store of preloaded certificate authorities. These default certificate authorities are used by most browsers. By using these default certificate authorities, the search appliance trusts the same servers that browsers trust.
Secure Content and Public Content Once controlled-access content is present in the index, the search appliance labels it as “secure” or “public”: • If the content is labeled “public,” any user with access to the search appliance can view links to content in response to a search query.
How a Search Appliance Determines What to Display in Public Search Results The front end configuration for a search results page controls how much information users see for each item in the search results. When you make controlled-access content available for public search, open the Page Layout Helper or the XSLT Stylesheet Editor for each front end and review the stylesheet configuration to ensure that you are not revealing more information than the user needs.
Authentication Serve-time authentication is the process of verifying the identity of a user who has issued a search request for controlled-access content.
The following diagram presents an overview of what happens when a user searches for protected content. The numbers in the diagram refer to the following steps in the process: 1. The user performs a search against content in one or more protected resources. 2. The search appliance prompts he user once for all protected resources by using a single login page, the Universal Login Form. 3.
The domain www.abcreports.com uses one, unique set of credentials (user name and password). All the other domains share a different single set of credentials. Because ABC company’s domains are protected by two sets of credentials, their search appliance administrator can group the domains into two credential groups, “reports” and “Default,” as illustrated in the following diagram.
Universal Login Form After credential groups are configured, whenever a user performs a secure search, and the user is not already authenticated, the Google Search Appliance presents the Universal Login Form, shown in the following figure. The Universal Login Form is the primary way the search appliance gathers user credentials (usernames and passwords). The user’s credentials are applied to all the systems in the credential groups for which the user supplies a username and password.
6. If any credential groups remain unsatisfied, the Universal Login Form is presented again (with only the unsatisfied credential group’s enabled), up to three times. Options that you, as the search appliance administrator, choose when configuring a credential group determine whether the user must enter credentials on the Universal Login Form to view search results. For more information about this topic, see “Creating Credential Groups” on page 19.
If this option is checked, the user is not required to type a username and password in the Universal Login Form for this credential group. The user can submit the Universal Login Form and view search results. However, if the user does not login, then search results do not include secure results protected by that credential group. If this option is not checked, the user is required to type a username and password in the Universal Login Form.
Configuring a Credential Group for Cookie-Based Authentication Configure a credential group rule for cookie-based authentication by supplying a URL pattern and sample URL on the Serving > Universal Login Auth Mechanisms > Cookie page in the Admin Console. Optionally, you can also supply a redirect URL. Sample URL Supply a sample URL, which is any page in the protected site that all authenticated users can view.
To add a credential group rule for cookie-based authentication: 1. Click Serving > Universal Login Auth Mechanisms > Cookie. 2. Select a credential group from the pull-down menu. 3. Optionally, click When sample URL check fails, expect the sample page to redirect to a form and log in to that form. 4. In the Mechanism Name box, type a unique name for the authentication mechanism. A mechanism name must not be the same as another mechanism name or credential group name.
Cookie-Based Authentication Scenarios Different organizations set up cookie-based authentication rules for the Google Search Appliance’s Universal Login in a variety of different ways. The selections that you, as a search appliance administrator, make by using the Admin Console depend on your system’s capabilities and your organization’s requirements. For examples of setting up cookie-based authentication, see “CookieBased Authentication Scenarios” on page 67.
6. Optionally, type the number of seconds that the verification of user credentials will be trusted in the Trust Duration box. 7. Click Save. Adding a Credential Group Rule for NTLM To add a credential group rule for NTLM authentication: 1. Click Serving > Universal Login Auth Mechanisms > HTTP. 2. Select a credential group from the pull-down menu. 3. Click the NTLM check box. 4. In the Mechanism Name box, type a unique name for the authentication mechanism.
2. Choose Administration > SSL Settings. Configure the search appliance to permit crawl and serve over HTTPS by installing an SSL certificate. For details, see “Configuring Crawl and Serve Over HTTPS” on page 11. 3.
• aes256-cts-hmac-sha1-96 • des-cbc-md5 To ensure that a search appliance uses Kerberos during serving, content sources must be enabled for Kerberos. For more information on ensuring that Kerberos is configured correctly on Windows content sources, see the wiki page http://code.google.com/p/google-saml-bridge-for-windows/wiki/ ConfigKerberos (the information is provided as a reference, and is not officially supported by Google).
After you complete these steps, recrawl the affected content sources. The search appliance is then able to check a user’s authentication status without requiring an additional login. A verified identity from Kerberos authentication can be used for authorization.
5. At the command prompt, create a keytab file for the search appliance and register the search appliance as the principal by entering the following command: ktpass -princ HTTP/FQDN_of_the_searchappliance@DOMAIN_NAME -mapuser DOMAIN_NAME\searchappliance_username -pass searchappliance_password -out filename.keytab -ptype KRB5_NT_PRINCIPAL where FQDN=fully qualified domain name. The search appliance username, password, and domain must be consistent with the user account that you created in step 2.
3. Open the properties for the user. Use the Account tab for the search appliance account to modify and apply the following properties: • Select the domain that you want to use from the drop-down box. Typically, there is only one domain listed. • Select the Use DES encryption types for this account checkbox. • Clear any other checkboxes under account properties. • If permitted by your security policies, set Password never expires. 4. Open a command prompt. 5.
4. Optionally, to enable cross-domain access, click the Enable KDC DNS Lookup checkbox. 5. Click the Save Kerberos KDC Hostname button. 6. Under Import a Kerberos Service Key Table (“keytab”) File, type the path name for the keytab file in the Keytab File Name box or click Browse to navigate to the file. 7. Click the Import Kerberos Keytab File button. 8. Select a credential group from the pull-down menu. 9. Click the Enable Kerberos support checkbox. 10.
4. Under Security, select the checkbox labeled Enable Integrated Windows Authentication (requires restart). This sets the browser to use Kerberos authentication. 5. Click OK and restart Internet Explorer. Configuring Firefox/Mozilla To configure Firefox/Mozilla: 1. Start Firefox. 2. In the address bar at the top of the window, enter the command “about:config”. 3. Double-click network.negotiate-auth.trusted-uris. Modify this parameter to include the search appliance’s URL as a trusted URI. 4.
Configuring a Credential Group for SAML Authentication When the Google Search Appliance is configured with a credential group that includes a SAML authentication domain, a user performing a secure search is challenged by the SAML Identity Provider. The user provides her credentials on the Identity Provider login page.
Connectors You can configure an authentication domain for a registered connector manager that has one connector with support for the authentication Service Provider Interface (SPI). You can have only one connector instance per connector manager with this authentication method. Configuring a Credential Group for a Connector Manager To add a credential group rule for a connector manager: 1. Click Serving > Universal Login > Auth Mechanisms > Connectors. 2.
Integrating the Search Appliance with an LDAP Server If you are not using Kerberos authentication, and want to enable the search appliance to validate a user’s login name and password by using a Lightweight Directory Access Protocol (LDAP) server, enable Directory Integration. This section provides a general overview of how to enable the search appliance to authenticate credentials against one or more LDAP servers.
11.
Enabling Group Lookup You can enable a search appliance to automatically look up group information for a user during authentication, provided that the search appliance has a verified identity for the user. To look up group information for a user, the search appliance uses the combination of group information from all its available sources. For example, if the search appliance has group information in the form of policy ACLs, it looks up group information for the user in the policy ACLs.
2. 3. Choose Administration > SSL Settings. Scroll down to Force secure connections when serving?. • To return results in the protocol used by the original search query, choose No. This option is the least secure. • To force the search appliance to use HTTPS for secure content only, choose Use HTTPS when serving secure results, but not when serving public results. • To force the search appliance to use HTTPS for all content, choose Use HTTPS when serving both public and secure results.
The effect of the response header is that it has “cracked” open the cookie and revealed the user and/or group name. The cookie can be used to “pre-satisfy” the credential group and the user has access to protected content without having to re-enter his credentials. Other than setting up a sample URL, there is no configuration required for using cookie cracking on a search appliance.
Flexible Authorization Flexible authorization gives you more control over authorization by enabling you to: • Specify authorization mechanisms in your environment • Customize which authorization mechanisms handle which URLs You can perform these tasks by configuring flexible authorization rules.
Legacy Authorization With legacy authorization, the search appliance performs an authorization check in this order: 1. Check for cached results from a previous check. 2. Check for Policy ACLs and per-URL ACLs. If you specify a policy ACL rule (see “Policy Access Control Lists” on page 40), the search appliance checks the URL patterns in the rules against the URLs that are returned for in the search results. If the users and groups in the rule are permitted to view the results, then the results display.
Policy ACLs typically store the results that would have occurred if the search appliance initiated a HEAD request to verify authorization. However policy ACLs can also be used to override the decision that would have been returned by a HEAD request.
Methods for Adding ACLs to the Index The search appliance supports different methods for adding per-URL ACLs and policy ACLs to the index. The following table lists these methods and provides references to documentation for each method. ACL Type Method Comments Described In Per-URL ACL Feed Use a feed to push per-URL ACLs to the search appliance. Connector Use a connector to push perURL ACLs to the search appliance (uses feeds).
Both the meta-name and the meta-value are encoded according to section 2 of RFC3986 (http:// www.ietf.org/rfc/rfc3986.txt) (commonly known as percent-encoding). The following example shows an encoded header: X-GSA-External-Metadata: google%3Aaclusers=Maria, google%3Aaclgroups=eng The per-URL ACLs supplied at crawl time are added to the search appliance index, replacing previously indexed per-URL ACLs. Subsequently crawled per-URL ACLs replace the previously indexed ones.
“General URL Patterns” on page 44 • Prefix Patterns If there is one or more matching prefix patterns, the pattern with the longest prefix is the best match. A prefix-pattern specifies a (possibly partial) domain and a prefix of the path portion of the URL. The general format of a prefix pattern is: / Examples of prefix patterns: sales.example.com/products/ sales.example.com/products/mypage.html sales.example.
7. In the Namespace/Credential Group box, accept the default namespace/credential group for the principal or type a different namespace/credential group. 8. If the principal name and domain are case sensitive, click the Case Sensitive? checkbox. 9. Click Save. To navigate to the previous page, click the Back to Policy ACL list link. Editing a Policy ACL To add a policy ACL: 1. Click Serving > Policy ACLs. 2. Click the Edit link next to the policy ACL rule you want to edit. 3.
To import and update policy ACLs: 1. Import the policy ACLs from the earlier release as described in “Importing a Configuration File.” 2. For each imported policy ACL, click the Edit link under Matching URL Patterns. Observe that Principal Name and Principal Type are imported correctly and that default values are added for the Domain, Namespace/Credential Group, and Case Sensitive?. 3. Update Domain, Namespace/Credential Group, and Case Sensitive? as appropriate for the policy ACL. 4. Click Save.
• The user in the policy ACL rule must match the identity in the Default credential group. For example, suppose the username in the Default credential group is “joe.” To ensure that the search appliance can use a policy ACL with this identity, ensure that there is a policy ACL rule with the user “joe.” • Check the Requires a Username option (see “Require a User-Name Option” on page 19) for the Default credential group. • Do not rename the Default credential group.
The SAML Authorization SPI is exposed to allow a customer’s web service to communicate between the Authorization SPI and the customer’s server that provides access control services, the Policy Decision Point. The Authorization SPI is required to support X.509 certificate authentication during serve. This section describes the Authorization SPI. Before using the Authorization SPI, you must configure the appliance to crawl and index some secure controlled-access content.
2. 3. Scroll down to Authorization SPI and enter the connection information for your Policy Decision Point. • Under Authorization Service URL, enter the URL that the search appliance should use when sending SAML Request messages to the Policy Decision Point. For example, https:// server.domain.com:8443/SAML/services/AuthZConnector. The search appliance determines Authorization by issuing an element in messages sent to the Artifact Service URL.
Removing Controlled-Access Content from Search Results Despite your best efforts to set exclusion patterns and define secure access policies that prevent the indexing of private content, you may discover unanticipated content that you must remove from the index. Removing content from the search appliance index takes anywhere from 30 minutes to a few hours, depending on the size and complexity of your index.
Using the Page Layout Helper The Page Layout Helper enables you to customize the Universal Login Form without directly editing any HTML. The Page Layout Helper contains the areas described in the following table. Area Description Logo Enter the location and name of the logo that you want to use. You may have to type the complete URL of the logo file. Also enter the width and height in pixels of your logo image. Font Face Enter the name of the font family that you want to use, for example, Arial.
If a credential group is already satisfied at the time the Universal Login Form is rendered, the Universal Login Form attempts to disable the login fields for the already-satisfied group(s). It does this in the following two ways: • First, the HTML for the form fields matching the above names are dynamically changed to include the “disabled” attribute and the user-name field is populated with the credential group’s verified user-name (if known).
Chapter 3 Use Cases with Public and Secure Serve for Multiple Authentication Mechanisms Chapter 3 This section provides more detailed explanation of how to set up crawl for controlled-access content and how to set up the Google Search Appliance to centralize serve-time authentication. Use Case 1: HTTP Basic or NTLM HTTP ControlledAccess Content with Public Serve The ABC Company wants to make its controlled-access content discoverable using intranet search.
Setting up Crawl and Index First, the system administrator creates a user account for the search appliance, called ABCsearch, and sets up access policies that ensure that the ABCsearch user account is authorized to view all files on events.abc.int, and announce.abc.int. The feed process on directory.abc.int has its own account with similar permissions, called ABCfeeder. Next, the search appliance administrator logs into the Admin Console and performs these actions: 1.
Populating the Index for Controlled-Access Content During crawl, the search appliance goes through each of the content sources that have been configured, and uses the credentials under Crawler Access to obtain the controlled-access content. The search appliance can use multiple protocols to crawl and index controlled-access content. • The search appliance connects to events.abc.int over HTTPS.
Serving Controlled-Access Content to the User as Public Content ABC Company has decided to make the search results public: the events, announce, and directory servers control access to their content, but employees can discover the information they need by performing a search query. Eric is an employee of ABC Company. He wants to find an announcement about a colleague’s recent promotion to Director. Eric opens the search page in a web browser and enters a query about “Maria Jones director”.
Currently, when employees search for protected personnel information, they are prompted for their credentials by each authentication mechanism separately. AlphaLyon’s Information Technology department has set an objective to centralize serve-time authentication for the various servers hosting personnel information. This way, users need to provide their credentials only once for content protected by several authentication mechanisms.
6. In the URL Pattern for this rule box, Tanya enters http://insidealpha.com/ and clicks Create a New Forms Authentication Rule. The search appliance proxies the login form. 7. Tanya enters the credentials for the crawler user account and saves the forms authentication rule. The search appliance stores the rule for use in crawl for all content under http:// insidealpha.com/. When a cookie expires, the search appliance uses the stored crawler account to request a new session cookie. 8.
3. The search appliance provides the username “ALSearch” and the password entered in the Admin Console. 4. The web server verifies that ALSearch has access to view documents on comp.alpha.int. 5. The search appliance crawls through all documents on comp.alpha.int and adds them to the index. For content on pers.def.int, which is protected by NTLM HTTP: 1. The search appliance connects to pers.def.int over HTTPS. 2. The Microsoft IIS server asks for credentials using Windows Authentication. 3.
5. Next, to add the comp.alpha.int web server, which uses HTTP Basic authentication, to the credential group, Tanya clicks the HTTP tab. The Default credential group is already selected. 6. Tanya types http://comp.alpha.int/na.html, a sample URL for the site in the Sample URL box, and clicks Save. Options for adding another HTTP-based domain appear on the page. The Default credential group is already selected. 7. To add pers.def.
Use Case 3: Two Sets of Credentials for Two Connectors AlphaLyon, from use case 2 (see “Use Case 2: One Set of Credentials for Multiple Authentication Mechanisms” on page 56), has acquired ABC company, from use case 1 (see “Use Case 1: HTTP Basic or NTLM HTTP Controlled-Access Content with Public Serve” on page 53). Content for the merged companies is managed by two different content management systems (CMSs).
Adding Connectors to the Credential Groups Next, Tanya configures the Default credential group and the ABCLivelink credential group by adding the connectors to each group: 1. First, to add the Documentum connector to the Default credential group, Tanya clicks Serving > Universal Login Auth Mechanisms >Connectors. The Default credential group is already selected. 2. Tanya types AlphaCM, a mechanism name for this entry in the Mechanism Name box. 3.
9. The search appliance queries the index and obtains a list of relevant results for Leslie’s query. 10. The search appliance checks the list to see whether any of the results require authorization and filters the results based on which results Leslie is authorized to view. 11. The search appliance directs Leslie’s browser to a search results page that contains all results that match the query “Island” that Leslie is authorized to view.
Obtaining a keytab File Before configuring and activating Kerberos support, Tanya must obtain a Kerberos Service Key Table (keytab) file from the domain controller. Tanya performs the following actions: 1. Tanya requests a keytab file for the search appliance from Ashish, the Windows system administrator. 2. Ashish sends Tanya a keytab file named searchappliance.keytab. 3. Tanya saves the keytab file on her Desktop.
The search appliance performs the following steps before sending Salim’s browser to the search results page: 1. The search appliance queries the index and obtains a list of the most relevant results for Salim’s query. The list of potential results includes announcements about the new AlphaLyon Product release (public content), as well as sales presentations and other sales collateral materials about AlphaLyon Product (secure content). 2.
Search by an Unauthorized User Eric isn’t a member of the sales team, but he’s also interested in the new AlphaLyon Product release and wants to know when the sales figures will be posted. Eric opens the search page in a web browser and enters the same query for AlphaLyon Product fall sales report. The search appliance performs the following steps before sending Eric’s browser to the search results page: 1.
Chapter 4 Cookie-Based Authentication Scenarios Chapter 4 This section provides detailed explanations of how selecting different options in the Admin Console affects the process of cookie-based authentication. Overview of Scenarios Different organizations set up cookie-based authentication rules for the Google Search Appliance’s Universal Login in a variety of different ways.
Each scenario contains detailed information about the interactions between the user, the search appliance, the content server (sample URL, see “Sample URL” on page 69) and login server (redirect URL, see “Sample URL Redirect to Login Form” on page 69) that take place in the different configurations. Read the scenarios so that you can decide which configuration best matches your system’s capabilities and your organization’s requirements.
Sample URL A sample URL is any page that should not be displayed unless the user who requests the content is logged in and authorized to view it. A sample URL enables the search appliance to detect if a user is logged in, and, if so, avoid the authentication page. An example of a sample URL is http://it.abcreports.com/status.html. To detect if a user is logged in, the search appliance sends an HTTP GET message to the sample URL. If a user is logged in, the sample URL’s content server, it.abcreports.
If a sample URL is provided, it allows the search appliance to skip the redirect if the user already has cookies that provide access to the sample URL. A sample URL also allows verification of the user cookies upon return from the sample URL service. Possible advantages of redirect URL authentication: • The user’s password is never sent to the search appliance. • The redirect URL server can interact directly with the user.
With cookie cracking, if a sample URL check for user credentials is successful, the sample URL’s content server generates the following response HTTP headers in addition to the standard headers: X-Username:value X-Groups:value1, value2 where value becomes a verified identity for the credential group that is associated with the sample URL. The effect of the response header is that it has “cracked” open the cookie and revealed the username and/or group(s).
Scenario 1: Normal Forms Authentication In Scenario 1, if the sample URL check fails because the user is not yet logged in, the content server redirects the search appliance to a login system for log in, then the login system’s server redirects the search appliance back to the content server after login. Scenario 1 corresponds to Forms Authentication in the search appliance’s legacy authentication.
4. If the search appliance’s session cookie is still valid, the authentication phase is complete. If the search appliance’s session cookie is not valid, the search appliance checks the content server by using the sample URL to detect whether other cookies that the browser has sent are valid. 5. If the user is logged in, the content server sends a 200 response to the search appliance and authentication is complete.
Process Overview of Scenario 2 The following diagram provides an overview of the cookie authentication process in scenario 2. For explanations of the numbers in the process, see the steps following the diagram. 1. The user requests a secure search. 2. The browser sends a GET message to the search appliance. 3. The search appliance checks its own session cookie to find out if authentication was previously completed.
Scenario 3: Cannot Use Universal Login Form and Need Identity Verified Silently Scenario 3 is a variation of scenario 2 (see “Scenario 2: Cannot Use Universal Login Form” on page 73). As in scenario 2, the system cannot use the Universal Login Form. But in this scenario, you need a verified identity to use with policy ACLs. The sample URL’s server provides the verified identity.
3. The search appliance checks its own session cookie to find out if authentication was previously completed. The search appliance sets a session cookie the first time a browser requests a secure search. 4. If the search appliance’s session cookie is still valid, the authentication phase is complete. If the search appliance’s session cookie is not valid, the search appliance checks the content server by using the sample URL to detect if other cookies that the browser has sent are valid. 5.
Process Overview of Scenario 4 The following diagram provides an overview of the cookie authentication process in scenario 4. For explanations of the numbers in the process, see the steps following the diagram. 1. The user requests a secure search 2. The browser sends a GET message to the search appliance. 3. The search appliance checks its own session cookie to find out if authentication was previously completed.
Set Up for Scenario 5 In scenario 5, the sample URL’s server is configured as a cookie cracker, meaning that it can provide silent authentication and a verified identity for the credential group that is associated with the sample URL. A 200 response from the sample URL includes the X-Username and/or X-Groups HTTP response headers. For scenario 5, set up a cookie authentication rule by specifying a Sample URL.
Scenario 6: Use an HTTP Basic Challenge to Get Cookies In Scenario 6, your system is set up to use HTTP Basic authentication. The Google Search Appliance supports both crawl-time and serve-time authentication for content protected by an HTTP Basic challenge. To set up a search appliance for this scenario, configure crawl of the protected content and then set up a cookie authentication rule by specifying a sample URL.
Scenario 7: Use an NTLM HTTP Login Page to Get Cookies In scenario 7, your system is set up to use an NTLM login page for authentication. The Google Search Appliance supports both crawl-time and serve-time authentication for content protected by an NTLM login page. To set up a search appliance for this scenario, configure crawl of the protected content and set up a cookie authentication rule by specifying a sample URL and a redirect URL.
Process Overview of Scenario 7 The following diagram provides an overview of the cookie authentication process in scenario 7. For explanations of the numbers in the process, see the steps following the diagram. 1. The user requests a secure search. 2. The browser sends a GET message to the search appliance. 3. The search appliance checks its own session cookie to find out if authentication was previously completed.
Index A Active Directory 27, 28 Administration > Certificate Authorities page 12, 25 Administration > LDAP Setup page 34 Administration > SSL Settings page 12, 25, 37 aes128-cts-hmac-sha1-96 encryption 25 aes256-cts-hmac-sha1-96 encryption 26 allow decision, authorization 39 API, policy ACL 42 arcfour-hmac encryption 25 artifact binding, HTTP 32 artifact resolver URL 32 authentication client certificate-based 24–25 connectors 33 cookie-based 20–23 description 8 HTTP-based 23–24 Kerberos-based 25–31 LDAP 33
Crawl and Index > Forms Authentication page 10, 11, 13, 57, 58, 59, 79, 80 crawler access 8, 54, 57 credential groups client certificate-based authentication 24–25 configuring 20 connectors 33 cookie-based authentication 20–23 creating 19–20 default 19 description 16 group is optional option 20 HTTP-based authentication 23–24 Kerberos-based authentication 25–30 LDAP 33–36 name 61 require a user-name option 19 SAML 32 satisfaction 18 D default credential group 19 deny decision, authorization 39 DENY, flexib
LDAP-based authentication description 33–36 group lookup 36 serve method 6 legacy authorization 40 M Make Public checkbox 13, 54, 56, 57, 63 metadata and per-URL ACLs 42 Microsoft IIS server 55, 56, 59, 63 multiple cookie domains 22 N NTLM authentication 6, 24, 80 NTLM HTTP crawl method 6, 7 use case 53–56 O Oracle Access Manager 10 P Page Layout Helper 14, 51 perimeter security 38 per-URL ACLs connectors 42 description 41 document headers 42 feeds 42 flexible authorization 39 late binding 47 metadata 4
SMB file share 6 SSL certificate 24 start URLs 54, 58 Status and Reports > Crawl Status page 58 U Universal Login description 15–20 perimeter security 38 Universal Login Form cannot use 73, 75 customizing 50–52 description 18 use case 60, 62 URL Pattern to Protect 43 URLs follow and crawl 54 start 54 V verified identity 17, 36, 75, 77 W web feed 54 Windows Authentication 55, 59 Windows Domain Controller (DC) 64 X X.
