HCL Connections Invite – Issues when using TDS/SDS as User Repository

Take care when deploying the HCL Connections Invite application using the TDS (Tivoli Directory Server)/SDS (IBM Security Directory Server) as user repository. The following information from the official documentation is wrong:

The following value includes the LDAP property used to map the user in LDAP to their Profiles GUID. In an Active Directory environment, for example, the default property is objectGUID. Other known defaults are entryuuid (IBM Security Director Integrator, formerly TDI),…

<profiles-connector>
             <entry>
                  <attributes>
                       <attribute>
                            <value>${ldap:objectGUID}</value>

First, the value of the Attribute in the “selfregistration-config.xml” is missing, this would be: “<key>com.ibm.snx_profiles.base.guid</key>”.

By reading the documentation, you would set the <value> parameter to ${ldap:entryuuid}, if you do that, you would get the following error:

00000660 SelfRegistrat W   Failed to get all the required attributes! required: ‘{​${​ldap:entryuuid}​=entryuuid, ${​ldap:sn}​=sn, ${​ldap:cn}​=cn}​’, received attributes: ‘{​sn=sn: Mail, cn=cn: <e-mail>}​’

The correct value for the parameter, when using TDS/SDS, would be “${ldap:ibm-entryuuid}”, so you should endup with the following:

<attribute>
                    <key>com.ibm.snx_profiles.base.guid</key>
                    <value>${ldap:ibm-entryuuid}</value>
                    <type>text</type>
                </attribute>

Although there are some comments in the “selfregistration-config.xml” showing the right information, a few colleagues/friends including me found them to be a bit “misleading”. This will surely be corrected in the future.

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:

https://www.ibm.com/support/pages/apar/PM66457

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 “127.0.1.1” 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 Notes Connections Plug-In – Login via SPNEGO not possible

If you are trying to use SPNEGO as the means for authenticating HCL Notes Connections Plug-In and you run into an issue, check if “Use the alias host name for the application server” option is used on Websphere Application Server and if that is the case try turning it off.

For some reason the HCL Notes Connections Plug-In cannot use SPNEGO authentication mechanism when this option is used on WAS. You can find this setting under “Global Security – Web and SIP security – SPNEGO web authentication”.

Depending on your DNS configuration and SPN entries created, this option may be needed for HCL Connections or other applications, so make sure you test everything appropriately after changing the SPNEGO settings.

HCL Connections – URL Preview Tip

If you have implemented or planing to implement the “URL Preview” feature for HCL Connections, make sure you import the Root Certificate for “Let’s Encrypt” certificate authority inside the java trust store.

By default, the root certificate of “Let’s Encrypt” certificate authority is not in the java trust store which the HCL Connections documentation suggests to use for URL Preview. Which means that if you do not import it manually, the URL preview won’t work for websites which are using “Let’s Encrypt” certificates.

HCL Connections Invite – Trace/Debug Parameters

If you are having issues with HCL Connections Invite, than the following Websphere debug or trace code might help:

com.ibm.lconn.registration.*=finest

HCL Connections Invite is assigned, per Default, to the WebSphere Homepage Cluster/Server. So this is where you have to set the parameter mentioned above.

This is how you can set the debug parameter during runtime. No restart needed.

HCL Connections – Configure access for the Tiny Editors Services through a HTTP proxy – Configuration/Documentation error

Take care when configuring access for the Tiny Editor through an HTTP proxy. The Documentation says to modify the “application.conf” in following manner:

ephox {
    proxy {
        http.proxyHost = someproxy.internal.corp
        http.proxyPort = 8080
        https.proxyHost = someproxy.internal.corp
        https.proxyPort = 8443
        http.nonProxyHosts = localhost|*.internal.corp
    }
}

If you follow the official documentation and do not set the values of “http.nonProxyHosts” in the double quotation marks the Tiny Editor WAS Application will start, but some features of Tiny Editor will not work (like Spellchecking). The correct will configuration looks like the following:

An example of proxy settings:

ephox {
    proxy {
        http.proxyHost = someproxy.internal.corp
        http.proxyPort = 8080
        https.proxyHost = someproxy.internal.corp
        https.proxyPort = 8443
        http.nonProxyHosts = "localhost|*.internal.corp"
    }
}

Hope this helps.

We Have Lost The “wasadmin” Account Password!

If you have lost the “wasadmin” account password or any other local WebSphere account, there is a rather simple way to recover it.

Just connect to the server where WebSphere Deployment Manager is running, via RDP or SSH, depending on the OS of the server, and open the “security.xml” file located under “<WebSphere_Installation_Directory>/AppServer/profiles/<Deployment_Manager_Profile>/config/cells/<Cell_Name>” for example “/opt/IBM/WebSphere/AppServer/profiles/ic-dmgr01/config/cells/ic-cell01”.

After that just search for the account name, for which you would like get the password, in the same line you should find the attribute “password”:

Then just copy the value of the “password” attribute, now we need to decode the xor encoded password. For that I am usually using the following Website: https://strelitzia.net/wasXORdecoder/wasXORdecoder.html

Just paste the encoded text and click the “decode” button, after that you should have the password.

HCL Connections 6.5 Installation – Community Highlights Database Missing

When creating Databases for HCL Connections 6.5 using the Database Wizard, you will find that the database “XCC” for the “Community Highlights” Application is missing. If you continue without it and you want to install all Connections Applications, you will get an error during the installation process stating that the Database for “Community Highlights” Application is missing.

To remedy this problem you will have to create the database manually, to do that, just extract the Package containing the Connections 6.5 Wizards, and navigate to the folder with the “icec” database scripts, for example:

“C:\temp\Connections_6.5_Wizards\Wizards\connections.sql\icec\db2”

In case you are using DB2, start the DB2 CMD as the DB2 Administrator and run the following commands:

db2 -tvf createDb.sql

db2 -tvf appGrants.sql

Please note that the script “appGrants.sql” allows the default Connections User, “LCUSER” to access the database. If you want to use this user to access the database, you are good to go.