Troubleshoot enterprise search

Managed by | Updated 6 years ago.

Integrated authentication isn't working

The answers below assume that you are trying to access the search using Internet Explorer (IE) and that authentication is enabled for the modern UI.

Examine the data model

Run a query as a user that should have access to the secured data and inspect the question element of the data model.

Look at the environmentVariables/AUTH_TYPE and REMOTE_USER values, and the userKeys value.

AUTH_TYPE should be NEGOTIATE and the REMOTE_USER should match the user that is being impersonated.

userKeys should contain keystrings for the DLS protected collections.  The response packet should look something like the screenshot below:

"userKeys": {
   "string": "example-collection-name;example-collection-name;ACL:-1#8456;L99;C:570#560#646#456#456#122;B:A#V;"
}

Use the server name (not 'localhost')

For some reason, using localhost interferes with authentication passing.  Use the server name instead (as you would from an outside computer connecting to the Funnelback server) e.g. http://yourdomain/s/search.html?collection=example-collection-meta.

Don't use a FQDN though - as this will place the server in the 'Internet zone' as far as IE is concerned.  The server must be identified as being in the intranet zone for SSO to function correctly.

Increase gatherer logging

For filecopy collections see: Setting the filecopier log level

Increase modern UI logging (see section below)

The modern UI can have it's logging increased to print additional information including details on userkeys and impersonation.

See: Enable DEBUG logging within the modern UI for detailed instructions on increasing the modern UI logging messages.

Enable padre security debugging

If it looks like impersonation is working and keystrings are present in the data model you can switch on padre security debugging.  Note: you should do this in conjunction with the increased modern UI logging above.

Edit the query processor options for the collection that you are querying and add -deb_security=10  Note: this will break the modern UI output, but cause additional logging to be sent to the log files.

Run a query against the DLS protected collection again and then view the modernui.Public.log - it should include additional debug lines that show the locks-keys matching being performed by padre.

The modernui.Public.log should get entries similar to the one below:

2016-05-18 10:25:24,518 [qtp2138564891-3057] [:] DEBUG servlet.NegotiateSecurityFilter - terminating impersonation
2016-05-18 10:25:45,643 [qtp2138564891-31] [:] DEBUG servlet.NegotiateSecurityFilter - GET /s/search.xml, contentlength: -1
2016-05-18 10:25:45,643 [qtp2138564891-31] [:] DEBUG spi.NegotiateSecurityFilterProvider - authorization: <none>, ntlm post: false
2016-05-18 10:25:45,643 [qtp2138564891-31] [:] DEBUG servlet.NegotiateSecurityFilter - previously authenticated Windows user: DEPT\svc_funnelback_searc
2016-05-18 10:25:45,643 [qtp2138564891-31] [:] DEBUG servlet.NegotiateSecurityFilter - re-impersonating user
2016-05-18 10:25:49,236 [qtp2138564891-31] [doca-intranet-trimpush:_default] TRACE padre.AbstractPadreForking -
---- RAW result packet BEGIN ----:
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<!-- Component: 'doca-intranet-trimpush' will NOT load a security plugin -->
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<PADRE_result_packet>
  <details>
    <padre_version>FUNNELBACK_PADRE_15.4.1.0 MDPLFS (Web/Ent) [64 bit]</padre_version>
    <collection_size>D:\funnelback/data/doca-intranet-trimpush\live\idx\index: 61.9 MB, 4860 docs</collection_size>
    <collection_updated>
      Tue May 17 15:49:18 2016    </collection_updated>
  </details>
  <!-- SECDs represented in this index = 0 -->
<!-- Spelling: query is not correctable -->
  <query>!hjksdf</query>
  <query_as_processed>!hjksdf</query_as_processed>
  <query_raw>!hjksdf</query_raw>
  <collection>doca-intranet-trimpush</collection>
<!-- Checking key string 'doca-intranet-trimpush;doca-intranet-trimpush;ACL:-1#84064;L:99;C:570#560#564#568#567#565;B:A#V;' against lock string 'doca-intranet-trimpush;L:5;C:570;CL:1259;RT:106#925#31;ACLD:-1;ACLR:-1' -->
<!-- Checking key string 'doca-intranet-trimpush;doca-intranet-trimpush;ACL:-1#84064;L:99;C:570#560#564#568#567#565;B:A#V;' against lock string 'doca-intranet-trimpush;L:5;C:570;CL:1170;RT:106#925#31;ACLD:-1;ACLR:-1' -->
<!-- Checking key string 'doca-intranet-trimpush;doca-intranet-trimpush;ACL:-1#84064;L:99;C:570#560#564#568#567#565;B:A#V;' against lock string 'doca-intranet-

Search is slow

Profile page element loads using Firebug

Load the search page in Firefox, using Firebug.  The 'Net' tab will display the load times of the various page elements.   In some cases, slow response times are caused by missing files or a slow web server, if you are referencing the client's Intranet server.  In this case, it is best to save the required CSS / image / Javascript files to the Funnelback server and then reference them locally (encountered at CASA).

TRIM related issues

• Check to make sure that the TRIM client is installed (and correct version)
• Check to make sure that the TRIM user can connect to TRIM (run the TRIM desktop client as the TRIM user and make sure you can connect and query TRIM).  If this doesn't work Funnelback won't be able to connect to TRIM.
• Ensure that Kerberos authentication is being used and that the servers are given delegation authority.
• Ensure that there is a post update command on the push collection to export the security info. (see https://docs.funnelback.com/15.4/trimpush_collection.html#recordtypesandclassificationsecurity)
• Ensure the user account under which Funnelback runs as the impersonated user permission in TRIM.

TRIMpush collection

• Can't start update from Admin UI (seems to start but trim.log has errors can't connect to database).
  
  • Not sure why this is - problems with impersonation.  Seeing error messages in log about not being able to connect to TRIM
• Can't start update from Scheduled Task (running as TRIM user)
  
  • Make sure the TRIM user has full control over the Funnelback folder (this seemed to fix the problem at AMSA) - before this change was made there was an error on the continuous updating about an inappropriate I/O Ctl operation.