Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Important security change Domino 11.0.1 FP3 and 12.0 on Windows

Daniel Nashed  31 May 2021 06:59:47

The following change has been introduced in 11.0.1 FP3 and higher on Windows.
See this technote for all details. But let me explain what this means for you if you are using add-on software.


https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0090343


Other platforms like Linux/UNIX and OS400 always enforced this type of security.
On Windows is was still possible to start an additional process with a different user and interact with the Domino server.

I have never been a fan of starting processes from outside the server.
The best way to invoke any add-on application is to run it from the server console or implement and configure it as a servertask.

Not all applications and use cases might allow this type of integration.
But now you have to start the new process with the exact same environment / user, than you process.


In consequence on a server usually started with the SYSTEM account, you can only use task/external code like virus scanners and backup, if the task is also started with the SYSTEM account.
There are rare cases where a server is started with a different account. In that case the additional processes also need to be started by this exact same user.
This makes a lot of sense and will also prevent instability issues.

There is a way to configure additional accounts with access to the server described in the technote.
But I would really try to configure your environment in a consistent way to not need two different accounts.

For details read the TN. If you have questions let me know. I might update my blog post with a FAQ based on your questions..


Update 31.5.2021 19:00:


After off-line discussion with a couple of partners, I had a quick look for work-arounds on the Microsoft side to see what would be the easiest way to keep their applications running.


It turned out that the system account isn't really as secure as one would think.

I never looked into how I could execute a program using the system account. And I thought I would need to write an own service.


After a minute consulting the web I was surprised there is very easy way to run commands as the local system account.


psexec.exe
from the famous SysInternal tools ->
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec provides the "-s" option.

So one use case an admin asked for was to run commands via Ansible scripts to shutdown and the HTTP task and restart it later.



psexec.exe -w c:\domino\bin -s "c:\domino\bin\nserver.exe" -c "tell http quit"



For tasks like a command-line restore there is even an interactive mode, which allows you to open a new command-line window with the system account.

See this example. When you run this shell, you can execute any command as system account.


psexec.exe -w -s -i cmd.exe


whoami

nt authority\system



Conclusion:


Windows is still not where Linux and Unix is from day one.

Linux and other Unix platforms are designed from ground up as multi-user and multi-tasking operating systems with very clear security models.


Domino always works in user mode. In fact you can't even start Domino using the root user.

Only some very restricted resources like kernel tuning and binding to restricted ports below 1024 require root permissions with binaries having the sticky bit set.


If you specify the right umask, all file permissions will be automatically correct and you could even run multiple partitions securely.


On Windows the only real security would be to completely restrict who can access the Windows machine.

And this might even be difficult in a Windows domain to restrict the number of admins with access to the Domino servers.



Another side comment -- sudo delegations for Domino admin tasks


As many of you know I am really a big Linux fan since day one. And the security model and the way to manage a Linux is much more clear than on Windows.


On Linux there is a very nice way to delegate system permissions.

The "sudo" command can be used to allow users and groups to execute certain commands with root permission.


So for example my Domino start is located in a read-only location which only root can write.

A Linux admin with root access could allow a normal user to just operate the Domino server levering the start script.

This would allow quite granular control on Linux level.


-- Daniel



Comments

1Christian Henseler  31.05.2021 9:34:01  Important security change Domino 11.0.1 FP3 and 12.0 on Windows

Thanks for sharing this, good to know.

I agree that it's best practice to execute processes from the server console or more general spoken in the context of the Domino Server account, e.g. via program document.

Does this also appy to 3rd party addons, e. g. when a restore is initiated using TSM UI/cmdline by an Administrator/Backup operator?

2Christian Henseler  31.05.2021 9:35:18  Important security change Domino 11.0.1 FP3 and 12.0 on Windows

Sorry, for my question, you've already mentioned my use case in your post.

3Benjamin Wolber  31.05.2021 17:56:32  Important security change Domino 11.0.1 FP3 and 12.0 on Windows

Thanks for this hint!

We also stumbled upon this issue - since upgrade from 11.0.1.2 to 11.0.1.3 Backup of databases and translocation via TSM/TDP was not working anymore.

TDP was not able to connect to Domino.

We opened a case with IBM regarding TSM and got a very very fast feedback with a solution working for us:

SHAREDMEMORYALLOWONLY Was not present, we set it to 0 and restarted Domino.

Though it is less secure as bypassing security measurements, we took this approach. Is working fine.

We also tried running the backup-jobs as User running Domino, this was also successful. But as we need to also start TSM GUI both as different user and elevated, we needed a not so elegant workaround.

Let me share the details from support.

(great support!! Thanks!!)

————————-

t seems that additional (more strict) rules have been applied in FP3 to access Domino API.

The user id must have right for Domino server as well as the Operating system.

Please check the setting of SHAREDMEMORY parameter in the notes.ini file.

If this SHAREDMEMORYALLOWONLY=1 this indicates that only the user who started the Domino Server has access.

Therefore, you will only be able to run the domdsmc commands as the user account that has started the Domino Server.

If it does not exist then by default it is set to 1.

Change SHAREDMEMORYALLOWONLY=0, restart the Domino server and check the issue.

Or you can also start backup jobs using the same account as Domino server and check the issue

Check article describing this issue which has been opened by HCL:

Standalone Domino processes may fail to start on Microsoft Windows

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0090343&sys_kb_id=0ace67511bc03050a67e9759bc4bcb61

I

4Jan  03.06.2021 12:28:32  Important security change Domino 11.0.1 FP3 and 12.0 on Windows

This change forces me to create the .ini file on all servers to still be able to run "kyrtool". Only annoying....

5Daniel Nashed  03.06.2021 12:32:44  Important security change Domino 11.0.1 FP3 and 12.0 on Windows

@Jan,

HCL has to take about security reports and there isn't anything that can be done to make it completely safe with Windows and the system account.

You can use the tool or you can just run the kyrtool from the server console with load kyrtool.

But in general in Domino V12 you should not need th kyrtool any more!

You can just switch to the CertMgr and import your existing keys into certstore.nsf automatically.

And you will never need any server task to be restarted for a certificate update.

But probably you are on 11.0.3 FP3? I just switched to 12.0.0 :-)

Domino V12 uses PEM as the new standard format and CertMgr and certstore.nsf make certfificate management a lot easier.

No more openssl command line or kyrtool needed ...

-- Daniel

Links

    Archives


    • [IBM Lotus Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]