Sametime Version: 12.0.3non containerized Chat Windows Operating System:Windows Server 2025
Hello all,
I just installed Sametime 12.0.3 “non containerized” on Windows, to test before deploying.
I’m facing a curious behavior : it works fine from Notes embedded client and Sametime Connect, but I’m unable to log-in from web interface : the authentication form display an “invalid credentials” error, but the server logs a valid login, then a “normal” logout, 46 seconds later…
Thank you for reaching out regarding the “invalid credentials” error you are encountering with the Sametime 12.0.3 non-containerized installation on Windows Server 2025. It is interesting that the server logs indicate a successful login and subsequent normal logout while the web interface displays an error.
To investigate this further, we need a bit more information to narrow down the potential causes:
Web Interface Details: Which specific web interface are you using (e.g., the standalone Sametime Web Chat client at /chat, Sametime integrated with HCL Verse, or Sametime in iNotes)?
Browser Information: Which web browser (including version) are you using to test this? Does the behavior persist across different browsers (e.g., Chrome, Firefox, or Edge)?
Authentication Method: Are you using standard username/password authentication, or have you configured Single Sign-On (SSO) with LTPA tokens?
Initial Troubleshooting Items to Collect
If you have not already done so, please check or collect the following:
Browser Console Logs: Check the browser’s developer tools (F12) Console and Network tabs during a login attempt to see if there are any specific errors (like 401 Unauthorized or CORS issues) not reflected in the server’s general log.
Sametime.ini Configuration: Verify if ST_AUTH_TOKEN is set correctly. For non-containerized installations where LTPA is used, it often needs to be set to ST_AUTH_TOKEN=Fork:Jwt,Ltpa.
Trace Logs: If possible, enable VP_TRACE_ALL=1 and VP_LDAP_TRACE=1 in your sametime.ini, restart the service, and collect the contents of the trace folder after a failed attempt.
Given the complexities of a new non-containerized deployment, this issue would be best handled by opening a formal support case. This will allow for a more effective exchange of logs, such as a HAR file from the browser and your configuration files (sametime.ini, stcommunityconfig.xml), which are necessary to pinpoint why the web client is not successfully consuming the session that the server seems to be creating.
Thank you so much for your answer. I’m sorry for the long time from my initial post, I took a long week off.
To give you the details you asked :
Web Interface Details: Sametime native web chat from a browser (Firefox and Edge give the same result) : https:///chat.
Authentication fails from Sametime integrated with Verse, too.
Browser Information: I test with up-to-date Firefox and Edge (automatic updates).
Authentication method: I configured LTPA, which works fine from Notes embedded client (not the automatic logon, but it will be another post !). For the web, I want to use simple username/password based on LDAP directory (Domino Server 14.5 FP1).
I also opened a support case, but “HCL (still) working”… I think I’ll wait for an answer from the support then report the solution here… unless someone already have it !
Finally I found where was the issue. I just added STLDAP_TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 in sametime.ini, [Config] section, just under the three other parameters:
Surprisingly without this cipher specification, authentication works fine for all clients, but web-based ones (standalone https://…/chat, Verse and iNotes integration).