HCL Connections & Kerberos Authentication Protocol Issue

After implementing Kerberos Authentication protocol for HCL Connections, as described in the official documentation (HCL Connections and IBM WebSphere documentation) and restarting the whole environment, the “synchronization status” of the Nodes in the IBM WebSphere ISC Console appeared to be “unknown”. All the HCL Connections Applications were running, there were no errors in GUI and the SSO was working without any issues. From the logs of the node agents we could see that the synchronization with the deployment manager was taking place and completing successfully, only in the “SystemOut.log” of the WepSphere deployment manager I found the following error message:

000015c Krb5WSSecurit E SECJ9314E: An unexpected exception occurred when trying to run initSecContext() method : GSSException: org.ietf.jgss.GSSException, major code: 11, minor code: 41

major string: General failure, unspecified at GSSAPI level
minor string: Kerberos error formatting credential for delegation: 41
at com.ibm.security.jgss.i18n.I18NException.throwGSSException(Unknown Source)
at com.ibm.security.jgss.mech.krb5.g.a(Unknown Source)
at com.ibm.security.jgss.mech.krb5.g.a(Unknown Source)
at com.ibm.security.jgss.mech.krb5.g.initSecContext(Unknown Source)
at com.ibm.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at com.ibm.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at com.ibm.ISecurityLocalObjectTokenBaseImpl.Krb5WSSecurityContextImpl$1.run(Krb5WSSecurityContextImpl.java:508)
at java.security.AccessController.doPrivileged(AccessController.java:770)
at javax.security.auth.Subject.doAs(Subject.java:570)
at com.ibm.ISecurityLocalObjectTokenBaseImpl.Krb5WSSecurityContextImpl.initSecContext(Krb5WSSecurityContextImpl.java:273)
at com.ibm.ISecurityLocalObjectTokenBaseImpl.Krb5WSSecurityContextImpl.initSecContext(Krb5WSSecurityContextImpl.java:157)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.processInternal(SOAPConnectorClient.java:1285)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.getSecurityHeader(SOAPConnectorClient.java:1095)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:783)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:697)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:687)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.queryNames(SOAPConnectorClient.java:599)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:524)
at com.sun.proxy.$Proxy40.queryNames(Unknown Source)
at com.ibm.ws.management.AdminClientImpl.queryNames(AdminClientImpl.java:108)
at com.ibm.ws.management.AdminServiceImpl.queryNames(AdminServiceImpl.java:679)
at com.ibm.ws.management.connector.AdminServiceDelegator.queryNames(AdminServiceDelegator.java:113)
at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at com.ibm.ws.management.connector.soap.SOAPConnector.invoke(SOAPConnector.java:503)
at com.ibm.ws.management.connector.soap.SOAPConnector.service(SOAPConnector.java:335)
at com.ibm.ws.management.connector.soap.SOAPConnection.handleRequest(SOAPConnection.java:65)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:733)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:522)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892)

After a quick Google search I found that this boils down to a problem with a hostname defined or spelled in upper case letters. As described in the following article:


This article also mentions a custom variable which could be set to remedy this issue.

But before trying the custom variable out, I wanted to make sure that this was really the issue. I checked the DNS Server and all SPN records, I could not find any issues there. The output of the “hostname” and “hostnamectl” commands (the whole environment is running on RHEL), were all returning the hostname written in (all) lowercase characters. Only when looking into the “hosts” file of the deployment manager I could find the issue, there was a “” entry stylized in “CamelCase”. I replaced the upper case letters in the “hosts” file with lower case letters and as soon as I have done that, all the nodes in the ISC console had the status “synchronized” and the error mentioned above did not appear anymore. The custom variable was not needed.

I hope this saves you some time! 🙂

HCL Sametime 11 – SSO between ST WebClient and iNotes/Verse on-Premises

You can integrate HCL iNotes and/or HCL Verse on-Premises, with Sametime 11 via ST Proxy server, the same way the integration was done with Sametime Version 9.0.1.

But before you can integrate the products mentioned above, you have to configure Single-Sign-On between Sametime WeClient and iNotes/VoP.

With Sametime version 9.0.1, you would export the LTPA Token from Websphere Application Server and import it in the Domino “Web SSO Configuration” document of the iNotes/VoP server and Sametime Community Server. Thus making sure that all components involved are using the same LTPA Token.

But in the Sametime Version 11, we do not have any WebSphere components. So, you just have to make sure that the Sametime Community and iNotes/VoP servers are using the same LTPA Token. Either export the LTPA Token from the old Sametime environment or any other existing WebSphere server and import it in the relevant Domino “Web SSO Configuration” documents. After restarting all components involved, the SSO should be working and you can proceed with integrating Sametime with iNotes and/or Verse on-Premises.

Domino AppDev Pack – Obstacles in using IAM Server for Authentication with WordPress, Drupal & Co.

One of our customers would like to use Domino as a User repository to Authenticate his users against services like WordPress and Drupal. The first thing that crossed my mind was Domino AppDev Pack and OAuth 2 Protocol. We decided to Deploy the AppDev Pack 1.0.1 (later on I upgraded the package to the 1.0.2 version) in a test environment and test this out.

The deployment is not that hard, the preparation of SSL Certificates is the key. For the Proton Task you need to create a self-signed certificate and generate some user certificates using the same CA you created for the Proton task. For everything else, you need a valid public SSL Certificate (including the client Application, WordPress for example). A big thumbs up for my colleague Christian Brandlehner for the heads-up. This is the first thing to keep in mind.

I am thinking about posting a step-by-step guide on how to deploy the environment we needed, so let me know if you are interested.

My first big issue was finding a WordPress Plugin which we were able to use with Domino IAM as endpoint. Most of the plugins available in the WordPress store can not be used in that regard. For me, only the WordPress plugin from MiniOrange was a viable option, they also have an awesome support.

After choosing and configuring the plugin I started getting various errors, like “client authentication failed” or “callback URL mismatch“. I contacted Heiko Vogt who helped me with troubleshooting, but after a some time I opened a case at HCL Support site. Here I got the information that most of the third party Software or Plugins for OAuth 2 will fail if there is a “+” or “%” sign in the Client Secret (this is by no means a bug or error at IAM component). That was the next challenge, because you can not restrict the Domino IAM on which characters to use when creating a Client Secret for the OAuth mechanism. Here you have to be patient and generate a few Applications on IAM until you get one without “+” or “%” characters in the Client Secret.

One more thing, you have to make sure that the “Callback URL” is the same in IAM Application definition and in the WordPress plugin, including any trailing slashes, this is the reason for “callback URL mismatch” error.

After a client secret with which the plugin could work was generated, we have hit the next problem, the Plugin and the OAuth Authentication works, but after a user logs in, the IAM is only sending “sub” and “accountId” user attributes to the WordPress Server. The issue here is that the free version of the MiniOrange Plugin only supports “mail” attribute at this point, the support is working on a trial version which we could try out with IAM found in the AppDev Pack.

The screenshot above shows a working configuration of MiniOrange Plugin.

In the next step, we would like to display and make the data editable, in Drupal for example, based on the Access each individual user has. We will see how that goes, but now we are confident that we can make it happen.


We got the authentication to work, Domino Users can log in, via IAM on the WordPress site! As mentioned we needed the Enterprise Version of the MiniOrange OAuth Plugin for WordPress.

Tips about Configuring IBM Connections to work with SPNEGO as Authentication Mechanism

Recently a customer asked me to review his Connections environment and implement SSO via SPNEGO. He started implementing it, but he couldn´t make to work, so he wanted me to pick up where he left it and make it work. I had a fair share of troubles to make it work and along the way I found some “typical” problems, so I thought I share these issues (and some other I had in the past) with you and hopefully save you some time.

Invest time in reading the Documentation about the Technology you plan to use

On the second thought invest a lot of time. The configuration will make sense only if you know the basics about Kerberos, SPNEGO and WebSphere Security in general. It will also help you a great deal troubleshooting and things like a WireShark trace (yes it may come all the way to that) will make much more sense. I strongly urge you to read the following article:


I never found a better article explaining how SPNEGO works in combination with WebSphere, it´s old, but it´s good.

I also recommend using the WebSphere documentation instead of Connections documentation (where it makes sense of course), I think that it is generally more in depth and more up to date. Which is OK I guess because Implementing SPNEGO has a lot more to do with WebSphere than with Connections Applications.

Plan Accordingly

Make sure your environment is up to date and there are no discrepancies between the Test and Production environment (a Test environment is essential). And keep it that way, I mean if you hit a “brick wall” in the Test Environment, do not go ahead and update the Production because a new Update came out. This will save you a lot of headache. Different versions mean different problems, so the chances are you will be trying to solve different problems in the Production than in the Test environment, when implementing SPNEGO, while the Production is down and someone is waiting for the whole thing to go online again.

Make sure Test and Production environments are the same

Here is where the details matter, I know that it is not always possible to have the exact same copy of a Production environment as a Test environment, but make sure that at least the things like DNS, Shares, User Access Rights… are the same as in Production. Difference between “CNAME” Alias and a “Host (A)” Record can have a lot of impact.

We had an issue, this will surely be a plague of the Test Environments, where the WebSphere Server Hostname, Primary Administration User and the URL for Connections Access, had a “Name-Clash” (as described in the URL pasted above) so make sure you check that and/or consider when building a Test environment.

Do it Step by Step

    I have made a mistake doing to many configuration changes at once, which essentially made it impossible to discover which part of the configuration led to an error. SPNEGO Implementation can be a combination of many different Configuration changes like: Primary Administrative User change, DNS changes and so on. So as my friend Martin Leyrer advised me, split the configuration in small steps/tasks, do one step, resync, restart and test and only after you are 100% happy with the change proceed with the next step.

Do you really need Kerberos?

As much as I know, SPNEGO is a “web friendly” version of Kerberos, right? So, it always made sense for me to do the Kerberos Configuration part in WebSphere before continuing with the SPNEGO part. Well I was wrong, the only Use-Case where you will need Kerberos implemented for IBM Connections is when you want to use IBM Connections Mail Plug-In with Exchange, which is not developed for Connections 6, so there´s that…

If you just want to achieve SSO from a Domain joined PC, then SPNEGO part will be sufficient. In that constellation Kerberos could just be another source of issues as Charlie Price made me realize that two months ago. 😀

LTPA Errors going through the roof

    We had an issue with LTPA, basically everything we tried to do in Connections GUI produced a mass of LTPA Errors in the logs. I tried everything, regenerating the LTPA Keys and so on, I contacted the support team, but we could not solve the issue. So, I asked Sharon Bellamy James for advice and she told me to export the LTPA Token from WebSphere and import it again, this solved that issue. The GUI looked much better and there were no LTPA Errors anymore.

Service Principal Name

When creating a Service Principal Name, never use “HTTPS/” in the “KTPASS” command, even though you are accessing Connections via “HTTPS”, only use “HTTP/”. For Examle:

ktpass -out c:\Node1.keytab –princ HTTP/connections.axians.local@AXIANS.LOCAL -mapuser connections_user -mapOp set –pass Password1 -ptype KRB5_NT_PRINCIPAL

If you need more than one keytab files and Service Principal Names, use a separate AD User for every one of them.

Delegation User Setting

    This is quite easy to forget, no matter what you do, Kerberos won´t work if your Service User Account used in the “KTPASS” command does not have the following setting set:

Although, I am not 100% sure you need to do this when you are Configuring SPNEGO without doing the Kerberos part in WebSphere. I will surely test this next time when I have a chance.

Disable TAI Authentication

    For SPNEGO to work with WebSphere as it should, you need to disable TAI Authentication:

Go to Security –> Global Security –> Custom Properties

Than enter the following:






I hope this is going to help someone, if you have any Tipps of your own, please share them in the comments below.