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 setup 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 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 the administration ECL.
Note Technically, when a server is initially installed, there is no 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 ECL that is copied to user workstations.
You use the administration ECL to define and deploy customized ECLs for your users. 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. For example, you can create one ECL exclusively for contract employees and another ECL for full-time employees.
For more information on using policies for security, see the topic Creating a Security policy settings document.
Guidelines for creating an effective administration ECL
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/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.
