ECL - The Complete Guide

What is the Execution Control List?? What is "Trust signer,"– and why do you always just press that button, "Trust signer"? Why do you get this message again and again? Do you care about your security? - Read this article, to understand the Execution Control List (usually referred to as ECL), and how to set up, maintain and deploy your ECLs to your environment and users.

The basics about ECL, - Execution Control List
Don't confuse the ECL with the ACL, though they look similar. Both have something to do with security, but in very different ways. The ECL is used to set up workstation data security and it protects user workstations against active content from unknown or suspect sources. This ECL can be configured to limit the action of any active content that runs on workstations, in other words, stopping actions that are not trusted by the workstation itself. "Active content" includes anything that can be run on a user workstation, including formulas, scripts, agents, design elements in databases and templates, documents with stored forms, actions, buttons, hot spots as well as malicious code, such as viruses and so-called "Trojan horses." The ECL determines whether the signer of the code is allowed to run on a given workstation, and it also defines the access that the code has to various workstation functions. For example, an ECL can prevent another person's code from running on a computer and damaging or erasing data. So, basically, as we will see later in this article, by clicking the "Trust signer" button, you are allowing "active content" of a given type to run on your computer, and also accepting that kind of action or "active content" to be run later on the same machine, if the signer of the "action" is the same.

Where's my ECL?
As mentioned earlier, ECL is part of a client's security settings, and is found as part of the client preferences, and is stored in the Personal Address Book. You can't really browse your Personal Address Book and read your ECL settings, but it can be viewed using menu elements in your Notes client. The location of your ECL settings is dependent on your client version. As of Notes 6, these settings have been moved to a special "security area" called "User Security" which can be found by selecting File - Security - User Security, and then selecting “What Others Do.” On an R5 client, you find your ECL by selecting File - Preferences - User Preferences, and then clicking the button labelled “Security.” Independent of your client, your ECL looks more or less like this:



On the left, you'll find the signatures, for which you allow different levels of access, through the checkboxes on the right. Depending on your client version again, you'll also have the above settings for workstation formulas and scripts, as well as java applets and JavaScript. The list of persons does not need to contain exact names (they way they appear in my list), you can also use asterisk, like "*/myOU/Dominozone".

One thing to be very aware of is that if you upgrade from a R5.03 client, "-Default-" and "-No Signature-" has full access to everything. This is a bug of the R5.03 release, so be aware if you upgrade from this point release, it will stay like that. If you install a fully new version though, it will be fixed.

Administraion ECL

When you set up a Notes client, each client will have a default ECL. You might think that this ECL is an empty ECL, but it is not. The default ECL for each client will reflect what we call the Administration ECL. If no Administration ECL is set, the ECL will default to a standard Lotus/IBM set-up. If you have set an Administration ECL, all your new clients will inherit this ECL automatically. However, if you set an Administration ECL later, your previous clients will not get this ECL automatically reflected on their client. How to solve this will be discussed later in this article.

To set up an Administration ECL that should be the default and "trusted" ECL for all your clients, you will need to use your Administration Client, or open your Domino Directory in a Notes client. In this article, I will be using an Administration Client.

Select the tab for Configuration, expand Server and then select Current Server Document. Now, you will have a menu available; Actions - Edit Administration ECL. This will give you a window showing the current "Administrative ECL" which will be reflected on all new client set-ups (see picture on the left). You might find this menu without selecting a "current server document", but in earlier releases this was the best way to make the menu appear.

As in this example, no extra signatures are added - and users in this company will most likely get a lot of "Trust Signer" messages/warnings, although this depends on how applications are deployed in the company. A best practice for ECL is to configure an Administrative ECL that includes a main signer ID signature, like "Signer/Company". This ID should always sign databases that are deployed in the environment, so that users that click on a button in a database (that runs a script) will not be given the annoying "Trust Signer" window. Given, of course that their client has this Administrative ECL installed.

But, as I said, clients will not have this Administrative ECL if they have been set up prior to configuring this Administrative ECL. To solve this, we have several choices. One is to upgrade to Domino 6, which can, using policy documents, set up centralized ECLs, and deploy these automatically. This is part of the regular policy and settings documents (security) of Notes/Domino 6. Another solution would be to refresh the local workstation ECL against the Administrative ECL, using some minor programming.

Updating local workstation ECLs using programming
As mentioned earlier, updating local workstation ECLs must, in a pre-Domino 6 environment, be done using some minor programming. Based on experience, I usually sketch 2 choices to accomplish this:
1. Button in e-mail
2. Hidden background agent

Button in e-mail
I always say that, your are not a fully-fledged administrator until you know quite some programming as well, and that goes the other way around as well. This is one example that should verify this. You could send an e-mail to all your employees/users, with a button that refreshes the local workstation ECL with the configured Administrative ECL. The code is very easy and can be expanded for more functionality:

@RefreshECL("Servername":"names.nsf"; "");
@Prompt([OK] ; "Success" ; "Thank you - you can now go back to work");



Already now, you should stop me. Wouldn't this also generate a "Trust signer" window for the client? Let's get back to basic, - what am I doing here? I, as an administrator, create an email, with a button, which again runs a code. This email is sent to all my users. The user clicks the button.... But, who signed this button? Of course, I did, or, the administrator. So, if the user does not have, let's say "Rune Carlsen/Dominozone" within his or hers local workstation ECL, he will in fact be prompted with a "Trust Signer" window. If you can live with this, emailing a refresh-button like this one is a good solution. This solution is also good if you know your users have a certain ID trusted in their ECL, and you just want to update/refresh it again. Then users won't be prompted. Another drawback of using this method is that you don't have control of what your users do. Will they click this button? - Or even more important, will they click it while they are connected to your LAN, and not while they are mobile? If these are problems you need to avoid, use the "hidden background agent" method instead.

Hidden background agent
Using this method, we really do the same thing, but we just hide it and "force" the user to run it. We will not get the problem with “Trust Signer,” neither will we get the problem with users not doing what we ask them to do. This is yet another example of the power you have with knowledge of both system administration and application development. What we do is to utilize a task on the Domino server, called DESIGNER. When a master template design changes, the Designer task updates all databases that inherit their designs from the master template. The Designer task runs daily by default at 1 AM. The Updall task, which runs by default at 2 AM, updates the view indexes of databases changed by Designer. So, what does this mean? Well, what we can do is to change an event in every mailfile on the server. Each mailfile has an event called "PostOpen". This event will run when the database is opened by the client. Meaning, we can tell the client to run some script when the client open his or her mailfile, in the background, without the user noticing what's going on. Instead of changing every mailfile and adding this script in the design of the mailfile, we do this in the template. During the night, every mailfile will have this script, because it is inherited from the mail template by the designer task. And the next time the user opens his or her mailfile, the script runs in the background. We can of course use any database, not only the mailfile, but it's a common way of doing it since every user opens his or her mailfile during the day. That way we ensure that the script will run. To avoid that your users get the "trust signer" window when opening their mailfile, ensure that you sign this script with an ID that is trusted in their ECL, or by creating a dummy ID file, reflecting the one that Lotus/IBM uses, which always is part of their local workstation ECL. All you need in your code is part of the previous code. We omit the prompt, to avoid user interaction.

@RefreshECL("Servername":"names.nsf"; "");

This code should be put into a separate sub-function and called from the "Initialize" event.

Best practices for deploying applications

If you have taken ECL into consideration, have set up an Administrative ECL and published or deployed it, someway or another, it's important that you don't forget about it in the future. As an administrator, you are the one responsible for adding and deploying new applications/databases on your servers. Don't forget that these databases before they are deployed should be signed with your "signer ID", the ID file that is part of the Administrative ECL, which again is part of every client’s workstation ECL. There are several ways of signing databases, both documented and undocumented. The out-of-the-box solution, is to use your administration client, and select your files tab, right-click the file/application/database you want to deploy and then select “Sign....” This should give you a window like the one shown to the left. You are prompted to choose which ID you want to sign the application(s) with, and what you would like to sign. As you see, the choice for selecting the signer ID, is "Active User's ID" or "Active Server's ID". Because of this, I would recommend you to switch to the signer ID of your choice, before doing the signing. Then, select "Active User's ID" as the ID you want to use for the signing. About the "What to sign" choices, my experience says that "All design documents" signs the database in the best way for deploying new applications to your environment. Also, I don't usually recommend to check the "Update existing signatures only (faster)" checkbox.

In order for all the functionality (such as Agents) in a signed application to work properly the Signer ID must have sufficient access to the server(s) and in each database ACL. The best way to set this up is to let the Signer ID have an proper password set and incorporate the Signer ID in an Administration group that is incorporated in the "Who can run Agents" etc sections in the server document and also have Manager access on all databases.

When you have signed your application(s), they are now ready for use, and users should not experience "Trust signer" warnings (if your ECL is deployed correctly).



Take ECL seriously
ECL is not a feature that was designed for fun, to annoy users with a "Trust Signer" window from time to time. When you set up the first server in a domain, Domino creates a default Administration ECL, which you can then customize. The Administration ECL is the template for all workstation ECLs. Whenever a new Notes client is installed, the set-up program copies the Administration ECL from the Domino Directory to the Personal Address Book on the Notes client workstation. The user's Notes ID is added to the workstation ECL, with all access allowed. For example, when Rune Carlsen's Notes client is being set up, Rune Carlsen is automatically added to the client ECL signer list.

Your goal as an administrator is to limit the number of trusted signers for active content, and the access that active content has to user workstations. To accomplish this goal, limit the number of trustworthy signers in your organization and ensure that workstation ECLs trust only those signers. By telling your users or giving them signals that pushing the "Trust Signer" button is the best thing to do, and that this will solve their problem, you are really just undermining your own environment security. The ECL is an integral part of the security settings for your clients, don't forget that.

Do not grant access to unsigned content. This creates a security hole that allows potentially harmful code, malicious or otherwise, to access user workstations. Keep the default access options for unsigned content. Know your signers. Trusting signed active content, especially from other organizations, is risky. Before adding an active content author to an ECL, decide if you trust that the author has created safe code. Create a separate certifier for an organizational unit to issue IDs specifically for users who must sign templates and applications -- for example, Enterprise ECLApp Signer/West/Acme. Then users who create templates and applications use those IDs to sign templates and applications. You can then set up the administration ECL to trust any user in that special organizational unit, or fine-tune it on a per-user basis.

Personally, I would say that the best configured and running environment, based on ECL, would be if no users are prompted with "Trust Signer" windows ever, and if they do, the first thing they do, would be to contact their administrator. They should be informed that "Trust Signer" should not happen in their environment, and should be considered and dealt with as potential virus attacks. Of course, that's just my personal imaginary world of a perfectly configured and deployed ECL, but if you take security seriously, this should be your ECL policy as well.

It is just a matter of time before some "clever" hackers makes an virus that attacks your Notes/Domino enviroment. If (when) that happens in your infrastucture and you have not implemeted ECL in a proper way -- you as an Administrator will have quite some problems to deal with. You can not blame it on a security hole etc. in Notes/Domino.... It is only you as the Administrator that must take the heat for not having followed best practices and implemented the ECL in your domain. So do not hasitate anymore, just do IT -- before it si too late.