Notes security is a powerful, important tool for your company. Lotus Notes and Domino security are multi-layered and comprehensive. Domino and Notes security have three main goals:
Domino server security—securing the data on the server
Mail security—protecting mail from prying eyes
Notes workstation security—protecting your workstation from malicious programs
The Domino server’s job is 1) to store data, 2) to accept data only from users authorized to submit data to it, and 3) to send data only to users authorized to receive it. To achieve these goals, Domino server security involves the following considerations:
Who can authenticate with the server
Who can access the server
Who can access each database
Who can access views, forms, and documents within a database
Who can access fields within a form
To do its job, therefore, the Domino server usually needs to know who the users are when they make requests for data. To learn its users’ identity, it requires them to authenticate. Domino supports three authentication modes:
Anonymous—. If you’re accessing Domino using a web browser client and you request access to data that is not restricted, Domino won’t require you to authenticate. You will be anonymous to Domino. An example of unrestricted data would be the information on your company’s home page. It’s freely made available to the public at large. The server doesn’t care who you are and just sends it to you.
Name and password—. If you’re accessing Domino using a web browser client and you request access to data that is restricted, Domino will require you to authenticate. You’ll have to enter your name and password, which your browser will submit to the server. If the server can match your name to a Person document in the Domino Directory, and your password matches the password recorded there, the server will consider you authenticated. It assumes you are the person named in the Person document.
Certificate-based—. If you’re accessing Domino using the Lotus Notes client, you will authenticate with the Domino server by sending a certificate to it. The certificate is a signed document stored in your Notes ID file. It states that you are the owner of a public key contained in the certificate. By analyzing the signature, the server can determine whether to accept the certificate. If the server does accept it, it will use the contained public key to encrypt a session key, then send the encrypted session key back to you. If you really are the owner of the public key, you will possess a private key in your Notes ID file that can decrypt the encrypted session key. Your private key is unique to you and is the only key that can decrypt data encrypted with your public key. By possessing it and therefore being able to decrypt the session key, you prove to the server that you are the person named in the certificate. The server now knows who you are; you are authenticated.
Note
While you may use the same password when accessing your mail in a browser as when opening your Notes client, they are not in fact the same password. The password you enter in a web browser is your Internet password, which is recorded in your Person document in the Domino Directory. Your Notes password is recorded in your Notes ID and unlocks it so you can extract your private key from it. To change the first, you have to edit the Internet password field in your Person document (or choose Change Password in Domino Web Access, see Chapter 16, “WebMail and Domino Web Access”). To change the second, you choose File, Security, User Security in Notes, then choose Change Password. Your administrator can optionally set up synchronization of the two passwords, so that changing one causes the other to be changed as well.
Note
Because authentication depends on your private key, it is password protected in your Notes ID file. It is very important that you keep your Notes ID password secret. If I could obtain a copy of your ID file and I knew the password, I could masquerade as you. I could gain access to data that only you are supposed to see. I could sabotage you by sending malicious emails while logged in as you. Don’t reveal your Notes ID password to anyone!
If you cannot authenticate with a Domino server, Notes may display one of the following messages: “You cannot log in using the supplied User ID file, smartcard or password” or “The server’s Domino Directory does not have any cross certificate capable of authenticating you”. If you can’t authenticate from a browser, you will receive an “Error 401 User Not Authenticated” message.
Having authenticated with the server, you may still not be authorized to do business with it. You must also be in the server’s list of users who can have access to that particular server. Just because you can authenticate does not mean you have authority to access all the servers in the organization.
If, when you try to open a database that resides on a Domino server, an access list blocks your access to the server or the database, you will see a message such as this: “You are not authorized . . . .” (The words not authorized will appear in the message.)
If you see such a message, and you think you should be authorized to access the server or the database, tell your administrator the exact wording of the error message. The administrator controls the server access lists and usually the database access lists as well and should be able to correct the problem.
After you establish access to the server, the next step is to gain access to databases on that server. Database access is determined by settings in the Access Control List (ACL) for each database.
When you open a database, the Security button on the status bar displays a symbol representing the level of access you have to that database. Click the Security button on the status bar and the Groups and Roles dialog box appears, indicating your access level.
Each person is granted one of seven levels of access to a database:
No Access—. This denies you access to the database. You can’t read any of the documents in the database, and you can’t create new documents.
Depositor—. You can create documents but can’t read any of the documents in the database—including the ones you create yourself. You might be granted this access level to cast a ballot in a voting database, for example.
Reader—. You can read the documents in the database, but you can’t create or edit documents. You might have this level of access to a company policy database so that you can read policies but can’t create or change them.
Author—. You can read documents created by others. You may be able to create documents. You may be able to delete some documents. You may be able to edit some documents or parts of them. Whether you can create or delete documents depends on privileges that must be assigned to you along with the assignment of Author access. Which documents you can edit or delete and which parts of a document you can edit depend on the design of the database. Most commonly, though, you will be able to create documents and to edit and perhaps delete only the documents you created.
Editor—. Editors can edit every document in a database, except ones that they can’t read. Typically only one or two people, who are generally in charge of keeping a database, have Editor access.
Designer—. A designer can do everything an editor can, and can create or change any design elements of the database. To change the design of a form in a database, you must have designer access. Designers can also control some replication settings of a database.
Manager—. A manager can access everything a designer can. A manager also can assign and modify the Access Control List (ACL), modify replication settings, and delete a database from the server.
Additional permissions in the ACL control whether you can create documents; delete documents; create personal views, folders, and agents; and replicate and copy documents. Also, some databases may have a class of documents called “public documents.” You can have read or write access to public documents independently of your level of access to regular documents. The most notable example of such a database is your mail database. All calendar and to-do documents in the mail database are “public documents.” This makes it possible for you to give other people access to your calendar and to-do list without letting them read your mail.
The database access control list isn’t the only control over database access. Within a database, there are additional access lists that control who can use certain views and forms, who can read certain documents, and who can edit what parts of documents. In addition, certain fields within a document may be encrypted so that only some people can read their contents.
In general the designer of the database controls these features. But users can control who is permitted to read documents which they created (or can edit). If you have the right to edit a document, you can limit the authorized readers of that document in its Reader Access List. To do so, follow these steps:
Open the document or select it within a view or folder.
Press Alt+Enter to open the Document Properties box.
Select the Security tab.
Deselect All readers and above, then click the Add read access button to the right of the reader list. The Select Names dialog box will open.
Select the names of the people who you want to be able to read the document. Click OK. Then press Alt+Enter to close the Properties box. Save and close the document if it is in Edit Mode.
Because mail crosses the network between your workstation and server, and between servers, it is vulnerable to being read by eavesdroppers and to being altered by them en route. To protect against these vulnerabilities, Notes allows you to encrypt and sign messages.
When you encrypt a message, you encrypt it in such a way that only the named recipient can decrypt and read it. You do this by encrypting it with the recipient’s public key. You can obtain another Notes user’s public key from his/her Person record in the Domino Directory. You can obtain a non-Notes user’s public key (if one exists) from other directories (Domino or LDAP) that your administrator may have made available to you for that purpose. And you can store copies of people’s public keys in their Contact documents or in Cross-Certificate documents that Notes may have created for you in your Personal Directory.
Text encrypted with one’s public key can only be decrypted with one’s private key. In a well-secured Notes domain, the only useable copy of one’s private key is in one’s own Notes ID file. So, as long as each Notes user does not share with others the password of his/her Notes ID file, only your recipients will be able to read encrypted mail you send to them.
To assure your mail recipients that messages you send to them were actually sent by you (and not some imposter) and have not been altered en route to them by some interloper, you can sign your messages. When you sign a message, you create a “digest” of your message, encrypt the digest with your private key, then send the encrypted digest along with the message to the recipient.
Note
Don’t confuse the mail signing discussed here with the written “signature” that Notes permits your to place at the bottom of your email messages. Use the electronic signature we are discussing here for security purposes. Use the written signature (see Chapter 5, “Using Mail Tools”) to append “boilerplate” information about yourself to the ends of your messages.
Your recipient decrypts the digest with your public key. That assures the recipient that you must have created the digest, because a digest encrypted with your private key can only be decrypted with your public key, and (in a well-secured Notes domain) yours is the only useable copy of your private key. In addition, the recipient can create his/her own digest of the message. If the recipient’s digest comes up identical to the one you created, the message can not have been altered en route.
Mail encryption and signing are enabled by default for Notes mail, but not for Internet mail. You can use them whenever you want when sending mail to other Notes mail users. But you can only send and receive signed and/or encrypted Internet mail if your Domino administrator has implemented Domino’s Internet mail security features, known as Secure MIME (S/MIME). See Chapter 3, “Email Basics,” to learn how to send signed or encrypted mail.
One of Notes’s most attractive features is that it protects us from malicious software being run on our computer. This is no small benefit in a computing world where spam and phishing messages arrive in our mail every day and where users’ computers are being infected by viruses and Trojan horses and taken over by those programs to be used as “zombie” computers to spread even more spam, phishing messages, viruses, and Trojan horses.
The Notes feature that protects us from these things is the Execution Control List (ECL). When a program tries to execute within a running Notes session, Notes checks to see who “signed” the program, then checks the ECL to see what sort of things the programs signed by the signer are permitted to do. Most malicious programs aren’t signed at all (because their authors don’t want you to know who they are) and, by default, Notes doesn’t permit unsigned programs to do anything that could possibly harm your computer or data.
Other programs may be signed by Lotus itself or by some developer or other entity within your own company. Again by default, Notes trusts Lotus-signed programs to do anything, no matter how potentially dangerous. How much it trusts programs signed by entities within your organization (or other third-party signers) depends on how your administrator may have preconfigured your ECL when setting up your workstation and what changes you or your administrator may have made or allowed since that time.
You can see your ECL and examine its settings by doing the following:
In the File menu, choose Security, User Security. Enter your Notes password. The User Security dialog box will open, looking much like the example in Figure A.1.
Expand What Others Do in the outline. Examine Using Workstation, Using Java, and Using JavaScript. Select each listed entity to see the actions that programs signed by that entity are permitted to take. Click OK, Close, or Cancel when finished.
You can make changes directly in the ECL, but generally you will not and should not. Typically your ECL will change, if at all, as a result of two other kinds of action. First, your administrator can make changes to organization-wide ECLs and push them down to user workstations. Second, you might be able to make changes indirectly, depending on how you react when a program tries to take an action that it hasn’t been pre-authorized for in the ECL. When that happens, you will see an Execution Security Alert. This dialog box warns you of the impending action (see Figure A.2) and presents options for dealing with it.
Figure A.2. Notes uses this dialog box to warn you that a program is trying to take an action that it isn’t authorized for in the ECL. If you aren’t sure whether to allow it, contact your administrator.
The choice you make may cause Notes to update the ECL with new rights. Specifically, if you choose the last option, Start trusting the signer to execute this action, in the dialog box, the ECL will be updated such that the signer named in the Execution Security Alert will have the right in the future to perform the action named in the dialog box. If you do choose that option, then later wish you had not, you can open the ECL directly (as described above) and reverse your decision.
Depending on how your administrator has configured your workstation, the option Start trusting the signer to execute this action may not be available in the Execution Security Alert on your workstation.