HCL Domino – Directory Assistance – Access to Active Directory via LDAPs

In order to re-configure the existing HCL Domino Directory Assistance document for accessing the user data over encrypted LDAP connection or LDAPs you have to do the following:

1. Create a Domino keyring file for the source Domino server.

Generally there are many good guides on the internet for doing this, personally, I like the following articles:

https://ds_infolib.hcltechsw.com/ldd/dominowiki.nsf/dx/3rd_Party_SHA-2_with_OpenSSL_and_kyrtool?OpenDocument&sa=true

Generating a keyring file with a third party CA SHA-2 cert using OpenSSL and KYRTool on a Windows workstation

https://ds_infolib.hcltechsw.com/ldd/dominowiki.nsf/dx/Self-signed_SHA-2_with_OpenSSL_and_kyrtool?OpenDocument&sa=true

Generating a keyring file with a self-signed SHA-2 cert using OpenSSL and kyrtool

Personally, I advise you to always use an official certificate, any well known third party CA or Let’s Encrypt certificates, which by the way are free, will do. This will save you some pain in the long run.

2. Add the personal certificate and/or CA certificate to the Domino keyring file of the Active Directory server you want to access.

You can do this in the same manner as adding the Domino root or personal certificate in the guides mentioned above. If possible, I would always add the personal and the root certificate of the AD target server, just to be sure that the trust will be established successfully. Just make sure to set a reminder to change the certificates mentioned before they expire. 🙂

3. Add the newly created Domino keyring file to the Domino Server document

Copy the Domino keyring file, including the stash file (.sth) to the Domino Data folder and reference it in the Domino server document.

4. Import the root and personal certificate of the Active Directory server to the Domino Directory

Export the Active Directory root and personal certificates as “.cert”, Base-64 encoded, and import them to the Domino Directory.

5. Activate encryption in the Domino Directory Assistance document.

Set the “Channel encryption” to “SSL”, I advise you to set the other settings to be “less restrictive”, you can fine tune those after you made sure that basics are working.

Do not worry if clicking the “Verify” button returns an error. I think that there is a bug in the Domino 11 DA Template. I was always getting the following error “Connection to host ‘<hostname>:636’ failed”.

6. Restart the Domino Server and verify.

After the Domino Server restart you can verify that the Microsoft Active Directory user data can be accessed via HCL Domino Directory Assistance by issuing the command “show xdir“, the result should be something like the following:

This is everything you have to do to access the user data over encrypted LDAP connection using HCL Domino Directory Assistance. I hope this helps.

HCL Domino & ADFS – SSO Suddenly stops working

If you are using ADFS with Domino as a Single Sign-On solution, and you get a call from a friendly user telling you that Single Sign-On stopped working, check if you are seeing the following error on the HCL Domino server console:

SECCheckAndParseSAMLResponse> VerifyAssertionSignature : Document has been modified or corrupted since signed! (signature)

If that is the case, check the expiration date of the “Token-decrypting” and “Token-signing” certificate on the ADFS Server. The easiest way to do that is using the ADFS Management Snap-in or ADFS Management Console.

If the secondary “Token-decrypting” and “Token-signing” is going to expire in two weeks or fewer and the ADFS certificate rollover has started, than you have to reimport the FederationMetadata.xml into your HCL Domino servers. Just download the new “FederationMetadata.xml” file according to the official documentation and re-import it into the existing IdP Configuration documents (you may have more than one).

After importing the new “FederationMetadata.xml” file, just refresh the HTTP configuration and restart the HTTP Task on the Domino Server. You can do that using the “tell http refresh” and “tell http restart” commands respectively. That should be it, your SSO solution should be back in business.

UPDATE

As Patrick Schneider mentioned, in the comment section of this post, you can increase the lifetime of the signing and decrypting certificates:

You can define the certificate duration in ADFS using PowerShell (10 years: Set-ADFSProperties -CertificateDuration 3650 and force a manual Certificate Rollover, see https://xenit.se/tech-blog/changing-default-adfs-decrypt-signing-certificate-lifetime-from-1-year-to-x-years/ )
Be aware that this also affect other services that are using ADFS.

@Patrick Schneider, thank you very much for this valuable information!

HCL Domino – Default LTPA Token

I came across an HCL Domino environment with HCL Sametime where the Sametime embedded clients were logging in via LTPA but with a different authentication server than the Sametime Community server.

As you can imagine, this was important to keep in mind during a Sametime migration. The Domino server used for authenticating Sametime clients is also hosting multiple websites and using multiple LTPA tokens, so the question was, which LTPA token is actually used for authenticating the Sametime clients.

After some searching I asked a good friend, Herwig W. Schauer, and he knew the answer. The LTPA token used for authenticatication of Sametime embedded clients is the default LTPA token, which is found inside the “($WebSSOConfigs)” hidden view of the Domino directory.

To access this view, hold “CTRL” and “Shift” keys while opening the “names.nsf” database. I hope this saves someone some time. 🙂

Creating an LTPA Token – Without WAS Network Deployment Server

Recently I was installing an HCL Sametime 11 environment from scratch. I always tend to implement a single LTPA Token across the Domino, Sametime and/or Connections environment. It is also a very good idea to use only the LTPA Token version 2, as it is more secure, but this also means that the LTPA Token has to be created by a WebSphere server.

Usually this is not a problem, because most of my customers have HCL Connections or an older version of Sametime already deployed, which means that they are also using WebSphere Application Server Network Deployment.

But this customer only had Domino, and a new installation of the WAS Network Deployment Server, solely to create a new LTPA Token and scrap it afterwards would take me too much time.

My friend Herwig W. Schauer gave me tip that the same could be done with WebSphere Liberty server, which is a lot faster.

Just download the latest version of WebSphere Application Liberty Server, which is free, from the IBM Website, I used the ZIP Install Package for Windows OS.

Just extract the downloaded package to the directory of your choice and open the “server.xml” file, which can be found under “<was_liberty_package>\wlp\usr\servers\defaultServer”, in text editor. At the line number 17, inside the “<ltpa>” tag, edit the “keyFileName” and “keysPassword” parameter, as shown in the screenshot below:

Afterwards, just start the WAS Liberty by executing the “server.bat” script.

“<was_liberty_package>\wlp\bin>server.bat start“

Just as in the screenshot below:

As soon as you get the server fired up, a new LTPA token will be generated in “<was_liberty_package>\wlp\usr\servers\defaultServer” directory, with the name and password you specified in the “server.xml” file.

That’s it, you can take the newly generated LTPA token and import it to Domino.

HCL Nomad: Features & Benefits Guide

Some time ago, HCL Published a really cool “one-pager” document summarizing the most important features of HCL Nomad. I find this extremely useful, take a look how you can extend and improve your existing environment!

HCL Nomad: Features & Benefits Guide

How to Make Domino Deployment and Monitoring Radically Easier – Webinar

Make sure to register for the “How to Make Domino Deployment and Monitoring Radically Easier” Webinar taking place tomorrow at 3:00 PM – 4:00 PM CET.

Join this session to learn how to create a controlled, efficient Domino deployment (regardless of where you want your servers) powered by Panopta, our new partner. You’ll learn how to get complete visibility of your Domino servers’ key health metrics in easy to use dashboards, ensure the right person is notified in case of any health or performance issues, and solve problems with automated remediation instead of manual intervention. And, with much of the configuration done out of the box, you’ll learn how to get this all up and running quickly!

How to Make Domino Deployment and Monitoring Radically Easier – Registration form

Domino 10.0.1 – IdP Catalog Database and the German Language Pack

If you are running Domino 10.0.1 Servers with German Language Pack and trying to implement SAML authentication mechanism, make sure to switch to the English version of the IdP Catalog database.

Or else you could run into the problem with creating the Service Provider Certificate by using the “Create SP Certificate” button in the “IdP Configuration” document, this action will create the certificate, but it will not create the “ServiceProvider.xml” file. When doing so, I got the following error:

Agent message: CreateIdPXML error 91 (Object variable not set) line 19 Please pass this error message to your notes admin

We had this issue in two customer environments, using Domino Version 10.0.1 to 10.0.1 FP3.

HCL Domino AppDev Pack – IAM System Requirements

As of now, there are no separate System Requirements listed for IAM component, of the Domino AppDev Pack, in the official documentation.

I opened a support case regarding this and got the information that the IAM component will run on any OS where the Node.js, version which is mentioned in the official documentation, will run.

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.

Update

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.