Back by popular demand......

On Friday 29th of January I will be hosting an hour long webinar to provide some real-world proven tips and tricks on preventing and surviving a ransomware attack.

It's at 1pm Eastern time. To reserve a spot simply email

It could save you $100,000's.
Darren Duke   |   January 22 2021 09:39:26 AM   |    security    |   Comments [0]

This Friday 11th of December I will be hosting an hour long webinar to provide some real-world proven tips and tricks on preventing and surviving a ransomware attack.

It's at 1pm Eastern time. To reserve a spot simply email

It could save you $100,000's.
Darren Duke   |   December 9 2020 11:35:43 AM   |    security    |   Comments [0]

I do a fair bit of ADFS so I know my way around it pretty well. But when I have to delve into the world of ADFS Transforms I wake up in cold sweats. Here's the business case....we need to take the SAMAccount name of a user and truncate it to only the first eight characters in length before passing it off as the NameID to a 3rd party application. So truncate jhowstoday to jhowstod. Simple right?

Why the eight character limit I hear you ask? No idea. Must have been written in DOS.

I thought this would be pretty straight forward, but no. There are some examples in the internet about truncating in an ADFS transform using regex but none, absolutely none worked for me. After coming up with such a blank and then flailing around from more then a handful of hours I thought I would add it here in case anyone else has to stumble through the hell I just put myself through.....

Also, it doesn't seem to appear that SAMAccount name is exposed in ADFS as an incoming option, but UPN is (at least in 2012 R2). So now I need two transform rules, so yay!

OK, here's the finished product, we'll pull apart each claim. The transform starts and the top and works down, so "1" is first and "2" is second and last. "2" is where the NameID will pop out of....

Image:ADFS Transformations how does one truncate? - also known as Regular Expressions are evil

Rule 1 - Extract SAMAccountName

c:[Type == "", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("temp:samaccountname"), query = ";sAMAccountName;{0}", param = c.Value);

In the above I essentially do an AD query and store the SAMAccount name in temp:samaccountname to I can get it in rule 2.

Rule 2 - Truncate to <= 8

c:[Type == "temp:samaccountname"]

=> issue(Type = "",
Value = RegexReplace(c.Value, "^([a-zA-Z]{8})+.+", "$1"));

Rule 2 is interesting. I take the previously stored temp:samaccountname and pass it through the ADFS transform regex engine. I'm presuming your SAMAccount name is only letters here [a-zA-Z] so adjust accordingly. The regex (I hate regex) actually matches the first group (in regex that's everything between the parenthesis in the query so [a-zA-Z]{8}). So in the
jhowstoday example it matches the jhowstod. It then takes that group 1 value, jhowstod. and replaces the entire  original text, the $1 in that command. Finally the returned regex is assigned as a NameID and passed out as there are no more rules.

It's easier to visualize using an online regex editor. I use Here is the breakdown:

Image:ADFS Transformations how does one truncate? - also known as Regular Expressions are evil

It looks pretty simple, but trust me, it was far from. Hopefully this will someday help someone.
Darren Duke   |   September 25 2020 04:29:53 PM   |    securitty  adfs  saml    |   Comments [0]

As most will have hopefully read by now the ZEROLOGON vulnerability in Windows (CVE-2020-1472) is pretty wild. Basically by passing Windows netlogon process bypassing a series of zeros to it. Fun times!

Microsoft did issue a patch in their August 2020 updates here, however I'm skeptical that people actually read the FAQ at the bottom of the article:

Image:ZEROLOGON and why you may not actually be protected

Notice that link in the highlighted section? Here it is

Which leads us to this nugget:

Image:ZEROLOGON and why you may not actually be protected

So your Domain Controllers are not fully protected? Admittedly this is a pretty confusing list of bullet points but it does seem to suggest the patch reports as opposed to enforces non-Windows machines. My assumption seems to be backed up by this paragraph below that mentions enforcement will being with the February 2021 patch Tuesday:

Image:ZEROLOGON and why you may not actually be protected
OK, so you installed the patch and your secure right? From Windows devices? Looks like. From non-Windows? I don't believe so unless you add this registry entry otherwise you are flying pants down until February when Microsoft will do it for you:

Image:ZEROLOGON and why you may not actually be protected
Darren Duke   |   September 25 2020 12:08:39 PM   |    security    |   Comments [0]

UPDATE 07/24/2020 - if you are still having issues after these fixes, head over to Tom Hillebrand's blog

I'll admit it. I wasn't exactly sure where the migration to HCL was going to end up. From a features perspective and moving the stagnant products forward it have been nothing short of astonishing. From a documentation and sales viewpoint it has been anything but. Point in case Sametime v11.

Sametime 11 was the promised land. Sametime without the need for DB2 and WAS. Sametime installable on a single server again. Sametime with persistent chat and multi device support. Enough to make even the customers still on 8.0.2 (the last non-WAS version) to stand up like a meerkat and take notice. So here's my tome.....

As a general rule when I have server hanging off the full internet I put it in a DMZ. Additionally whenever possible when I put a server in the DMZ it's going to be Linux. So Domino and Sametime on Linux it is. CentOS 8 to be exact.  It is here the Homer-esque story begins....

I'll start off with this statement. IBM documentation was always woeful. IBM was a veritable Mark Twain when compared to HCL. Good Lord. It is nothing short of atrocious. Especially for Sametime. What we have here is a failure to communicate.

First the good news, I have just gotten it working after several different attempts and more than 8 hours of trying, Almost a WAS like effort. Now, I'm no Linux Deus, but I can get by well enough and boy did I struggle. All because HCL hasn't provided even the bare minimum of documentation for the install process and even more important, the OS pre-requisites need to make the product work.

You get this:

Image:Sametime v11 on CentOS 8....head meet desk

A PDF that is somewhat helpful if you don't know MongoDB (I don't) but from an installation and use knowledge dump it is useless.

So here's how I eventually got the promised land of Sametime v11 to work on CentOS 8. I already had Domino working and installed Sametime and Mongo per the guide. But nada. Nothing. Sametime seemed to start and I was able to log in and while chats can be sent the are blank at the both the recipient and senders clients. Great. In the forum there is mention that this field (not at all mentioned in either in the documentation or added by the installer) in the stconfig database:

Image:Sametime v11 on CentOS 8....head meet desk

Upon install the Chat Log Flag below is not set to "relax" which is (apparently) required to make it work, but set to "off" (why HCL?). I changed it per the forum post but no change in my tragic outcome of blank messages:

Image:Sametime v11 on CentOS 8....head meet desk

So if it's not a Sametime issue I figured it must be Mongo, as all the chats are stored there to allow for the new persistent chat. Hum. I don't know Mongo and Sametime has radically changed since I used to do it regularly (I stopped at WAS like most customers did). Another forum post that pointed me to a "trace" folder under the DomData. Off I go and find this file:

Image:Sametime v11 on CentOS 8....head meet desk

Upon opening it and looking around I find this nugget when ever I restart Sametime:

Image:Sametime v11 on CentOS 8....head meet desk

Hum, libstchatloggingmongodb won't start? Sametime uses Mongo for persistent chat, so...... OK, so where is it and what is it? The Linux locate (part of mlocate) and ldd (part of the core OS) are your friends. Be sure to run updatedb often for locate to be useful.

First, does libstchatloggingmongodb file exist?

locate libstchatloggingmongodb


Image:Sametime v11 on CentOS 8....head meet desk

So the file does exist. Let's find out what the file needs:

ldd /usr/lib64/

Image:Sametime v11 on CentOS 8....head meet desk

Well, there's a clue "not found" eh?. A fair number of the libraries that needs are either not installed or not linked to the correct path (in my case both, although mostly the latter).

I then go down each missing file and find out if it's installed (if not figure out which packages need and them installed). Here's an example of the file that was installed but not linked by the Sametime installer (why not HCL?). Note, I changed the Sametime related paths from 11000000 to latest in the hope that a future Domino upgrade won't break all the symlinks again:

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

Image:Sametime v11 on CentOS 8....head meet desk

Rinse and repeat until you have all the missing ones linked or installed. However for the life of me I could not get and fixed until I figured out I needed compat-openssl110

yum install compat-openssl110

Image:Sametime v11 on CentOS 8....head meet desk

Once that was installed and all the links established the new ldd command looks like this:

Image:Sametime v11 on CentOS 8....head meet desk

With these in place. Sametime v11 on CentOS is finally working. Now to figure out why the embedded client shows me as "away" while I'm actually typing and why you have to kill an entire chat to get it to populate the "chats" view in Notes.. Fun times!

Image:Sametime v11 on CentOS 8....head meet desk

Oh, and to get file transfer to work was another Herculean effort of editing XML files (the trick is which one and what attribute). But still, Sametime without WAS and DB2 is glorious, It just took a long time to get to that point. Thanks HCL for the software and seemingly giving a crap. Now can we have stellar (or maybe just useful) documentation so everyone can install and use the excellent strides you have made?

I'm sure there is a better way,but the above actually worked for me. so while not exhaustive, here's most of the link commands I used for Sametime v11 FP1 on CentOS 8 after Domino, Sametime and Mongo were installed (and remember to change "off to "relax" in the stconfig):

yum install compat-openssl10

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/sticc/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/ /usr/lib64/

ln -s /opt/hcl/domino/notes/latest/linux/STOpenSSL/ /usr/lib64/
Darren Duke   |   May 29 2020 08:57:55 AM   |    sametime    |   Comments [0]

No meaningful blog posts in ages, then 257 in the space of 3 days. Yeah, COVID quarantine is a killer.

Anyway, apparently ID Vaults stop working after 10 years. Not the best decision ever made but the head shed at IBM when 8.5 shipped. I only discovered this when trying to reset a vaulted password. What's even worse is the error of this type of failure. It's not something useful like:

Your ID Vault Trust Certificate is expired as it lasts for 10 years, see technote xxxxxx

(admittedly Domino related IBM-hosted technotes are about as much use as an orange colored President, but meaningful error messages are)

But no. Not useful. All there was this verbal splat of English:

Server Error: The address book does not contain a cross certificate capable of validating the public key.

Image:ID Vault Trust Certificates expire after 10 years. AKA that was a stupid decision and breaks ID Vault

OK. After a few hours of repeatedly hitting my head against a wall checking every certificate under the sun and some Googling that made me start to doubt my ability in seach-fu I hit pay dirt.
This article from Fabio Di Paola was the solution. Essentially this, Vault Trust Certificates expire after 10 years. Genius decision by the ID Vault creators. Not. Many 8.5 installs are coming up to, or have passed their 10 year anniversary when initial ID Vaults would have been installed, so this may help some folks.

Fabio also has the steps to fix it, but it's basically this:

First check if your Vault certificate is expired if so manually delete your old Vault Trust Certificates from the NAB (say what now Darren????!!!!) then re-add the Organization back to the vault via the Manage Vault action. Viola, error banished, passwords are resettable. Bird sing, sky blue.

See Fabio's article for more information if you need it.
Darren Duke   |   April 15 2020 03:08:12 PM   |    domino security    |   Comments [0]

In yesterday's post about AES NSF local encryption, I quipped that you should be able to locally encrypt a replica with AES 128, but that you'd have to do it manually.  Well, you can't. I probably should have tested this theory like HCL should have tested this feature.

Here's what happens:

Go to an existing database on a server and enable AES 128 encryption (yes, the option is there):

Image:Changing NSF encryption on a server to AES? No, you’re not.

Compact said database:

Image:Changing NSF encryption on a server to AES? No, you’re not.

Take another peak at the encryption settings:

Image:Changing NSF encryption on a server to AES? No, you’re not.

"Strong"? WTF? No matter what I do I can't get an existing on server database to encrypt with the new AES setting.

At first I thought this was a Domino version issue. Nope. Servers are 11.0.1. Then I thought maybe an OS difference, after all one of my main servers is Windows, the other CentOS. Nope. Same behavior on both.

Hum. Next up some notes.ini settings can change these settings (see
Ben's post here), but none of those are present on the server.

Lastly was an idea that maybe a local desktop policy was interfering but I could find no evidence of that after several tries (and as mentioned yesterday, the desktop policy settings document is not showing AES as an option and this should only be for local anyway, not server).

So my conclusion for now is that you can only encrypt NEW DATABASES with AES 128 on a Domino server
(or it could be AES and reporting wrong, but new NSFs that are encrypted don't exhibit that behavior, so I very much doubt it is that).
Darren Duke   |   April 14 2020 07:28:32 AM   |    domino  security    |   Comments [0]

One of the new features added with 11.0.1 is 128 bit AES local encryption. Kudos for HCL doing stuff IBM could of and should of done a decade ago. But there are a few things missing.

If you encrypt a NSF with AES encryption like so (this is on a Domino server to get "at-rest" encryption):

Image:Creating a replica of an AES encrypted NSF - some issues

If you then create another replica of the NSF, AES is not an option (only strong):

Image:Creating a replica of an AES encrypted NSF - some issues

I tested against two 11.0.1 servers and a 11.0.1 server and 11.0.1 client (everything was 11.0.1 didn't change the options).

So what can you do if you require AES encryption on all replicas? I guess you can replicate without encryption and then encrypt once it's at the new location (update 04/14/2020, no, you're not). Unfortunately it's also not a setting in a policy yet either so if you were hoping to use this with a Notes client prepare to be disappointed for a while:

Image:Creating a replica of an AES encrypted NSF - some issues

PubNames template is 11.0.1 as well.

One step forward and half a step back is still a big improvement over IBM's approach of no steps forward at all.
Darren Duke   |   April 13 2020 12:04:26 PM   |    domino    |   Comments [0]

Updated 3/31/2020 for 11.0.1

A few weeks ago it dawned on me that there doesn't seem to be a useful (at least that I know of) list of the features added to Domino over the last few releases. Then Lisa asked me for this list for a STS customer. While this is not definitive, it is a least a starting point to see what new features were added when, and maybe more importantly, what was added. This is a tad difficult to collate due to IBM's seriously disastrous decision to go the "feature pack" way for a while.

It should also be noted that as of 10 and higher IBM/HCL have reverted back to fix packs being fix packs. So no new features should be getting added outside of a release revision (for example no new features in 10.0 FP1, but there are new features in 10.0.1).

So here goes:

9.0.1 (IBM)

  2. Java 8 on server
  3. Summary 16MB
  4. SAML ADFS 3.0

  1. New mail, contacts and pubnames templates (Some features below require these new templates)
  2. View open speed increase on TX logged NSFs
  3. Mail forwarding restrictions
  4. Inline view indexing
  5. Run mail rules on existing messges
  6. REST API improvements

  1. Java 8 in client and DDE
  2. Eclipse update 4.6.2 (from 3.4.2)

10.0 (IBM)
  1. Touch screen supoort
  2. Custom colors
  3. New mail template
  4. Dynamic indexing for highly changing views
  5. Symmetrical clusters
  6. Document deletion logging
  7. Dead mail automatic processing
  8. New ODS 53, 256GB NSF size support
  9. Node.js support
  10. DQL (Domino Query Language)

10.0.1 (IBM)
  1. AUT - automatic client update tool
  2. Marvel Client Essentials included
  3. SSL cipher improvements
  4. One time mail signatures

11.0 (HCL)
  1. New licensing model
  2. New mail template
  3. OpenSSL Use
  4. InstallAnywehre use
  5. DirectorySync
  6. Use ID Vault password as HTTP password
  7. AdoptOpenJDK 8 with OpenJ9
  8. DAOS 2-tier storage
  9. Nomad for iPad released

11.0.1 (HCL)
  1. Swiftfile integration is standard. Can be disabled
  2. New Directory Sync feature allow multiple AD users to be registered at once
  3. Subject Alternate Name support in TLS certs.
  4. SNI Domino HTTP support. Server Name Indication (disabled by default)
  5. DAOS tier 2 storage
  6. Docker image in UBI format
  7. Java
  8. Save (well export) document to PDF
  9. 128 bit AES local encryption
  10. Updated templates (including mail and pubnames)
  11. Cross Domain support for Traveler to get ID's from ID Vault
Darren Duke   |   February 29 2020 04:46:06 AM   |    domino    |   Comments [2]

Microsoft always seemed to detest that organization and users kept Windows XP and then Windows 7 for a decade or more. Well they've fixed that in Windows 10.

Windows 10 eh? Pretty much everyone hates it. The Windows updates are massive and feature updates can take an eternity to install on even the fastest of fast computers. Those feature updates, officially called  "Semi-Annual Channel" (SAC) and are released in March and September of each year. You know the ones I mean,
they can break a ton of stuff. Now what if I tell you that Microsoft only support a given feature version (like 1703, the March 2017 version) for 18 months. Then your OS goes end of life. And you have to install a feature pack that is more recent to keep getting security upgrades. The exact same feature updates that can break a ton of stuff. How would you like that?

Basically your Windows 10 Pro install has a 18 month planned obsolesce. On hardware that could last 4-5 years. Fantastic idea Microsoft.

Now I know all of this as we sell this stuff. And I honestly thought all the PC's at STS were in Windows 10 Enterprise (more on that later), but a vulnerability scan (the fantastic
OpenVAS Community Edition is what I use) proved it otherwise:

Image:Your Windows 10 Pro installation could be end of life

Sure enough, I go to the reporting PC run
winver and Windows 10 Pro 1703....gah:

Image:Your Windows 10 Pro installation could be end of life

OK, so upgrade it to Windows 10 Pro 1809 and waste two to three hours of my life (this example PC is an i5-7500T with an NVMe and it;'s been going for a hour already). But if I'm an organization with more than a handful of computers or maybe my software is custom or I have Panasonic tough books that require 1607 (yes I know, not xx03 or xx09.....)  or I want to avoid the whole feature-update-breaks-things what can I do?

You need to buy Windows 10 Enterprise. This has few advantages:
  1. These get 30 months of updates if you go with the September (xx09) version of Enterprise. March editions only get 18 months. WTF MS?
  2. There is a special version of Windows 10 Enterprise called "Long Term Support Branch" (LTSB also used to be LTSC for "channel"). This puppy gets you 10 years, YES 10 YEARS of updates. You have to have a volume account to get it though. And because your PC life cycle is somewhat less than 10 years (it is right? Because if not we need long hard chat) you never have to worry about an OS install or feature pack install as long as the PC in use.

LTSC also has some more advantages like no Windows Store and all the crap-ware and no Edge browser. Other things to.

So if you have Enterprise why would anyone ever not go to LTSC? Good question. You cannot do an in-place upgrade from any version of Windows 10, yes, even non-LTSC Enterprise, to LTSC. It has to be a clean install (although you can keep data and files). That's why you may not want to do it. The PC that's upgrading to 1809 now has a fair amount of of software that I don't really want to have to re-install from scratch, so I'm not doing LTSC on that until the OS takes a crap or the SSD dies. What I can though is to update to Windows 10 Pro 1809, then do an in-place upgrade to (non LTSC) Windows 10 Enterprise by changing the activation key. This gets me a whole extra year of being able to ignore the issue again as you can see from the non-LTSC life cycle table:

Image:Your Windows 10 Pro installation could be end of life

For reference here is the LTSC life cycle table:

Image:Your Windows 10 Pro installation could be end of life

The above tables  (and server and 8.1 and other stuff) are available at

As always, if this has piqued your interest in Windows 10 Enterprise
drop Lisa a line.

This is also a good example of why just vulnerability scanning your network and allowing your desktop firewalls to block the scans is a bad idea. If I had done it that way (and not OpenVAS into the OS) I may not have realized that I had a potential highly vulnerable system just hanging about on my network.

Oh, and after 90 minutes of upgrading to 1809, this happens. And Microsoft wonder why pretty much everyone hates Windows 10. Maybe this PC will get LTSC after all.....

Image:Your Windows 10 Pro installation could be end of life
Darren Duke   |   May 11 2019 08:27:42 AM   |    windows    |   Comments [0]