Administration ECLs

When you set up the first server in a domain, HCL Domino® creates a default administration ECL, which you can then customize to create other named administration ECLs.

An administration ECL functions as a template for workstation ECLs. Whenever a new HCL Notes® client is installed, the setup program copies either the default administration ECL or, if the administrator has created other admin ECLs, a named administration ECL, from the Domino® Directory to Contacts on the Notes® client workstation. The user's Notes® ID is added to the workstation ECL, with all access allowed. For example, when John Doe's Notes® client is being set up, John Doe is automatically added to the client ECL signer list.

If the home server is unavailable when a Notes® client is installed -- for example, when a user is disconnected -- the workstation ECL is created with default settings, rather than being created from an administration ECL.

Note: Technically, when a server is initially installed, there is no default Admin ECL. When a client attempts to edit the workstation ECL, or refresh it from an admin ECL that does not exist, the client creates an ECL with default settings that are coded into the client. The Admin ECL exists on disk, once an administrator modifies and saves it. Once the modified administration ECL is saved to disk, then that is the default ECL that is copied to user workstations.

You use administration ECLs to define and deploy customized ECLs for your users. For example, you may create one administration ECL to define workstation ECL settings for contractors in your organization, and a different administration ECL to define workstation ECL settings for full-time workers. You can control ECL changes or allow users to modify their own ECLs. Furthermore, you can update your users' workstation ECLs as security requirements change -- automatically, through the use of a security settings document deployed through a policy, or manually, by asking users to refresh their workstation ECLs.

To create customized ECLs that can be deployed for specific groups of users, you must use a security settings document that is deployed through a server policy.

Guidelines for creating effective administration ECLs

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.

Use these guidelines to create secure ECLs:

  • 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.
  • Do not let your users trust unsigned content. To prevent users from changing their ECLs -- for example, by giving access to unsigned content, or to content signed by signers who are not listed in the ECL, deselect Allow user to modify in the Administration ECL.
  • 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/Renovations. 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.