The everyday work involved in administering Notes security, such as managing access control lists, issuing IDs, and monitoring database accesses, are a considerable part of an administrator's job. Chapter 5, "Building a Deployment Plan," shows
you how to plan your Notes network to minimize the overhead caused by the security system. You also should review Chapter 3, "Understanding Security," and Chapter 4, "Advanced Security Issues," before reading this chapter. This chapter
details the tasks involved in administering Notes security. Specifically, this chapter discusses
This chapter doesn't discuss in detail the concepts of access control, authentication, and encryption. These topics are covered in Chapter 4, "Advanced Security Issues." This chapter provides the information you need to actually carry out your
day-to-day tasks.
Each type of administrator (server administrator, database administrator, certifier) has a role to play in Notes security:
In small organizations, many of these roles are played by a single person. You should realize that giving a single person this much power is a clear security risk. Large organizations split these roles among several people. The recommended way of
splitting these roles is to give certifiers no other responsibilities or access. For example, a person with access to your company's certificates shouldn't be either a server administrator or a database administrator. On the other hand, combining the role
of server administrator and database administrator is okay.
Access control lists grant specific privileges to users and control which data replicates between servers. Access control lists are everywhere within Notes. Individual documents, databases, and servers can have their own ACLs. Each Notes database and
server has an ACL. If you have 100 databases spread out over 5 servers, your administrators have at least 105 ACLs to manage. In large organizations, several thousand databases are not uncommon.
Managing access control lists efficiently should be a primary goal when designing your Notes network and applications. This section details each of the tasks that you need to accomplish when managing ACLs and shows you how to minimize the amount of
effort needed to manage large numbers of ACLs.
All database-level ACL options are accessed by using the Access Control List dialog box. You administer ACLs in two ways. You can manually change an ACL for a single database by using the Access Control List dialog box, or you can manage the ACLs for
all databases by taking advantage of the administration server. The Access Control List dialog box enables you to view and change names and roles, monitor changes to the ACL, and cause all database replicas to use the same access control list. Figure 18.1
shows a typical access control list.
Figure 18.1.
A typical access control list.
Figure 18.1 shows that Andrew Dahl has manager access and the ability to delete documents. Each name listed in an access control list has an associated type access level and some specific abilities, and may be assigned one or more roles.
Each name in the access control list must be the name of a user, server, group, or the replica ID of a database. In addition, you can use the reserved word Anonymous to specify the access level for the general public. Anonymous differs from
"default" in that noncertified users accessing the Notes system are given the Anonymous access level, while certified users are given the default access level.
Notes assumes, unless told otherwise, that names in access control lists use the same organizational unit certificate as the server that houses the database. For example, if the name David Malone appears in an access control list on the server
Marketing/L3COMM, Notes assumes that the full name for David Malone is David Malone/L3COMM. If the user is certified with a different organizational unit certificate than that of the server that houses the database, you must specify the full name for the
user. Because you can't always know in advance the servers that will house a particular database, you should always specify full names in the access control list.
Although server names can be specified directly in access control lists, you should always use groups to include servers in ACLs. Notes specifies two groups that are meant to control server access to a database. These groups are LocalDomainServers and
OtherDomainServers. You add the name of a server to an access control list to control which information is replicated from this database to a replica on the other server. Listing a server in an ACL doesn't affect which information is replicated from the
other server to the local database. As with user names, you have the option of specifying just the common name for a server, or the full hierarchical name. To ease your overall administrative burden, specifying the full name of a server in access control
lists is better. Using the full name for servers provides tighter security and eliminates possible problems down the road.
Groups are a convenient way of collecting several users or servers, and are are a key element in easing the administrative burden. All groups that you list in an access control list must be present in the Public Name and Address Book.
You should never list specific names in an access control list. All users and servers should be placed in groups, using the public Name and Address Book. Only group names should appear in access control lists. The only exception to this rule is if your
organization uses the Memo to Database Manager feature. The Memo to Database Manager feature is a convenient way for any user to send a memo to the database manager for that particular database. For this feature to work, you must specify the user's name
directly in the access control list, and the user must have manager access.
Chapter 3, "Understanding Security," contains a complete description of the various access levels that you can grant to users and servers. In summary, these levels are
Each of these access levels can be refined for a particular server, user, or group of users. The privileges that can be set on a per-name basis are detailed in Chapter 3, "Understanding Security." In summary, the optional settings are
The following sections detail each of the tasks involved in managing ACLs.
Chapter 3, "Understanding Security," discusses the issue of adding specific names to an access control list. The recommended approach to ACLs is to add only group names to an ACL. The steps for adding a name to an ACL are identical regardless
of whether the name is a user, server, or group. To add a name to an access control list, follow these steps:
If you have trouble making changes to the access control list, check the access level of your current ID. You need manager access to change an ACL.
You may want to delete a name from an access control list for a variety of reasons. You should always remove the name of the designer that created the database when you place a database into production. You should also remove the names of anyone who has
left the company from all access control lists in which that name appeared. The need to remove names of people who have left the company is one of the primary reasons you should avoid listing specific names in an access control list. To delete a name from
an access control list, follow these steps:
If you have trouble making changes to the access control list, check the access level of your current ID. You need manager access to change an ACL.
The primary reason you will need to change names in an access control list is that the user has changed departments and his or her fully qualified name has changed. For example, when Leslie Lesnick moves from Marketing to Consulting, her fully qualified
name could be changed from Leslie Lesnick/Marketing/L3COMM to Leslie Lesnick/Consulting/L3COMM. When a user's name changes, you need to update all ACLs in which the name appears, and recertify the user. You can do this manually, or automatically by using
the Administration Server agent. To manually change a name in a ACL, follow these steps:
If the name appears in a large number of access control lists, it's easier to have an administration agent automatically update all ACLs to reflect the new name in the Name and Address Book. Using the administration server to update ACLs guarantees that
all changes to the Name and Address Book are reflected in the access control lists for all databases in your organization. To have a database ACL updated using an administration agent, you must specify an administration server for the database. The server
that you select must be running the Administration Process. You don't need to specify an administration server for every replica of a database if you have configured your servers to replicate ACL changes. If you haven't set up your servers to replicate ACL
changes by giving servers manager access to all replicas of this database, you need to specify an administration server for each replica of the database. To have your database ACLs automatically updated by an administration agent, follow these steps:
The Administration Process automatically updates all group documents in the Name and Address Book, as well as the ACLs of all databases specifying an administration server, with the new full name for the user. The administrator only needs to change the
person document for the user on the administration server. The Administration Process notices the change and does the rest. For details on the administration server, see Chapter 13, "Administrative Tools."
The user types feature enables an administrator to specify the exact type (user, server, group of users, group of servers, mixed group) for each name in an ACL. This feature, while not a true security feature, helps prevent security mistakes. For
example, by specifying the type Mixed Group for a name, you prevent someone from accessing a database by creating a user ID with the same name as the group listed in the ACL. This feature doesn't prevent someone with the power to create IDs from gaining
access to a databasehe could create an ID that's listed as part of the group, and use that ID to access the database. But it does help prevent you from accidentally giving the wrong access level to a user.
You can assign any of the following types to a name in the access control list.
The default type for all names is unspecified. The administrator or database designer needs to take steps to force a type to be assigned. You can assign a type to each name manually or you can force Notes to look up each name in the Name and Address
Book and automatically specify a type. To manually change a user type, follow these steps:
If you have a large number of databases, or a large number of names in a particular database's ACL, use the Name and Address Book lookup to save time and avoid mistakes. To force Notes to assign types that match the entries in the Name and Address Book,
follow these steps:
Notes looks up the type for each name in the ACL that doesn't have a type. All groups are specified as mixed; if you want to specify a person or server group, you need to manually specify a type for each of those groups.
A user or server may be listed more than one time in an ACL. There are three situations in which this can happen:
There are four acceptable types of entries in a database ACL:
You can place the name of any user in an ACL. If the user is listed in the Name and Address Book on the server on which the database resides, you can use the short name or the full name. If the user isn't listed in the local Name and Address Book, you
must specify the full name for the user. Avoid explicitly listing user names whenever possible. Groups are easier to manage than individual names. You also should use wild cards (for example, *\Marketing\L3Comm) rather than individual names. Wild cards are
useful only when you have a hierarchical naming scheme.
Servers appear in ACLs to control which data replicates to and from the server. LocalDomainServers and OtherDomainServers are two default groups that Notes provides in each access control list. These groups have manager access so that all servers can
replicate changes to an ACL.
Groups can hold multiple users or servers and are useful for specifying access level to a class of users or servers. All groups must be listed in the Public Name and Address Book. Notes needs access to the group document in order to resolve the
individual names within a group. You can specify short names or full names for members of a group. The only exception is when a name appears in a group that is in turn included in another group. In this case, you must specify the full name exactly as it
appears in that person's ID file. Because of this restriction and the fact that you can't tell in advance which groups will be nested inside other groups, you should always use full names when including them in a group.
Applications must often retrieve data from another database. This is done by using the @DbColumn or the @DbLookup functions. The database from which you want to retrieve data must have the current database's replica ID in its ACL. For this technique to
work, the two databases must exist on the same machine, and the database that's retrieving data must have at least reader access to the other database.
Because replica IDs are long sequences of gibberish, avoid typing them into an ACL. Instead, cut-and-paste a replica ID from a database information box to the ACL of the other database. You can determine the replica ID of a database by following this
procedure:
You only need to specify replica IDs when the default access for a database is depositor or no access. If the default access is reader or higher, all entities, including other databases, will be able to query data from the database.
The database manager for a database should keep track of all changes to an ACL. You can perform this task in two ways: regularly check the ACL log, or have changes mailed to you automatically.
To force all ACL changes to be sent to your mailbox, follow these steps:
To disable ACL monitoring for a database, follow these steps:
If you are monitoring a large number of databases and receiving many notifications in your e-mail, consider setting up a mail-in database to receive ACL changes. In addition to setting up a custom mail-in database, you can use the Statistics Reporting
database (described in Chapter 17, "Administering Notes Databases").
Even if you are having all changes to an ACL sent to your e-mail or a central database, you need to check the ACL log regularly to prevent someone from temporarily disabling ACL monitoring, making a change to an ACL, and then re-enabling ACL monitoring.
To view all ACL changes to a database, follow these steps:
Roles are useful for controlling access to specific design elements within a database. You don't use roles to assign specific access levels, such as manager or designer, to names. Instead, you use roles in the read or edit access lists for views and
forms. Chapter 3, "Understanding Security," discusses reasons why you may want to use roles. Strictly speaking, roles aren't necessary. You can accomplish the same goals by using groups in the Name and Address Book. These are the advantages of
using roles:
The author recommends that you use roles sparingly, if at all. Roles aren't useful in protecting the data in a database, only in protecting the views and forms in a database. The only ways to protect data in a database are with access levels and encryption. Because roles aren't useful in protecting data, the administrative overhead involved in maintaining roles usually outweighs any benefit gained from roles.
When creating a role, use a name that reflects the purpose of the role. To create a new role, follow these steps:
No mechanism exists for automatically looking up roles specified in the access lists of the forms and views of a database. Always double-check the spelling of a role when you create a new role.
Notes databases have five roles already specified in the ACL. You may want to eliminate these roles to avoid clutter in the ACL. To remove a role, follow these steps:
Roles are useful only after you have assigned users to a role and used those roles in specific access lists for views and forms. To assign users to roles, follow these steps:
You use the same process to delete users from roles, except that you deselect users in step 4.
No easy mechanism exists for viewing the names assigned to a specific role. Instead, you must review each name in an ACL to determine if it is part of a role. To view the members of a specific role, follow these steps:
Notes provides a default ACL for every database. The default ACL specified by Notes may not be appropriate for your organization. Chapter 5, "Building a Deployment Plan," shows how to develop an ACL that's right for your organization. Most
organizations could benefit by using the following default ACL (covered in detail in Chapter 5):
Using the Terminations group in all ACLs is particularly important. All organizations have people who will leave the organization and should be denied access to Notes resources.
You may think that preventing access to the server is sufficient to protect your data. It is, if you never mess up a server ACL. Use the Terminations group in each ACL anyway, as a backup mechanism.
Problems in your access control lists show up in one of two ways. The database administrator may receive complaints about data not replicating or about documents that are unavailable. In these cases, the most likely problem is that too low an access
level has been given to a user or server. While annoying, this problem often is less severe than giving users or servers too much access.
The primary goal of any security system is to prevent unauthorized access to confidential information. A database manager is unlikely to receive a complaint from a user that too much data is available or that the user has access to confidential data
when he shouldn't have access. Discovering access control problems that allow access to confidential data requires constant monitoring of both the ACL and user accesses to a database. Chapter 17, "Administering Notes Databases," shows you how to
monitor accesses to a database.
Manager access is the default level of access provided to anyone accessing a local database. This case is true even if the user has a lower access level for the copy of the database stored on the server. This issue can lead to confusion among users, who
make changes to their local copies that aren't replicated to the server. To avoid these problems, you can force local copies to restrict users to the rights that they have in the ACL. Follow these steps:
Local security is another feature that looks and smells like a security feature, but is actually used only to build good interfaces. Don't rely on the local security feature to protect data stored on laptops. You must encrypt databases if you want to
protect the data from users who have file-system-level access to a database. See the later section on encryption for details on encrypting databases.
Controlling access to servers is the first line of defense for your Notes network. Server access control is set by using the server document in the Name and Address Book. The server document in the Name and Address Book contains four key access control
lists:
In addition to controlling access by using access control lists, you can force a Notes server to verify public keys or allow anonymous connections (described shortly).
To specify a list of users or servers that can access this server, follow these steps:
The names in the Allow Access list are the only names that will be given access. You can specify a list of users or servers that shouldn't have access by entering their names in the Not Access Server field.
The acceptable entries for a server access list are
Carefully plan your use of server access lists, because performance implications exist. Every server access is checked against the corresponding server access lists. These checks can result in lower performance and capacity. To increase performance for
frequent users of the server, consider creating a group called FrequentUsersOfx (where x is the name of the server). By listing frequent users of this server in a group and placing this group first in the Access Server field, you decrease the
load placed on the server by these users. Notes looks in the first group and finds a matching name, without the need to search through the entire Name and Address Book.
You can restrict the user's ability to create new databases or replicas by entering the names of people in the Create New Databases or Create Replica Databases fields.
You can give the general public access to a Notes server by allowing anonymous connections. When you allow anonymous connections to a server, anyone with a Notes client can access the server. Users are given access to individual databases using the
Anonymous class in database ACLs. Unauthenticated users receive whatever access is assigned to the word Anonymous in an ACL. If you don't specify an access level for Anonymous, anonymous users receive default access. To enable anonymous connections, follow
these steps:
You can prevent people from even knowing of the existence of a database, by placing that database in a secure directory. You can create a secure directory by following these steps:
Listing 18.1 shows an example of a directory link.
c:\notes\securedb\ Andrew Dahl\Consulting\L3Comm *\Acme
WARNING: Minimize your use of directory link files; you must maintain the access control lists in these files by hand. The Administration Process doesn't update these files when users are deleted or have name changes.
You can't maintain a highly secure Notes network in the absence of physical security for servers. All servers must be physically secure to guarantee Notes security, especially if all servers have manager access in database ACLs. Even if unsecured
servers don't have manager access to all resources on the Notes network, they still represent a security hole. If you don't provide physical security for your servers, you have to rely completely on database encryption to prevent people from gaining access
to confidential information through the local console. Physical security implies a locked, ventilated room. You can enhance physical security by taking these actions:
Don't use database encryption to enhance physical security. Doing so would require that all administrators accessing the server from the local console have access to the ID file that was used to encrypt the database. This method causes a situation where
multiple administrators use the same ID file, completely destroying your ability to maintain an audit trail for your Notes servers. You have no way of knowing which administrator is making modifications to an ACL, because everyone uses the same ID.
Therefore, encrypting a database on a server that is physically secure ends up making your Notes environment less secure, by creating a loophole for the people most likely to cause security problemsyour administrators.
With most of the network operating systems supported by Notes, you can use the server that Notes is running on as a file server. In fact, in the NetWare version of Notes, you have to turn off file serving if you don't want your server to be both a Notes
server and a file server. You should never use a Notes server as a file server for the following reasons:
You can specify a list of users, servers, or groups that are allowed to access a server by using a particular port. This scheme is useful when you want to set aside a particular port for a specific set of servers, or restrict access to dial-in ports. To
create an access control list for a port, follow these steps:
If you use both a port access list and a server access list, a name must be listed in both the port access list and the correct server access list to access the server.
Notes security is based on possession of ID files. ID files contain public and private encryption keys unique to each user in a Notes system (probably the world). Notes authenticates a user's identity by ensuring that the user has the correct private
key. Notes authentication is concerned only with identifying users, not controlling access to resources. Notes uses lists of names to control access to resources, and must therefore have some mechanism of binding encryption keys to names. Otherwise, users
could simply change the name stored in the local ID file and gain access to any database or server. Certificates are the mechanism for binding names and encryption keys. Certificates bind together a specific name and a private key. Certificates are issued
by a certifiera third party that both the server and client trust. By stamping an ID file with a certificate, a certifier validates the key/name pair contained in the ID file. A Notes server or client accepts a name if the other party also has a
certificate issued by a trusted certifier. In Notes, a certifier is trusted only if the local ID file contains a certificate from that certifier.
Chapter 3, "Understanding Security," contains more detail on the various types of certificates that Notes supports, such as organizational, organizational unit, flat, and cross certificates.
To issue certificates, a certifier must have possession of a certifier ID file. Certifier ID files are similar to other ID files. They have a pair of encryption keys and a name. Certifier ID files, with one exception, must also contain a certificate
that validates the key/name combination. The one exception is the organization-level certifier ID. The organizational certifier is the root of the certificate hierarchy. Each level in the certificate hierarchy is certified by the level above. For example,
Columbus/Marketing/Acme is certified by Marketing/Acme. Marketing/Acme is certified by Acme. Acme has no predecessor.
Before you create the certifier ID files used to stamp user and server ID files, you should read Chapter 5, "Building a Deployment Plan," which contains details about creating a naming structure for your organization. After you create a naming
structure for your organization, the next step is to create the certifier ID files that match your naming structure.
The first certifier ID file that you create is the organizational certifier ID file. The organizational certifier ID file is created automatically when you install the first server in your organization. You can also create a new organizational ID by
following these steps:
After creating the organizational ID file, keep it in a secure place.
WARNING: Never use an organization certifier to stamp an ID file of a user or server. Doing so makes providing a high level of security throughout your Notes network more difficult.
The only reason you should use the organizational certifier is to create organizational unit certifiers. Because of the sensitive nature of the organizational certifier ID, you should specify multiple passwords and store the file in a safe place. To use
the organizational certifier file to create organizational unit certifier ID files, follow these steps:
Repeat the process of creating organizational unit certifiers until you have finished creating the certifiers for your entire naming structure. Keep in mind that you can create an organizational unit certifier file using another organizational unit
certifier file, not just with an organizational certifier ID file. For example, to create the Acme/Marketing/New Products organizational unit certifier ID, you would specify Acme/Marketing as the certifier which will stamp the new certifier ID file.
All but the smallest organizations should protect all certifier ID files with multiple passwords. You use these same steps to add multiple passwords to any type of ID file, not just certifier ID files. To add multiple passwords, follow these steps:
Figure 18.2.
Use the Edit ID File Password List dialog box to add or remove passwords.
You must manually update the user names stored on multiple-password ID files when administrators change jobs or leave the company. The Administration Process doesn't automatically perform this task.
Every user and server must have a certified ID file. The certifier is responsible for issuing certificates to users and servers, and should always perform these steps herself. Never give access to a certifier ID file to anyone other than the
authorized certifier.
This section assumes that users have already received an ID file and are requesting a new certificate. For directions on issuing the initial certificates for a user, see the later section "Managing ID Files."
Before certifying a user, the certifier must guarantee that the name on the ID file is in fact the name of the person who will use the ID file, and that the name is unique. You can double-check the validity of an ID file by comparing the ID number
stored with the file you have to the one stored on the user's workstation. You can have users check the ID number of the ID on their individual workstations by choosing Tools | User ID.
A certifier issues a certificate for the following reasons:
You have several ways to accomplish the task of certifying ID files. Certifiers can receive ID files from administrators one at a time or en masse, or a user can request a new certificate. The communication between the certifier and user can take place
via Notes mail or floppy disk, as described in the following sections.
Certifiers can recertify groups of users simultaneously, using the Public Name and Address Book. You must be using the Administration Process to recertify groups of users. Chapter 13, "Administrative Tools," contains information on the
Administration Process.
To recertify a group of users, the certifier follows these steps (which must be carried out at the server with the Public Name and Address Book):
You recertify individual users or servers through Notes mail or by using floppy disks. No matter which method you use, the process involves the creation of a safe copy of an ID file that is certified and returned to the user. A safe copy is an ID
file without the private key. Because private keys are the cornerstone of Notes security, they never should be sent over the network. Safe copies enable a certifier to issue certificates to users and servers without having access to the private key.
A user can generate a request for a certificate at any time by using Notes mail, in three steps. The user generates a request, the certifier issues a certificate, and the user merges the certificate into his real ID file.
To generate a request for a certificate, the user follows these steps:
Figure 18.3.
User can request new certificates by using the User ID dialog box.
Because many users don't know the address of their certifier, consider providing this information in a How To database that users can check.
Figure 18.4.
Fill in the address of the certifier.
Notes sends a safe copy of the user's ID file to the certifier, using Notes mail. As Figure 18.4 shows, the request is signed by the user making the request (the Sign check box is selected and grayed). This system safeguards the ID file attached to the
mail message while it's being sent. If anyone manages to tamper with the file in transit, Notes warns the certifier when she receives the message.
The certifier issues a certificate for a request received through the mail by following these steps:
Figure 18.5.
Options for issuing hierarchical certificates.
Figure 18.6.
Options for issuing flat certificates.
If the certification causes a user's name to change, the Administration Process automatically updates the Name and Address Book and any database ACLs to the new distinguished name of the user. See Chapter 13, "Administrative Tools," for
details on configuring the Administration Process.
When the user receives the certified ID file, he needs to merge the new certificate with his ID file by following these steps:
The user should update any backup copies of his ID file after receiving the new certificate.
You should use Notes mail to fulfill user requests for certificates whenever possible. If the network isn't available, you can use the process outlined in the following short sections. Three steps are required: the user saves a safe copy of his ID to a
floppy disk (and gives it to the certifier), the certifier issues a certificate, and the user merges the certificate into his ID file.
To create a safe copy of the ID file, the user follows these steps:
Figure 18.7.
Creating a safe copy of an ID using the User ID dialog.
Using your name as part of the file name for the safe copy helps the certifier keep files organized.
The certifier stamps an ID file that she received on a floppy disk by following these steps:
If the certification causes a user's or server's name to change, the Administration Process automatically updates the Name and Address Book and any database ACLs to the new distinguished name of the user. See Chapter 13, "Administrative
Tools," for details on configuring the Administration Process.
When the user receives the safe copy with the new certificate, he needs to copy the certificate into his ID file. Administrators should perform this function for server ID files, using the workstation program running on the actual server. In either
case, follow these steps:
The user should make new backups of his ID file after receiving a new certificate. If the ID file is for a server, the administrator for the server should keep a backup in a safe place.
Cross certificates enable communication between two hierarchically certified organizations. Both organizations must use hierarchical certifiers to use cross certificates. A cross certificate is the stamp of approval from your local certifier that the
other organization's certifier is trustworthy. After your certifier issues a cross certificate for another organization, your users and servers trust the certificates issued by that other certifier.
Notes uses certificates during authentication. Because authentication is bidirectional (each party authenticates the other), both organizations must issue cross certificates. Both parties attempting to communicate (user and server, or two servers) must
trust the certifier that issued the certificate for the other party.
The cross certificate is created by your certifier and stored in your organization's Public Name and Address Book. When a user or server from the other organization attempts to access one of your servers, the server looks in the PNAB for a cross
certificate. If it finds one, authentication succeeds, and the server checks the appropriate ACLs to see if access should be given to the user or server.
To limit the number of users from the other organization that gain access to your Notes network, issue cross certificates using organizational unit certifiers. If you issue a cross certificate for an organizational certifier ID file, you are saying that
you trust all the certifiers in that entire organization. By insisting on the use of an organizational unit certifier, you need to trust only that certifier and his descendants. You also can cross certify individual users and servers. (Certifying specific
users and servers requires more work on the part of the certifier but limits access to specific users and servers.)
Cross certificates enable your users and servers to authenticate users and servers from the other organization. They do nothing to control access to servers. Use server access lists to limit the servers and users from the other organization that can
access your Notes network.
You can exchange cross certificates with another organization manually (using Notes mail, floppy disks, or the telephone) or automatically.
After a certifier creates a cross certificate for another organization, the users must copy-and-paste the cross certificate into their Personal Name and Address Books. Many users won't understand how to do this, or why they should. And you may not have
given users reader access to the Name and Address Book, preventing them from copying the cross certificate even if they know how. You can avoid the need to copy cross certificates by having users from your organization automatically create a cross
certificate when they first access the other organization's server. This strategy helps only when the server being accessed already has a cross certificate for your organization. Otherwise, the other server rejects all connections.
When a user accesses a hierarchically certified server from another organization for which she doesn't have a cross certificate, Notes presents a warning that explains a little about authentication and asks if the user wants to authenticate the identity
of the server being accessed. The user can respond to the warning message in one of three ways:
This same warning appears when users receive mail signed by a user from another organization. (Notes is really asking if you want to trust the signature.)
Certificates bind together public keys and names. A name is just a text string. A public key is just a long string of nonsense text. The process can be a little tedious, but you can transfer names and public keys over the phone (by talking). Notes takes
advantage of this fact and allows a certifier to talk on the phone to an administrator from another organization and create a cross certificate.
To create a cross certificate over the phone, follow these steps:
When using Notes mail or floppy disks to generate a cross certificate, the process takes two steps. First, each administrator generates a request for a cross certificate and issues a cross certificate. Notes stores a copy of the cross certificate in the
Name and Address Book. For example, if you use the L3Comm certifier ID file to cross certify the Acme certifier ID file, the L3Comm-issued cross certificate ends up stored in Acme's Name and Address Book. Any user certified with the Acme certifier ID File
can copy-and-paste the cross certificate from Acme's Public Name and Address Book into his Personal Name and Address Book and access your servers.
Use Notes mail when you have the ability to route mail to the other organization. Exchanging cross certificates using mail is far less burdensome than any of the other methods.
Each administrator follows these steps to generate a request for a cross certificate:
Figure 18.8.
Use Notes mail to request a cross certificate when you already have a way to route Notes mail to the other organization.
When a certifier receives a request for a cross certificate, he can issue a certificate by following these steps:
Users who need access to your servers must copy-and-paste the cross certificate from the Public Name and Address Book into their Personal Name and Address Books. Servers already have a local copy of the Public Name and Address Book and don't need the
cross certificate pasted into a Personal Name and Address Book.
When you first cross certify with another organization, you probably don't have a way to route Notes mail. If you have some other way of exchanging files, such as via the Internet or floppy disk, follow the steps in the next few short sections to
exchange cross certificates. You can also create cross certificates over the phone.
Each administrator should create a safe copy of the ID file to be cross certified. Follow these steps:
A certifier issues a cross certificate for a safe copy of a certifier ID file by following these steps:
If you used "local" as the registration server, you must copy the new cross certificate to the Public Name and Address Book before servers and users in your organization can communicate with the other organization.
ID files are the basis of Notes security. Your primary goal in managing ID files is to keep them secure. Users inevitably have an important role to play, although administrators can take steps such as keeping backup copies that minimize user
responsibilities.
Following are the basic ID tasks:
The following sections cover creation and distribution of ID files.
You should decide how you want to distribute ID files before you create any files. During the creation process, Notes asks how you want to distribute ID files . You have three options for distributing ID files: floppy disk, the Name and Address Book, or
both. You have these options no matter how you decide to create ID files (one at a time, or in batches). At some point during the creation of IDs, Notes presents the Register Person dialog box. By selecting the Other icon in this dialog box, you display
the options shown in Figure 18.9.
Figure 18.9.
Specifying how you want Notes to distribute ID files.
The default selection is to store new ID files in the Name and Address Book. This method is the preferred way of distributing ID files to users, who then store the ID files on their local hard drives. When a user first accesses Notes, the ID file is cut
from his person document and stored on his hard drive. You must give the user the correct password for the ID file. Notes requires a password at least one character long when storing ID files in the Address Book.
You also can choose to store the new ID file on a floppy disk. You may choose this option because you are storing all ID files on a file server, or to create an initial backup of the user's ID file. If you are creating a backup copy, select both the In
Address Book and In File options in the Other panel of the Register Person dialog box. If you are storing ID files on a file server, select just the In File option. You can override the default file name (a:\user.id) by selecting the Set ID File button.
Registering users is the process of creating ID files for users. You can create ID files one at a time, or in batches (using a file as input). For each user you plan to register, you must have the following information:
In addition to these items, you can optionally set up a location and administrator for each user. If you are registering multiple users at one time, you should specify a unique name for each ID file created.
You can save considerable time when setting up new users by using user profiles. A user profile lists the passthru, dial-up, and Internet servers common to a group of users, and the mail domain for a group of users. The information from the user profile
is entered automatically into the person document created for each user. Notes also creates the connection documents needed for users to reach the listed servers.
You create user profiles by using the Name and Address Book. Follow these steps:
Figure 18.10.
The User Setup Profile form.
You should create a user profile for each department or geographic region in your organization.
Follow these steps to register a single user:
Figure 18.11.
Registering a single user.
You can repeat these steps starting at step 5 for every user you want to register.
Notes can register many users at one time, using a file as input. The file contains one line for each user, with all the information on that line. Each entry contains the following information, in order, separated by semicolons:
The following listing shows an example of a user registration file.
Dahl;Andrew;;L3Comm;password;c:\notesids;adahl.id;notes1;mail;adahl.nsf;;;; Lesnick;Leslie;L;L3Comm;password;c:\notesids;llesnick.id;notes1;mail;llesnick.nsf;;;;
After you have created a registration file, use it to register multiple users by following these steps:
Some controversy exists about whether you should create backups of ID files. In organizations that don't make heavy use of multiple certificates or encryption keys, backing up an ID file can ease the administrative burden associated with lost ID files
and forgotten passwords. If your organization has a large number of users accessing databases that require special encryption keys, on the other hand, keeping current versions of ID files backed up may require more work than occasionally re-creating an ID
file.
WARNING: Backup ID files are a potential security hole. An administrator with access to the backup ID file can use it to impersonate the user who owns the ID file. You can alleviate this security hole by requiring multiple passwords on backup copies of IDs. (The user who owns the ID should be one of the people who knows a password.) Of course, if the administrator is also the certifier for your organization, no additional security holes are created by allowing him to keep backup copies of ID files. An administrator who is also a certifier can just as easily create a brand new ID file.
The most common reason for changing a user's name is that he has transferred to a new department. One of the key considerations when creating a naming structure is to minimize the name changes that will be required.
If you're changing the user's name from flat to hierarchical, see Chapter 17, "Administering Notes Databases," for details on changing from flat to hierarchical naming.
To change the common name for a user, you must have access to the correct certifier ID file for the user(s) being renamed. Follow these steps:
The Administration Process propagates the name change to all documents in the Name and Address Book and database ACLs that list this server as an administration server. See Chapter 13, "Administrative Tools," for more details.
When the user next connects with a server, the user's local copy of his ID file will be updated with the new name.
Lotus has licensed the public key cryptography technology from RSA CryptoSystems, a company in California. RSA is short for Rivest Salmir and Adelman, the professors at MIT who developed the public key algorithm. RSA technology is currently the most
widely used public key system. RSA claims a patent on all public key systems, although challenges to that patent were pending when this book was written. Notes can use public key encryption to
Perhaps the most common use of public key encryption in Notes is hidden from users. Public key encryption is a critical part of Notes authentication. Chapter 3, "Understanding Security, " covers Notes authentication in detail.
Administrators or users can cause outgoing mail, incoming mail, or saved mail to be encrypted automatically. Notes encrypts only the body of a message, not the header information, such as the To, From, and cc fields. Notes can only encrypt mail sent to
recipients for which Notes can find a public key in the Name and Address Book. Because no global public key storage currently exists for Notes, most organizations can send encrypted mail only to other users within the organization. You can't send encrypted
mail to non-Notes mail users, because they can't decrypt the message. Even if a non-Notes mail user has an entry in the Public Name and Address Book, he can't decrypt the message, because his mail system can't use the Notes mail ID file to retrieve the
private key, which is needed to decrypt the message.
Encrypt outgoing mail when you want to ensure that only the recipient can read the message; a mail message in transit may pass through several servers, and the path that the message takes isn't controllable by the user.
Only users can encrypt outgoing mail. To encrypt outgoing mail, follow these steps:
When you enable encryption of sent mail, Notes generates a different encryption key (known as a session key) for each message sent. Notes encrypts the message body, using the session key. Notes then encrypts the session key, using the recipient's
public key, and sends both the encrypted message and the encrypted session key to the user. Notes automatically decrypts the message when the recipient reads the message. Because only the intended recipient has the private key needed to decrypt the
message, only he can read the message.
Encrypting incoming mail prevents administrators or any unauthorized person from reading mail after it arrives in your mailbox. Encryption of incoming mail can be set up either by users or administrators. The administrators have the option of setting up
encryption for an individual user or for all users on a mail server. A user can encrypt incoming mail if he has editor access to his person document in the Name and Address Book by following these steps:
If the user doesn't have editor access to his person document, the administrator must perform these steps for him.
Administrators can turn on encryption of incoming mail for all users on a mail server by following these steps:
Mail_Encrypt_Incoming=1
The following steps detail the encryption process for incoming messages:
A user can encrypt all mail saved in her mail file, including drafts of unsent messages and messages saved after sending. This option has the same effect as turning on encryption of incoming mailit prevents administrators and others with access to
mail files from reading mail in the user's personal mailbox. To enable encryption of saved mail, users can follow these steps:
Only documents saved after this option is enabled are encrypted. Messages already in the mailbox aren't encrypted.
Database designers can include encryptable fields in documents. Notes automatically encrypts all encryptable fields in a document, if an encryption key is stored with that document. Because only a single encryption key can be stored with a document, all
encryptable fields within a document are encrypted by using the same key. Encrypted fields can be read only by a user who has the correct encryption key stored in her ID file. Users without the correct key can't read the data in an encrypted field. You can
enable encryption for a field by following these steps:
Encryptable fields display red brackets; non-encryptable fields have gray brackets.
If your organization has databases that are set up to encrypt fields within documents, you need a mechanism for distributing encryption keys to users. You can distribute encryption keys by sending encrypted mail to the users who require the encryption
keys. Users can merge the encryption keys into their ID files.
All encryptable fields in a document are encrypted as soon as an encryption key is associated with the document. The designer can indicate a specific set of keys to be associated with the document, using the Form Properties dialog box. To associate
default keys with a document, follow these steps:
You can encrypt data sent over a specific port. This tactic is most useful when Notes servers communicate over a public network, such as the Internet. Port encryption prevents unauthorized users from monitoring Notes data traffic. Notes servers detect
encrypted data sent via a port and automatically decrypt the data. Encrypting data sent over a port doesn't have a significant impact on performance, although it eliminates the chance of using any kind of data compression (lack of data compression is a
problem common to all encryption schemes). To encrypt data sent over a port, follow these steps:
Laptop users often carry replicas of sensitive information as they go about their everyday tasks. Thefts of executive's laptops are a common occurrence. To protect your data, you should encrypt all databases stored on laptops. Encrypting a database
makes it more difficult for a company that steals the laptop to read the data in Notes datbases, although Notes encryption is far from unbreakable. If the user's ID is also stored on the laptop, a hacker needs only to guess the password in the ID file to
gain access to encrypted databases.
You must have manager access to a database to turn on encryption. Notes provides three levels of encryption for databases:
You have to decide for each database the level of encryption needed. To encrypt a database, follow these steps:
Database encryption is intended to prevent unauthorized users who copy a database file by using operating system commands from gaining access to confidential information. Database encryption isn't meant as a wholesale substitute for field-level
encryption. An encrypted database can be decrypted only by a single user. Encrypted fields can be decrypted by anyone with the proper key. When Notes encrypts a database, it generates a random encryption key and uses that key to encrypt the database. The
encryption key is then encrypted by using the public key from the Public Name and Address Book for the name you specified in the Database Properties dialog box. Notes then appends the encrypted key to the database. When a user attempts to open the
database, Notes checks to see whether the local ID file contains a private key capable of decrypting a database.
Chapter 4, "Advanced Security Issues," covers electronic (digital) signatures in detail. In summary, an electronic signature is the digital equivalent of a handwritten signature, a mark that can be made only by a single individual. Electronic
signatures have the additional feature of guaranteeing that the document hasn't changed since it was signed. Notes enables you to add an electronic signature to a field or section of any form. The signing of fields and sections is controlled by the
database designer. To enable signing of a field or section, follow these steps:
Notes also allows signing of e-mail messages. The user can decide whether to electronically sign mail that he sends. To turn on signing, follow these steps:
This selection causes all mail sent from this user to be signed. Users also can decide to sign individual messages by selecting Sign as a delivery option.
The validity of electronic signatures is completely dependent on the security of ID files. Electronic signatures are assumed to be unique because ID files are assumed to be unique. If an unauthorized person has a copy of an ID file, he can use it to
forge signatures.
Notes licenses come in two flavors; International and North American. The U.S. government restricts the type of encryption technology that can be exported. In previous versions of Notes, the International version used weaker encryption than the North
American version. This system meant that data encrypted using a North American license couldn't be read by someone with an International license. This is no longer the case. With Lotus Notes version 4.0, both International and North American licenses use
64-bit keys to encrypt data and are therefore completely interoperable.
The International licenses generate keys of which 24 bits are given to the U.S. government. This leaves only 40 bits of protection from the U.S. government, a trivial decryption exercise for the U.S. government. Everyone other than the U.S. government
must decrypt the full 64 bits, a much harder task (although still clearly possible).
You can add access lists to individual documents, to control who can edit or read a document. A user with author access to a database can edit a document only if his name appears in a field of type Author. If you want to allow a user with author access
to edit documents he creates, you must include his name in a field of type Author. You can do this by programming a macro that executes when the user saves the document. The macro should contain the line
"Fieldxxx := @name([abbreviate]:author list)
where Fieldxxx is the name of the field of type Author.
You can restrict who can read a document by including a field of type Reader in the document. Any user not listed in the field can't read the document, and any server not listed in the field can't replicate the document. If you are going to use reader
fields, and you want documents with reader fields to replicate correctly, include the group LocalDomainServers in all reader fields. This action gives all servers reader access and the capability to replicate the document.
The simplest form of limiting access to a database is simply not to tell anyone about the existence of a database, and not list the database in a database catalog. Hiding databases is an effective technique, although not truly a security technique. The primary method of protecting a database is the access control list.
Protecting design elements such as forms and views is a useful user interface feature, but isn't an effective way to protect data. Forms and views simply filter data. If the user has access to another form or view that displays the underlying document,
he can still gain access to the data. If you want to protect the data in a database, you must rely on access control lists, encryption, and Author/Reader fields.
Roles are the primary method of protecting design elements such as forms and views. For some background on roles, see Chapter 3, "Understanding Security." In summary, roles are groups of users associated with a particular database. Roles
require additional administrative effort and aren't used in most organizations. You don't need to use roles to protect forms and views. Instead, you can use any group that appears in the access control list.
To specify the users who have the right to read documents created using a particular form, follow these steps:
To limit who can create documents with a form, make sure that the All Authors and Above check box is deselected. You specify the exact users and groups allowed to create documents by including them in the access control list and selecting them in the
list.
You can limit the users allowed to read documents that appear in a view by using the View Properties dialog box. Follow these steps:
Users with the ability to create personal views can create a view that displays the same documents as the protected view. The personal view could then be used to access any of the protected documents. Don't rely on view access lists to protect data from
view.
If you are distributing applications to third parties or building products for distribution, you will want to hide the design of your databases. Organizations may also want to hide the design of their internal databases, because this strategy also has
the effect of disabling all changes. To hide a database design, follow these steps:
This action prevents anyone without access to the master template from viewing the design or making any changes to the design. Hiding a database design institutes the following settings:
You can always unhide a design in the future by replacing the design with the master template, after disabling the hiding of formulas and LotusScript programs.
Sometimes you want to allow reader access to sensitive data, while taking reasonable efforts to control the spread of this information. You can discourage people who have reader access to data from printing, copying, or forwarding it to other users.
Follow these steps:
Notes provides an extensive list of security features that enable you to protect databases, documents, and design elements. You can protect against users gaining access from the server console or against eavesdroppers on telecommunication lines. For
further background on Notes security features, see Chapters 3 and 4.
Issuing IDs and certificates and managing access control lists are the primary jobs involved in Notes security. Notes administrators, database managers, and certifiers all play a role in administering Notes security. Certifiers are responsible for
issuing certificates for ID files. Database managers are responsible for maintaining the ACLs on the databases that they control. Notes administrators are responsible for limiting access to Notes servers and supporting the other two roles. Proper planning
and coordination can minimize the overhead needed to maintain a secure Notes system.