Why does the connection fail from Spotfire Data Virtualization to the LDAP servers, after changing the DisplayName (DN) of the account?

Why does the connection fail from Spotfire Data Virtualization to the LDAP servers, after changing the DisplayName (DN) of the account?

book

Article ID: KB0137858

calendar_today

Updated On:

Products Versions
TIBCO Data Virtualization All supported Versions

Description

Spotfire Data Virtualization administrators may observe a sudden and complete failure of all LDAP and LDAPS connections. This failure prevents users from logging in and disrupts applications that rely on data from SDV, leading to a significant business impact. Even performing operations like editing the "Annotation' or creating a new LDAP/LDAPS domain fails with error:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ERROR [jetty thread pool-25606] 2025-07-17 03:15:22.477 +0200 AuthenticationFilter - [1209806149] Authorization failed: Invalid login attempt.  [security-1900202]
ERROR [jetty thread pool-25606] 2025-07-17 03:15:23.784 +0200 DefaultLdapDomainConnection - null
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0904AE, comment: AcceptSecurityContext error, data 52e, v3839 ]
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The error code 49 and the sub-code 52e are seen as part of the error.

This behavior can be confusing because in SDV the ldap.properties file is used to configure if the displayName or the sAMAccountName should be used for the lookup and this may be correctly configured to use a stable attribute, such as sAMAccountName, for authenticating users. Despite this, the connection still fails, indicating the problem lies with the initial bind process and not the subsequent user lookup operations.

Resolution

The root cause of this issue is the distinction between the initial LDAP bind connection and the subsequent user lookup process.

1. The Bind Connection: SDV first connects to the LDAP server using a specified service account to gain permission to search the directory. The credentials for this "bind account" are configured in the main LDAP domain settings in the SDV Web Manager, not in the ldap.properties file. This configuration often uses the service account's full Distinguished Name (DN), which contains the Common Name (CN). The CN is often identical to the account's DisplayName.

2. The User Lookup: Only after a successful bind does TDV use the rules defined in the ldap.properties file (e.g., abc.user.filter=...) to find and authenticate individual end-users based on attributes like sAMAccountName.

When the DisplayName of the bind account is altered in Active Directory, its CN also changes. This change invalidates the DN used in LDAP/LDAPS domain configuration, causing the initial bind connection to fail. Because the bind fails, TDV never proceeds to the user lookup step.

To prevent this issue and create a more resilient configuration, modify the bind account identifier in TDV to use a stable attribute that is not linked to the DisplayName.

Action Steps:

1. Log in to the Spotfire (TIBCO) Data Virtualization Web Manager.

2. Navigate to Configuration > Domain Management.

3. Select the LDAP domain that is experiencing the issue and click Edit.

4. In the domain configuration settings, locate the field for the bind account's username/Login.

5. Here, change the CN that has been configured, to the new CN, which will now allow TDV to search for the correct DN, or instead of using the DN, update the field to use the User Principal Name (UPN) of the service account. The UPN format is typically <service_account>@<your_domain.com>.

6. Enter the password for the service account and save the changes.

By using the UPN, the connection will no longer be dependent on the DisplayName or CN, preventing future authentication failures if those attributes are modified.

Issue/Introduction

When using Spotfire (formerly TIBCO) Data Virtualization (SDV), LDAP or LDAPS connections may fail after an LDAP administrator changes the DisplayName of the service account used for the connection. The reason is explained here.