Authentication

This section lists the common authentication issues. If your issue is not listed below or if the solution provided does not suffice, contact TIBCO Support.

LDAP Authentication issues
Before you Begin

  • Work with the LDAP Admin to get the LDAP structure / Ldif file for users to be added.

  • Read the cs_server.log generated after turning on DEBUG for LDAP.

Possible Causes

  • ldap.properties file is not configured right.

  • The filters used in the LDAP URL/login credentials may be incorrect.

  • Port 389 for LDAP and port 636 for LDAPs may be blocked.

Solution

Follow one ore more of the solutions given below.

  • Work with the LDAP Admin team to get the ldap filters that need to be updated in ldap.properties file.

  • Review the LDAP DEBUG logs for the flow of the authentication and make the necessary changes to the ldap.properties file/ URL/login.

  • Restart TDV Server to make sure the updated ldap.properties file takes into effect.

  • If you are using LDAPs, then make sure to import the required right LDAP Server certificates into the cis_server_truststore.jks (TDV Server truststore).

References

https://support.tibco.com/s/article/000045564

https://support.tibco.com/s/article/000051747

https://support.tibco.com/s/article/000052459

Unable to configure LDAPS
Before you Begin

Gather the following information:

  • The complete LDAPs URL, login and password from the LDAP admin.

  • The complete certificate chain from the LDAP Admin.

  • cs_server.log to review for any errors that explain the reason for the failure of LDAPs configurtaion.

Possible Cause

  • The LDAP certificates are not imported into the cis_server_truststore.

  • The complete certificate chain is missing in the cis_server_truststore.

  • Correct certificates are not imported.

  • The LDAPs URL is not correct.

  • The ldap.properties file must be missing the correct user/group filters.

Solution

  • Review the cs_server.log for the error cause (The most common error encountered is the "PKIX certificate not found" error (or) any other error that explains the reason for why the certificate import did not help).

  • Check with the LDAP admin and get the right certificates to import into the cis_server_truststore.jks file. A TDV server restart after the import would be helpful

References

https://support.tibco.com/s/article/000041489

Login duration for AD/LDAP user accounts is high
Before you Begin

Gather the following information:

  • LDAP URL information in TDV Manager domain configuration.

  • ldap.properties file.

Possible Cause

  • The user may not be part of the local tree/domain of the AD/LDAP Server configured in TDV Manager. Hence a referral lookup is made at the forest level to retrieve the information, resulting in longer duration to complete the request.

  • The search catalog is too wide for the organization/tree.

Solution

  • Querying global catalog in place of a local one may yield faster response time. Local ports are 389 (ldap), 636 (ldaps). Global ports are 3268 (ldap), 3269 (ldaps).

  • Narrow down the search criteria to add more filters for the group/users search in the ldap.properties file.

How to enable debug logging to troubleshoot Kerberos Authentication issues in TDV?

To enable Kerberos debug logging :

  1. Launch TDV Studio and Navigate to Administration tab > Configuration panel >Server >Configuration >Security >Authentication >Kerberos >Debug Output Kerberos Authentication Enabled and Set this to true.

  2. This will log Debug entries in the cs_server.out or cs_monitor.out file.

  3. The Kerberos debug trace will be written to one of these logs.

Login issues using Kerberos authentication
Before you Begin

Gather the following information:

  • TDV Server logs directory with SSL and Kerberos debug.

  • SPN, keytab and krb5 config files.

  • ktpass command used in generating the keytab file and setspn commands used for the SPN.

  • Fully Qualfied Domain name of the machine where TDV Server is installed.

Example commands to gather this information: 

ktpass -princ host/computer.contoso.com@CONTOSO.COM -mapUser <nameOfTheKerberosPrincipal> -mapOp set -pass <password> -crypto ALL -pType KRB5_NT_PRINCIPAL -in C:\temp\tdv.keytab -out C:\temp\krb5.keytab
setspn -L <Hostname>
klist –k –e -K -t FILE:<path_To_KeyTab_File>
Possible Cause

  • The crypto flag used in generating the keytab file did not allow "ALL" crypto and associated to a few.

  • krb5 file is not built with Realms sub section.

  • The SPN is not configured correctly.

  • The server time for machine that hosts the TDV Servers, Studio/Client machines and KDC Server are not set to follow the same time protocol.

Solution

  • The krb5.conf/ini file has default_tgt_enctypes, default_tkt_enctypes parameter. This should match the "crypto" flag cipher used in generating the keytab file, if anything other than ALL was used.

  • The krb5.conf/ini file realms should match the domain used for the SPN

  • The SPN should be of the format HTTP/<FullyQualifiedDomainName_of_the_host_machine>@DOMAIN (Note: the domain must be in upper case).

  • The TDV Server, client machines and KDC server times should not differ by more than 2 minutes. It is suggested that the TDV Server and Clients use the KDC Server time by removing all time protocol in ntp.conf file.

References

https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html#realms

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass

Error when logging into TDV Studio using the OAuth Azure domain
Solution

In the manifest file for the application registered in Azure, the following line needs to be modified:

accessTokenAcceptedVersion:2

Note: By default, this value is set to 'null' in the manifest file.The accessTokenAcceptedVersion value is set to 2 so that the issuer will become login.microsoft.com instead of sts.windows.net.