Lotus Nut

A little known ECL setting for Domino is "<ECLOwner>". Adding this in as an entry to the ECL will allow you to control exactly what the workstation user can do with code signed as himself and running on the workstation. More information can be found here. Recently I have seen where -Default- has allowed all of the methods (please, do NOT have your ECL configured this way!!!) and when it was previously removed in testing the users were prompted to add ECL entries for themselves when opening folders (or doing other such things). The solution is to grant <ECLOwner> the proper rights first and then to begin the process of revoking rights for -Default- and "No Signature".

And if you haven't looked in a while, please go review your ECL (carefully, don't just go revoking people and make sure the account you use has access to modify the ECL within the ECL so that you don't have users receiving those prompts!)

After seeing the security problems with Sametime Connect Client API that Carl Tyler blogged about over the weekend, Lotus 911 has decided to disable plug-in installation for the im.bleedyellow.com Sametime Community. Hopefully, this will be a temporary change until IBM releases a fix for this.

If you experience any issues with this, please post a comment here or use the "Contact" link at the top of the page.

One of the Domino Server security settings that I rarely see implemented is the option to "Enforce Server Access Settings". In the link, you can see that Ted describes the feature nicely.

With Quickr, you have the ability to grant access to places for people not listed in your directory. However, I have found that there is a "gotcha" when using this Domino security option if you also have the setting to only allow "Users listed in all trusted directories" checked in the Security tab of the Server document. Since the internal "place users" are not in your Domino Directory, they will not be able to log in.

But there is a way around this. With specific place users, they are created in the ACL as me@domain.com/placename/QP/DominoDomain. So this means that along with the "Users listed in all trusted directories" that you should be able to add */QP/DominoDomain to also be allowed to access the server.

Oh, and you'll also have to make sure that LocalDomainServers (or some other server group) has access to the server as well. :)

Continuing my series on Domino 8 Administration features, new with Domino 8.0.1 is the option to mandate the encryption standard for ID files. Full details can be found at the infocenter. With Notes 8.0 and Domino 8.0.1, there is an option to use AES for ID file encryption. Here's how strong AES is:

"The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use."

Implementation of AES requires a Domino 8.0.1 server. A Security Settings document is used to configure how the ID file's encryption will be enforced on your server. In a new or existing Security Settings document, you will need to go to the Password Management tab and then scroll to the bottom to the ID File Encryption Settings section:


For both the Mandated and Allowed encryption standards fields, you have the following choices (the same choices as when you change your password in Notes 8.0):

• Compatible with all releases (64 bit RC2)
• Compatible with release 6 and later (128 bit RC2)
• Compatible with release 8 and later (128 bit AES)
• Compatible with release 8 and later (256 bit AES)

First of all, this is great that companies can now mandate this. But the super swank option is the "Key derivation strength (iterations)" field. In layman's terms, the higher you set this value (the default is 5000), the longer a dictionary attack will take against the ID file. It won't be impervious to an attack, but you shouldn't be using passwords that are in dictionaries... From the infocenter:

Key derivation strengthening is a technique used to make it more costly for malicious attackers to guess likely passwords through a brute force dictionary attack. They work by increasing the time it takes to generate a key from a password. The value for this field is the number of times an HMAC algorithm is applied as part of the operation that generates a key from the password. Specifying a larger number for this value increases the duration of each attempt during a dictionary attack. The default setting for this field is 5000, which is acceptable in most environments. Organizations with higher security requirements may wish to specify a higher value.

So, once you have your servers at 8.0.1 and then have clients at 8.0 or higher, you can begin enforcing this. However, you may also phase this in with a tiered approach. For instance, if you have admins and/or developers that may have access to sensitive data, you may wish to get them on the Notes 8.0 + client and apply a special security settings document to their policy.