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.
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.
One of our customers wants to implement Single-Sign-On for Notes Clients on Windows Operating Systems and in the future they plan to implement Smart Cards as a Login mechanism on Windows PCs.
Due to some misleading official articles, I was not sure if Smart Cards are supported with NSL or NFL. After a check with IBM Support, it turns out that Smart Cards are supported with Notes Shared Login and Notes Federated Login, as long as you do not use “Smart Card Protected ID” Feature.
So, as long you use Smart Cards solely for OS access/login you are good to go to use NSL or NFL for Notes SSO.
Important Notice: If you are using your Domino Server as an LDAP Directory for Connections and/or Sametime do not continue with the steps described further down.
If your Domino Server is exposed to the Internet, make sure that the Domino Directory or the “Names.nsf” database cannot be accessed via Web Browser, or at least certain fields which can be used to get the hash values of the Internet Passwords.
A while ago, we got contacted by a customer who found out that his Domino Servers are vulnerable to a certain exploit which allows an attacker to extract the hash values of HTTP Passwords, of every user in the Domino Directory. The mentioned vulnerability is documented as “CVE-2005-2428”, you can read all the details of the exploit in the article bellow:
EDIT: In a response to my post, Sven Hasselbach also wrote a post on his blog. It is very informative and detailed, he added Information I missed, so I would strongly urge you to read it. Furthermore the I would also like to add the comment from Christoph Stöttner:
I haven’t checked the authentication, but you can’t use LDAP any more (Softerra will present: The user has insufficient access rights!)! So even when Connections or Sametime User can authenticate (please double check), TDI will not read or update any user account, even worse with default settings in Connections TDISOL all your profiles get deactivated!
The mentioned vulnerability is from 2016! So nothing new. To get the hashes the attacker already need to have a valid login (or allowed anonymous access to your names)! Then he can grab the hashes. Afaik with “Use more secure internet passwords” and “Yes – Password verification compatible with Notes/Domino release 8.01 or greater” it’s not that easy to decrypt the hashes.
I think a way more important is proper ACL, a well-configured security tab in the server document and “Enforce server access settings: Yes” for all used protocols.
As described in the article, you could remedy this by hiding $dspHTTPPassword and HTTPPassword or, you could “block” the access to names.nsf via Web Browser completely. The only reliable way I could find, with the help of Roberto Boccadoro, to do this on Domino would be to set the following property:
I tested this in few environments, with SPNEGO and Web Federated Login enabled, and I could find no issues.
Thoughts about HCL Connections, Domino and Sametime 