Search

Your Notifications (0)

There are currently no notifications. You're all set!

Knowledge Base
ChemDraw and ChemOffice+ Products Signals Notebook E-Notebook and ChemBioOffice Enterprise Spotfire and Signals Spotfire Products Image Artist Spectrus, Percepta, Katalyst, Luminata and more
Downloads
Downloads
Community
Ideas Portal Product Basics
About Support
Legal Resources Support and Maintenance Plans Product Life Cycle Support News
Contact Support

How to test if Kerberos delegation is setup correctly on the Spotfire server and Web player in v7.5 and newer

Kisiel, Pawel
  • Updated
Date Posted:
Product: TIBCO Spotfire®

Problem:

How to test if Kerberos delegation is setup correctly on the Spotfire server and Web player in v7.5 and newer


Solution:

If login to the Web player does not work and the end user get's an error like "Internal Server Error", then chances are that the kerberos delegation setup is not correct. 

By doing the test described in the Resolution section, you will know if there is a problem with the Kerberos setup of the Spotfire server and/or Web Player without involving any data sources or connectors.
While there can be many reasons for the failure, it is important to use the following described first step to make sure that Kerberos is actually working all the way from the Spotfire server to the Web Player before troubleshooting any data source or connector.

Even though the Spotfire environment Kerberos setup might not be correct, it is still possible to successfully login to the Web Player and open analysis files that does NOT require any kerberos delegation. The reason for this is the default behavior of the Spotfire server which is to try to first use delegated Kerberos to login to the Web Player and if that fails it will silently fall back to using "backend trust", which is the standard way that the Spotfire server and the Web Player authenticates when not using Kerberos.
Since the Kerberos login attempt from the Spotfire server to the Web Player silently fails, the end user will not notice anything until trying to open an analysis using some Kerberos enabled data source or connector. Therefore the end user will often believe it is an error with the data source/connector, but actually the error already happened during the initial login and has nothing to do with the data source/connector set up.

Change in default behavior
In 7.7 we've introduce a new flag for the config-kerberos-auth command named "--worker-delegation-policy". This setting has 3 options:

  • REQUIRE - Do not connect to a service unless delegation succeeds.
  • TRY - Try delegation; if that fails, log in with impersonation.
  • NEVER - Do not attempt to delegate; always log in with impersonation.
In 7.5 and 7.6 this setting was hard coded to be set to "TRY".

In 7.7 and newer the default behavior has changed to "REQUIRE". This is even true for environments upgraded from 7.5 or 7.6 to 7.7 or newer.
So you can have a "working" kerberos environment in 7.5 or 7.6 which the starts failing after updating to 7.7 or newer

There's two ways to see what the "--worker-delegation-policy" is set to:
1. In the configuration.xml you'll see this:
**************************************************************************
<kerberos>
     <login-context>SpotfireKerberos</login-context>
     <refresh-tgt>false</refresh-tgt>
     <delegation-policy>TRY</delegation-policy>
   </kerberos>
**************************************************************************
You'll only see this if it has actively been set by. If it is NOT present in the configuration.xml file, then it means that it the Spotfire server is using the default "REQUIRED" setting.
 
2. In the server.log on debug level you can see 1 of these 3 possible entries depending on what the setting is set to:
DEBUG 2016-11-09T14:47:05,201+0100 [mblixter@gslab.local, #10, #39] wp.router.RequireDelegationStrategy: Logging in to [https://ref-nm75-krb.gslab.local:9501/f010725d-4680-4631-8e16-614d61802a2b]
 
DEBUG 2016-11-09T14:47:05,201+0100 [mblixter@gslab.local, #10, #39] wp.router.NoDelegationStrategy: Logging in to [https://ref-nm75-krb.gslab.local:9501/f010725d-4680-4631-8e16-614d61802a2b]
 
DEBUG 2016-11-09T14:47:05,201+0100 [mblixter@gslab.local, #10, #39] wp.router.TryDelegationStrategy: Logging in to [https://ref-nm75-krb.gslab.local:9501/f010725d-4680-4631-8e16-614d61802a2b]
 

The test to do, to leave out any data source or connector issues and just test the kerberos setup is:

  1. Enable debug logging on the Spotfire server.
  2. Login to the Spotfire server and go to "Analytics".
  3. Click on "New analysis".

As soon as you click on "New Analysis" the Spotfire server will try to login to the Web player using Kerberos, and you will see the below entries in the server.log log file on the Spotfire server.
If you see the failed login attempt entries then you need to troubleshoot the Kerberos setup for the environment.

Failed login attempt:
If the logging level is set to INFO:
**************************************************************************
ERROR 2016-09-22T16:46:37,506+0200 [mblixter@gslab.local, #22640, #199416] the Web player.router.DelegatingStrategy: Kerberos login to ref-nm75-krb.gslab.local failed
**************************************************************************

If the logging level is set to DEBUG:
**************************************************************************
ERROR 2016-09-22T16:46:37,506+0200 [mblixter@gslab.local, #22640, #199416] the Web player.router.DelegatingStrategy: Kerberos login to ref-nm75-krb.gslab.local failed
............................
DEBUG 2016-09-22T16:46:37,771+0200 [mblixter@gslab.local, #22640, #199416] the Web player.router.TryDelegationStrategy: Could not log in to [https://ref-nm75-krb.gslab.local:9501/20da1bbf-7bdf-49f9-aea8-b1e922913241], reverting to backend trust with impersonation
DEBUG 2016-09-22T16:46:37,771+0200 [mblixter@gslab.local, #22640, #199416] the Web player.router.NoDelegationStrategy: Logging in to [https://ref-nm75-krb.gslab.local:9501/20da1bbf-7bdf-49f9-aea8-b1e922913241]
**************************************************************************

Successful login (Only captured in DEBUG mode).
**************************************************************************
DEBUG 2016-09-22T16:41:45,234+0200 [unknown, #22632, #199297] server.security.KerberosAuthenticator: The service ticket for 'mblixter@GSLAB.LOCAL' is forwardable
DEBUG 2016-09-22T16:41:45,234+0200 [unknown, #22632, #199297] server.security.KerberosAuthenticator: Authentication handshake completed for principal 'mblixter@GSLAB.LOCAL'
DEBUG 2016-09-22T16:41:45,234+0200 [unknown, #22632, #199297] server.security.KerberosAuthenticator: Successfully authenticated user 'mblixter@GSLAB.LOCAL' with GSS credentials
**************************************************************************


Common configuration errors.
**************************************************************************

  • "forwardable=true" has not been added to the "libdefaults" section of the krb5.conf file as shown in the manual https://docs.tibco.com/pub/spotfire_server/7.8.0/doc/html/TIB_sfire_server_tsas_admin_help/GUID-1E941678-DDED-4CEB-917D-A58FC4EBF3B3.html
 
  • The Spotfire server service account is set to contained delegation while the Web Player service account(the account running the node manager service) is set to unconstrained delegation.This is not a working setup as you start having a locked down Kerberos ticket on the Spotfire server using constrained delegation and later when the Spotfire server tries to login to the Web Player which is set to unconstrained delegation, you try to create a Kerberos ticket with less security since it is using unconstrained delegation.
    This is not a limitation in Spotfire but how Kerberos works.
 
  • Delegation rights are not set for the Spotfire server service account and/or the Web Player service account. It is important that delegation rights be granted on both service accounts. If the Node Manager service is running as the default "Local system", it is the computer account that needs to have the delegation rights, otherwise it is the user account running the service.
   
  • The Node Manager service used to be running as a user and SPN's have been registered to that user, but now the service is running as "local system". It is important to remember to delete any SPN's for the Node Manager registered on a user account when running the service as "Local system".

Related articles

Comments

0 comments

Article is closed for comments.