Previous Page TOC Next Page



— 18 —


Administering Notes Security


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.

Security Roles and Responsibilities


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.

Managing Access Control Lists


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.

Database 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.

Access Levels


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.

Adding Names to an Access Control List


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:

  1. Highlight the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Click the Add button.
  4. You can type the name you want to add, or look up the name in the Name and Address Book. Using the Name and Address Book prevents typographical errors and is the recommended approach. To get a name from the Name and Address Book, click the Person button, select the name you want, click Add, select and add any other names you want, and then choose OK.
  5. Set the access level and optional privileges for the names you have added to the access control list.
  6. Choose OK.

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.

Deleting Names from an Access Control List


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:

  1. Highlight the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Highlight the name you want to remove.
  4. Click the Remove button.
  5. Choose OK.

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.

Changing Names in an Access Control List


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:

  1. Highlight the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select the name you want to change.
  4. Choose Rename.
  5. You can type the new name or use a look up in the Name and Address Book. Using the Name and Address Book look up can help you avoid typographical mistakes. To get a name from the Name and Address Book, click the Person button, select the name you want, click the Add button, find and add any other names you want, and choose OK.

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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select the Advanced icon.
  4. In the Administration Server portion of the dialog box, select the Server radio button.
  5. Select an administration server from the drop-down list.
  6. If the administration server doesn't appear in the drop-down list, select Other and type the name of the administration server. All servers listed in the Name and Address Book appear in the drop-down list, so, if you don't see the server you want, check the local Name and Address Book.

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."

Understanding User Types


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 database—he 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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select the name in the access control list for which you want to specify a user type.
  4. Select the appropriate type from the User Type drop-down list.
  5. Choose OK.

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:

  1. Select the database icon from the workspace.
  2. Choose File | Database |Access Control.
  3. Select the Advanced icon.
  4. Click the option Look Up User Types for (Unspecified) Users.
  5. Choose OK.

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.

Resolving Duplicate Entries in an ACL


A user or server may be listed more than one time in an ACL. There are three situations in which this can happen:


Acceptable Entries in an ACL


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:

  1. Choose File | Database | Properties.
  2. Click the Information tab.
    The replica ID is listed near the bottom of the dialog box.

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.

Monitoring ACL Changes


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:

  1. Open the Statistics and Events database. The Statistics and Events database must have the file name EVENTS4.NSF.
  2. Choose Create | Monitors |ACL Monitor.
  3. Make sure that the monitor is enabled.
  4. Specify the full path and file name for the database you want to monitor (for example, Consulting/Contracts.NSF).
  5. Select an Event Severity of Normal to have all changes reported.
  6. Enter the mail address, including any domain names necessary, of the person who should be notified via mail. To avoid typographical mistakes, look up the address in the Name and Address Book.
  7. To monitor the ACL of all replicas, enter an asterisk (*) for the server name. Otherwise, enter the specific name of the server that you want to monitor.
  8. To have Notes fill in the description automatically, press F9.
  9. Choose Save ACL Monitor.

To disable ACL monitoring for a database, follow these steps:

  1. Open the Statistics and Events database.
  2. Choose View | Database Monitors.
  3. Open and edit the ACL monitor document for the database and server you want to disable.
  4. Make sure that Monitor Disabled is selected next to Enabled/Disabled.
  5. Choose Save ACL Monitor.

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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select the log icon.
  4. The date, time, and a brief description of all changes appear in the Change History box.

Using Roles


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:



NOTEThe 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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Click the Roles icon.
  4. Click Add.
  5. Type the name of the role.
  6. Choose OK.

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:

  1. Select an icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Click the Roles icon.
  4. Select the role that you want to remove.
  5. Click the Remove button.
  6. Choose OK.

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:

  1. Select the icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select a name to be added.
  4. Select the roles to be assigned to this name. A check mark appears next to each role as you select it.
  5. Repeat steps 3 and 4 for each name to be assigned one or more roles.
  6. Choose OK.

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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select a name in the ACL. All roles assigned to this name have a check mark.
  4. Repeat step 3 for each name in the access control list.
  5. Choose OK.

Using the Default ACLs


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.



TIP 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.



Solving Access Control Problems


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.

Enforcing Local Security


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:

  1. Select the database icon from the workspace.
  2. Choose File | Database | Access Control.
  3. Select the Advanced icon.
  4. Select the option called Enforce a Consistent Access Control List Across All Replicas of This Database.
  5. Choose OK.

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 Server Access


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).

Allowing and Denying Access


To specify a list of users or servers that can access this server, follow these steps:

  1. Open the server document for the server.
  2. Expand the Restrictions section of the form.
  3. In the Access Server field, enter the names of users or servers that should be allowed access.
  4. Save the server document.

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.



NOTEYou 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.



Using Anonymous Connections


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:

  1. Open the Name and Address Book.
  2. Open the server document for the server that will allow anonymous connections.
  3. Type "Yes" in the Allow Anonymous Connections field in the Security section.
  4. Save the server document.

Restricting Access to Directories


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:

  1. Create a directory that isn't part of the Notes data path.
  2. Place a directory link from the Notes data path to the new directory.
    A directory link is a text file with a .DIR extension. The first line in the file should be the full path name of the secure directory. All other lines in the file are treated as an access control list for the new directory.
  3. Specify an access control list for the new directory.

Listing 18.1 shows an example of a directory link.

Listing 18.1. You can create secure directories by using directory link files.


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.


Providing Physical Security for Notes Servers


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 problems—your administrators.

Notes Servers as File Servers


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:


Restricting Access to Server Ports


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:

  1. Create a group called AccessPortx (where x is the name of the port), listing all users and servers with access to the port. Use nested groups whenever possible.
  2. Enter the line ALLOW_ACCESS = AccessPortx. Alternatively, if you want to deny access to a port, use the key word DENY_ACCESS and create a group called DenyAccessPortx. You must restart the server to make these changes effective.

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.

Managing Certificates


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 certifier—a 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.

Creating Certifier ID Files


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.

(e)Organizational Certifiers

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:

  1. Choose File | Tools | Server Administration.
  2. Click the Certifiers icon.
  3. Select Register Organization.
  4. Specify the correct registration server by clicking the Registration Server button and choosing the correct server from the drop-down list.
    The registration server must be available on the network before you can proceed. The registration server does the actual work of creating the ID file and update the Name and Address Book.
  5. (Optional) Specify a country code for this organization. Country codes are useful when communicating internationally.
  6. Specify your organizational name. The name you use here should be the exact name you chose for the root of your naming scheme.
  7. Enter a password for the new certifier ID file.
  8. (Optional) Specify the mail address of the certifier who will be authorized to stamp user and server ID files, using this new certifier ID file.
  9. (Optional) Select Other Certifier Settings if you want to add a comment or location to this ID file, or you want to specify a license type or minimum password length.
  10. Click the Register button.
  11. Enter a name for the new ID file.
  12. Choose Save.

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.


Organizational Unit Certifiers

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:

  1. Choose File | Tools | Server Administration.
  2. Click the Certifiers icon.
  3. Select Register Organizational Unit.
  4. Enter the password for your current ID file.
  5. Specify the correct registration server. The registration server must be available on the network for this process to continue. The registration server does the actual work of creating the ID file and updating the Name and Address Book.
  6. Specify the correct organizational certifier.
  7. Specify the name of the organizational unit, using the exact name planned in your naming structure.
  8. Enter a password for the new organizational unit certifier file.
  9. (Optional) Specify the mail address of the certifier who will be authorized to stamp ID files, using this new file.
  10. (Optional) Select other certifier settings if you want to add a comment or location to this ID file, or you want to specify a license type or minimum password length.
  11. Click the Register button.
    Notes creates the certifier ID file.

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.

Specifying Multiple Passwords


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:

  1. Choose File | Tools | Server Administration
  2. Click the Certifiers icon.
  3. Select Edit Multiple Passwords.
    A file selection dialog box appears.
  4. Select the ID file you want to edit.
    The Edit ID File Password List dialog box opens. Figure 18.2 shows the dialog box.

    Figure 18.2.
    Use the Edit ID File Password List dialog box to add or remove passwords.

  5. Enter a user/password combination for this file. The user entries are for administrative convenience only—to help you remember who knows the various passwords. The user entries aren't required when trying to access the ID file.
  6. Click Add.
  7. Repeat steps 5 and 6 for each user/password combination.
  8. Choose OK.

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.

Recertifying Users and Servers


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.



NOTEThis 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.

Recertifying Groups of Users

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):

  1. Open the Public Name and Address Book.
  2. (recertifying users) Open the People view.
    (recertifying servers) Open the Servers-Servers view.
  3. Select the users or servers you want to recertify. All selections must have been certified with the same certified ID file.
  4. (recertifying users) Choose Actions | Recertify Person.
    (recertifying servers) Choose Actions | Recertify Server.
  5. Open the certifier ID file used to certify the selected servers or users. You must use the same certifier that was originally used to certify the ID files.
  6. Enter the password for the certifier ID file.
    The Certify ID dialog box opens.
  7. (optional) Change the expiration date.
  8. (optional) Enter an expiration date for a subset of users.
  9. Choose Certify.

Certifying Through Notes Mail

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.

Generating a Certificate Request

To generate a request for a certificate, the user follows these steps:

  1. Choose Tools | User ID. You may need to enter a password before proceeding.
    The User ID dialog box opens.
  2. Click the Certificates icon. Figure 18.3 shows the resulting dialog box.

    Figure 18.3.
    User can request new certificates by using the User ID dialog box.

  3. Choose Request Certificate to display the Mail Certificate Request dialog box (see Figure 18.4).
  4. Fill in the correct address for the certifier.


    TIP Because many users don't know the address of their certifier, consider providing this information in a How To database that users can check.


  5. Choose Send.

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.

Issuing the Certificate

The certifier issues a certificate for a request received through the mail by following these steps:

  1. Open the message containing the request.
  2. Verify the identity of the user and the ID number in the ID file received.
  3. Choose Actions | Certify Attached ID File.
  4. Open the correct certifier ID file.
    If the ID file already contains a hierarchical certificate, the Certify dialog box opens. The certifier can replace the existing certificate (which changes the user's name) or issue a cross certificate (covered a little later).
  5. Choose Re-certify.
    The Certify ID dialog box displays different options, based on whether a hierarchical or flat certificate is being created. Figure 18.5 shows the options for issuing hierarchical certificates; Figure 18.6 shows the options for issuing flat certificates.

    Figure 18.5.
    Options for issuing hierarchical certificates.

    Figure 18.6.
    Options for issuing flat certificates.

  6. (optional) Change the certificate expiration date. The suggested default is two years. If you are certifying many users at one time, change the date to avoid having to recertify all users at the same time two years in the future.
  7. (optional) Enter a minimum password length (hierarchical only). Eight characters is the recommended minimum.
  8. (flat certificates only) Deselect Trust Other Certificates Signed by This Certifier if you are certifying an ID file from a different organization.
  9. (optional) Change the registration server by clicking the Server button. (The registration server must be available on the network before you can proceed.) The registration server is the server that does the actual work of changing the user's entry in the Name and Address Book.
  10. Choose Certify.
    Notes generates a certificate for the ID file. The Mail Certified ID dialog box appears.
  11. Enter the user's name in the To field.
  12. (recommended) Select the Sign check box.
  13. Choose Send.
    Notes mails the certified ID file to the user.

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.

Accepting the Certificate

When the user receives the certified ID file, he needs to merge the new certificate with his ID file by following these steps:

  1. Open the message.
  2. Choose Mail | Accept Certificate.
    For hierarchical certificates, the Accept New ID Information dialog box opens. For flat certificates, Notes posts the Merge Certificate into Your ID File dialog box.
  3. (hierarchical) Choose OK.
    (flat) Choose Accept.

The user should update any backup copies of his ID file after receiving the new certificate.

Certifying via Sneaker Net

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.

Creating a Safe Copy of the ID File

To create a safe copy of the ID file, the user follows these steps:

  1. Choose File | Tools | User ID.
    The User ID dialog box opens.
  2. Choose More Options. Figure 18.7 shows the additional options that appear.

    Figure 18.7.
    Creating a safe copy of an ID using the User ID dialog.

  3. Choose Create Safe Copy. Notes displays a file management dialog box.
  4. Enter a name for the safe copy.


    TIP Using your name as part of the file name for the safe copy helps the certifier keep files organized.


  5. Choose Save, and save the safe copy to a floppy disk.
  6. Give the floppy disk to the certifier.

Issuing the Certificate

The certifier stamps an ID file that she received on a floppy disk by following these steps:

  1. Choose File | Tools | Server Administration.
  2. Click the Certifiers icon.
  3. Choose Certify ID.
  4. Open the desired certifier ID file.
  5. Enter the password for the certifier ID file.
  6. Open the safe copy of the ID file to be certified.
    The Certify ID dialog box opens. The dialog changes based on whether a hierarchical or flat certificate is being created. (Refer to Figures 18.6 and 18.7 to see an example of each version.)
  7. (optional) Change the certificate expiration date. The suggested default is two years. If you are certifying many users at one time, change the date to avoid having to recertify all users at the same time two years in the future.
  8. (optional) Enter a minimum password length (hierarchical only). Eight chracters is the recommended minimum.
  9. (flat certificates only) Deselect Trust Other Certificates Signed by This Certifier if you are certifying an ID file from a different organization.
  10. (optional) Change the registration server by clicking the Server button. (The registration server must be available on the network before you can proceed.) The registration server is the server that does the actual work of changing the user's entry in the Name and Address Book.
  11. Choose Certify.
    Notes generates a certificate for the ID file.
  12. The ID file is returned to the user, who then follows the steps in the next section )"Merging the Certificate").

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.

Merging the Certificate

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:

  1. Insert the floppy disk with the certified safe copy into the disk drive.
  2. Choose File | Tools | User ID.
    The User ID dialog appears.
  3. Choose More Options.
  4. Choose Merge a Copy.
  5. Open the certified safe copy on the floppy disk.
  6. Choose Done.

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.

Issuing Cross Certificates


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.

Automatic User Cross Certification

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.)

Cross Certifying via Telephone

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:

  1. Choose File | Tools | Server Administration.
    Notes displays the Administration Server panel.
  2. Click the Certifiers icon.
  3. Choose Cross Certify Key to display a file selection dialog box.
  4. Select the certifier ID file you want to use.
  5. Enter the password for the ID file.
  6. Enter the name of the organizational unit certifier ID file you want to cross certify.
  7. Enter the public key for the organizational unit certifier ID file. The public key is available in the Server-Certificates view of the Name and Address Book. Open the certificate document for the certifier in Edit mode to view the public key.
  8. Choose Certify.
    Notes creates a public key and stores it in the Public Name and Address Book.

Requesting a Cross Certificate via Notes Mail

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.

Requesting a Cross Certificate

Each administrator follows these steps to generate a request for a cross certificate:

  1. Choose File | Tools | User ID.
    The User ID dialog box opens.
  2. Click the Certificates icon.
  3. Choose Request Cross Certificate to display a file selection dialog box.
  4. Select the ID file you want to cross certify.
    The Mail Cross Certificate Request dialog box appears (see Figure 18.8).

    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.

  5. Enter the address of the certifier in the other organization.
  6. Choose Send.
    Notes mails a safe copy of the ID to the other certifier.

Cross Certifying an ID

When a certifier receives a request for a cross certificate, he can issue a certificate by following these steps:

  1. Open the message containing the request.
  2. Choose Actions | Cross Certify Attached ID File. Notes displays a file selection dialog box.
  3. Select the certifier ID file you want to use.
  4. Choose Certify.
    Notes creates a cross certificate and stores it in the Public Name and Address Book.

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.

Requesting a Cross Certificate Without Notes Mail

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.

Creating a Safe Copy

Each administrator should create a safe copy of the ID file to be cross certified. Follow these steps:

  1. Choose File | Tools | Server Administration.
    Notes displays the Server Administration panel.
  2. Choose Administration | ID to display a file selection dialog box.
  3. Select the certifier ID file for which you want to create a cross certificate.
    The Enter Password dialog box opens.
  4. Enter the password for the certifier ID file.
    The User ID dialog box appears.
  5. Choose More Options.
  6. Choose Create Safe Copy.
  7. Enter a file name for the safe copy. The default name is SAFE.ID. You can help eliminate confusion by using the name of your organization somewhere in the file name.
  8. Choose Save.
  9. Send the safe copy to the certifier at the other organization.

Issuing the Cross Certificate

A certifier issues a cross certificate for a safe copy of a certifier ID file by following these steps:

  1. Choose File | Tools | Server Administration.
    Notes displays the Server Administration panel.
  2. Click the Certifiers icon.
  3. Choose Cross Certify ID File. Notes displays a file selection dialog box.
  4. Select the certifier ID that you want to use to certify the cross certificate. (The certifier ID file from your organization.)
  5. Enter the password for the certifier ID file.
    Notes redisplays the file selection dialog box.
  6. Select the safe copy received from the other organization.
  7. (optional) Select a registration server. The registration server is the server where the cross certificate is stored in the Public Name and Address Book. The registration server must be available on the network before you can create the cross certificate.
  8. (optional) Change the expiration date. The default is ten years.
  9. Choose Cross Certify.
    Notes adds the cross certificate to the Name and Address Book on the registration server.

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.

Managing ID Files


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.

Distributing 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 New Users


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.

User Profiles

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:

  1. Open the Name and Address Book.
  2. Select the Server-Setup Profiles view.
  3. Click the Add Setup Profile button.
    Notes displays the User Setup Profile form (see Figure 18.10).

    Figure 18.10.
    The User Setup Profile form.

  4. (optional) Enter the name of the InterNotes server.
  5. (optional) Enter the name and phone number of the default passthru server.
  6. (optional) Enter the names and phone numbers of all remote servers.
  7. (optional) Enter the mail domain name for these users.
  8. Choose Save.
  9. Choose Close.

You should create a user profile for each department or geographic region in your organization.

Registering a Single User

Follow these steps to register a single user:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel opens.
  2. Click the People icon.
  3. Choose Register Person.
    The Enter Password dialog appears.
  4. Enter the password for the certifier ID file.
    The Register Person dialog box is redisplayed.
  5. (optional) Specify a registration server. The registration server's Name and Address Book will be updated with the new person record and ID file. The specififed registration server must be available on the network before you can complete registration.
  6. (optional) Specify a new certifier ID.
  7. Specify a security type. See the later section "International Compatibility" for details on the differences between North American and International security.
  8. Specify an expiration date. The default is two years.
  9. (optional) Specify the profile you want to use.
  10. Choose Continue.
    The Register Person dialog box reappears (see Figure 18.11).

    Figure 18.11.
    Registering a single user.

  11. Click the Mail icon.
  12. Specify the type of mail system for the user.
  13. Specify the home server for the user.
  14. Click the Other icon.
  15. Choose to store the ID file in the Address Book, in a directory, or both. For details on making this selection, see the earlier section "Distributing ID Files."
  16. (optional) Enter a location for this user.
  17. (optional) Enter the administrator for the user's location.
  18. (optional) Add a comment about the user.
  19. Choose Register.

You can repeat these steps starting at step 5 for every user you want to register.

Registering Multiple Users

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:

  1. Choose File | Tools | Server Administration.
    Notes displays the Server Administration panel.
  2. Click the People icon.
  3. Choose Register from File.
    The Enter Password dialog box opens.
  4. Enter the password for the certifier ID file.
    The Register Person dialog box appears.
  5. (optional) Specify a registration server. The registration server's Name and Address Book will be updated with the new person record and ID file. The registration server specified must be available on the network before you can complete registration.
  6. (optional) Specify a new certifier ID.
  7. Select a security type. See the later section "International Compatibility" for details on the differences between North American and International security.
  8. Specify an expiration date. The default is two years.
  9. (optional) Specify the profile you want to use.
  10. Choose Continue.
    Notes posts a file selection dialog box.
  11. Open the text file containing the user information.
    The Register People from Text File dialog box appears.
  12. Enter a minimum password length for the users. Make sure that all the passwords specified in the file meet this requirement.
  13. Specify a license type for the users.
  14. (optional) Specify a user profile for the users.
  15. Click the Mail icon.
  16. Specify the type of mail system for these users.
  17. Specify the home server for the users.
  18. Click the Other icon.
  19. Choose to store ID files in the Address Book, in a directory, or both. For details on making this selection, see the earlier section "Distributing ID Files."
  20. Choose Register.
    Notes creates ID files for all users listed in the file. When the ID files are complete, Notes displays a confirmation message with the number of users registered.

Backing Up ID Files


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.


Changing a User's Name


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:

  1. Open the Name and Address Book.
  2. Select the People view.
  3. Select the person documents for the users to be renamed.
  4. Choose Actions | Rename.
  5. Choose Change Common Name.
    Notes displays a file selection dialog box.
  6. Open the certifier ID file for the users.
    The Enter Password dialog box appears.
  7. Enter the password for the certifier ID file.
  8. Change the user's first name, last name, or middle initial as desired.
  9. Specify an expiration date for the new certificate.
  10. (if needed) If a user exists with this name, certified by the same certifier ID file, specify a unique qualifier for this user to differentiate between the two users. Enter the qualifier next to the New Qualifying Org. Unit option. This qualifier will appear between the user's common name and the certifier name.
  11. Choose Rename.

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.

Notes Encryption


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.

Encrypting Mail


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:

  1. Choose File | Tools | User Preferences.
  2. Click the Mail icon.
  3. Select the Encrypt Sent Mail check box.
  4. Choose OK.

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:

  1. Open the person document in Edit mode.
  2. Select Yes for the Encrypt Incoming Mail option.
  3. Choose Save.

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:

  1. Add the following line to the NOTES.INI file.
    
    Mail_Encrypt_Incoming=1
    
    
  2. Save the NOTES.INI file.
  3. Reboot the server.

The following steps detail the encryption process for incoming messages:

  1. Generating a new encryption key for each message.
  2. Encrypting the message with the key.
  3. Encrypting the key, using the recipient's public key stored in the Name and Address Book.
  4. Storing the encrypted key with the encrypted message in the user's mailbox.

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 mail—it 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:

  1. Choose File | Tools | User Preferences.
  2. Click the Mail icon.
  3. Select the Encrypt Saved Mail option.
  4. Choose OK.

Only documents saved after this option is enabled are encrypted. Messages already in the mailbox aren't encrypted.

Field-Level Encryption


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:

  1. Open the form containing the field.
  2. Right-click the field to display the Field Properties dialog box.
  3. Click the Options tab.
  4. Select Enable Encryption for This Field from the Security Options drop-down list.
  5. Close the Field Properties dialog box.

Encryptable fields display red brackets; non-encryptable fields have gray brackets.

Distributing Encryption Keys


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.

Specifying Encryption Keys for Documents


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:

  1. Open the form definition for the document.
  2. Right-click to display the Form Properties dialog box.
  3. Click the Security tab.
  4. Select the appropriate encryption key from the Default Encryption Keys drop-down list. If no keys are listed, the current ID file has no encryption keys stored in it. Before being able to associate a specific key with a document, you must create that key and store it in the designer's ID file.
  5. Choose OK.

Port Encryption


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:

  1. Choose File | Tools | User Preferences.
  2. Click the Ports icon.
  3. In the Communication Ports list box, select the port that you want to encrypt.
  4. Select the Encrypt Network Data check box.
  5. Choose OK.

Encrypting Databases


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:

  1. Choose File | Database | Properties.
  2. Click the Encryption button.
  3. Select the option Locally Encrypt This Database.
  4. Select the desired level of encryption from the drop-down list.
  5. If you want to encrypt this database for someone other than yourself, click the For button and select the name from the list that appears.
  6. Choose OK.

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.

Electronic Signatures


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:

  1. Open the form containing the field or section.
  2. Right-click the field and display the Field Properties dialog box.
  3. Click the Options tab.
  4. Select Sign If Mailed or Saved from the Security Options drop-down list.
  5. Choose OK.

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:

  1. Choose File | Tools | User Preferences.
  2. Click the Mail icon.
  3. Select the Sign Sent Mail check box.
  4. Choose OK.

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.

International Compatibility


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).

Protecting Documents


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.



TIP 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 Forms and Views


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.

Protecting Forms


To specify the users who have the right to read documents created using a particular form, follow these steps:

  1. Open the form definition.
  2. Right-click anywhere in the form and display the Form Properties dialog box.
  3. Click the Security tab.
  4. To specify individuals allowed to read documents created with this form, make sure that the All Readers and Above check box is deselected.
  5. Select from the list box only those names and groups that should be able to read documents created with this form.

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.

Protecting Views


You can limit the users allowed to read documents that appear in a view by using the View Properties dialog box. Follow these steps:

  1. Open the view definition.
  2. Choose Design | View Properties.
  3. Click the Security tab.
  4. Make sure that the All Readers and Above check box is deselected.
  5. Select the appropriate names and roles from the list.

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.

Hiding Database Designs


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:

  1. Create a master template for the database.
  2. Create a new database, based on the master template.
  3. Select the new database icon from the workspace.
  4. Choose File | Database | Replace Design.
  5. Select the master template and make sure that the Hide Formulas and LotusScript check box is selected.
  6. Choose Yes.

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.

Preventing Printing, Copying, and Forwarding


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:

  1. Open the form definition.
  2. Right-click somewhere in the form and display the Form Properties dialog box.
  3. Click the Security tab.
  4. Select the option Disable Printing, Forwarding, Copying to Clipboard.
  5. Save the form.

Summary


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.

Previous Page Page Top TOC Next Page