|
|
||||
|
|||||
|
|||||
|
|
|||||
|
|
|
|
||||||||||||||||
|
||||||||||||||||||
 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |  Securing the Domino Environment Back to Main Menu Introduction This Learner-Directed Offering provides additional information about specific security topics covered in the Implementing a Domino Infrastructure R5 and Maintaining a Domino Server Infrastructure R5 courses, with the exception of HTTP and Secured Socket Layer (SSL). Most of the information contained in this Learner-Directed Offering assumes knowledge of the security-related topics covered in the aforementioned System Administration (Release 5.0) courses; however, this Learner-Directed Offering provides a review of key security concepts. Securing databases, documents and fields is the job of the application developer and is therefore beyond the scope of this Learner-Directed Offering. For additional information, refer to the Learner-Directed Offering entitled Securing Your Application. The Deploying Domino Applications course covers securing databases as it applies to application deployment. The Application Development curriculum also covers these topics in detail. Network and Domino Firewalls Protecting a Domino Server Network: Use network firewalls to protect the network from direct access from other networks and dial-in access via modems. The following diagram shows the process the user must go through to gain access to data.
Network and Domino Firewalls For example: In addition, physically isolate the server from other servers. If this "external" or "public" server is in the same domain as the other company Domino servers, protect the Domino Directory by replicating only the necessary documents to the external server's Domino Directory. For example, replicate only Server documents, select groups, and one Connection document. Note: If the server is in a different domain, this is not an issue since the Domino Directory is unique by definition. Back to Table of Contents
Certificates: The Basis for Domino Security Notes ID Component Review Note: The password is used to protect and encrypt the ID file. The other components are used to identify the owner of the ID in order to determine access to resources. Back to Table of Contents
Accessing a Server through Successful Authentication Authentication is the verification process Domino uses to ascertain a user's or server's identity. It is based on certificates. Authentication is successful if users and/or servers share a common certificate. If users or servers each share an authority (the certifier), they trust each other's identity. Authentication is successful if any of the following are true: Note: This Learner-Directed Offering does not address flat certificates. For more information on flat certificates, refer to Flat names in the Domino 5 Administration Help database. Public and private keys are used as follows: Private key: Available to one owner (person, server, or certifier). Contained in the owner's ID file. Either key can be used to encrypt data, and the other key is used to decrypt the data. The authentication process Authentication is the process whereby the server and the entity requesting access (the requestor) establish trust — verify each other's identity. The authentication process is illustrated in the following diagram and described below:
2. The requestor creates a message using the random number from the server, signs it using the requestor's private key, and sends the signed message back to the server. 3. The server verifies that the signature is correct by using the certificates to validate the requestor's public key which is used to decrypt the signed message. The server can then verify that the random number contained in the signed message matches the original random number. 4. This sequence is then repeated in the opposite direction so that the requester can verify that the server is authentic. Authentication Scenarios Scenario 1
Scenario 2
Answer to Scenario 1: Hierarchical IDs have a common ancestor.
Answer to Scenario 2: Hierarchical IDs without a common ancestor have a cross certificate available.
Fortifying Server Security using Server Restrictions
The following diagram shows the logic in determining user/server access to a server.
If a server is configured to allow anonymous access and an entity is listed in the Access Server field, the entity (server or user) is allowed to access the server as the named user or server. Since that entity's identity is known to the server, it is attributed with any additional access or restrictions based on the server or user name. Procedure: Bypassing Authentication by Allowing Anonymous access
Administrators can allow Anonymous access to a server, and still maintain server access control as follows: Note: Remember that the scope of this discussion is protecting the server. Once the server is secure, it is the database manager's responsibility to set each database ACL appropriately to control access to databases. Back to Table of Contents
Enhancing Server Security by comparing public keys Comparing public keys enhances the security inherent in the authentication process. For example: If a user loses an ID, the administrator can restore an archived ID and generate a new public key for the ID while retaining the same name and private key. If unauthorized users attempt to use the original ID, they will not be able to access the server because the new public key for the ID will no longer match the public key on the original user ID. Users who are not listed in the Domino Directory will not be able to access the server. This secures the server against users from another organization and users who have left the company. Note: There is no performance penalty when comparing public keys. Authentication does not take any longer when performing the comparison. Cascading Address Books: Include public keys in the primary Domino Directory. The server will not look in any additional Domino Directories specified in the NOTES.INI file. Procedure: Configuring the server to compare public keys Follow these steps to enable public key comparison.
Back to Table of Contents Protecting the server with Password Checking Note: If password checking is enabled, users are not required to enter their password more often than they must if password checking is not enabled. Procedure: Enabling Password Checking If the Administration process is not set up, you cannot set up password options for multiple users simultaneously. Instead, you must either manually edit the Person documents, or design an agent to modify the Person documents. For details about how the Administration Process enables password checking, see Verifying user passwords during authentication in the Domino 5 Administration Help database. Follow these steps to enable password checking.
The Process of checking passwords After the administrator enables password checking for users and the server, the following occurs: 1. The first time the user authenticates with the server, the client uses the user's private key and password to generate a public/private key pair and stores the new key pair in the user's ID file. 2. The server also stores a digest of the new public key in the Password digest field in the user's Person document. 3. Each time the user authenticates with this server, the server sends the value stored in the Password Digest field from that user's Person document to the client. 4. The client then sends back to the server the corresponding public key and a signature signed by the corresponding private key. 5. The server then verifies that the public key provided matches the digest of the corresponding public key in the user's Person document and that the signature is valid. Caution: If an ID is stolen and the thief knows and changes the password, when the thief authenticates with the server, the fraudulent information is stored in the password digest field in the user's Person document. The valid user will not be able to authenticate with the server. To address this issue, the administrator must delete the fraudulent value in the Password digest field to lockout the thief, then have the valid user authenticate with the server to store the correct information in the Person document. Back to Table of Contents Server Security Scenarios Scenario 1: Preventing access from people using stolen IDs Answer: Administrators should take the following action: Answer: Create a group, such as DenyAcess, and include this group in the Not access server field in the Server document for each server in your domain. Answer: Set the Allow anonymous Notes connections field to Yes on the Security tab in the Server document. Protecting a Notes Workstation When users enter a password, Notes decrypts the user's private key using the typed password as a key. If a user enters the wrong password, the checksum fails, and the decrypted result is random junk. When users change passwords, they must first provide the old password which is used to decrypt the encrypted information contained in the ID. The new password is then used to re-encrypt the ID file.
Automatic Password Protections
Procedure: Enabling Multiple Passwords
Note: Any password assigned to an ID before authorized passwords are assigned, are no longer valid. For more on how to set up multiple passwords, see Password-protection for Notes and Domino IDs in the Domino 5 Administration Help database. Back to Table of Contents
Execution Control Lists (ECLs) Every design element in a database is signed using a Notes ID. Notes looks at the signature to determine whether the ECL allows a specific action, such as access to a database or the file system. For example, ECLs can warn users against executing programs from users outside the organization that might sabotage their work. If there is no signature associated with the action (for example, a user sends a mail message containing an action button, but does not sign the message), Notes uses the default ECL access. Each workstation includes a default ECL. Administrators can choose whether or not users can update their own ECL. If administrators allow users to manage their workstation ECL, users can access the settings in File >Tools > User Preferences; Basics panel; Security Options button.
Follow these steps to edit the Administration ECL in the Domino Directory.
Note: The Administration ECL is used as the default ECL for all new workstations that are set up. To update the ECLs on existing workstations, send an e-mail message to users, and include a button to click that will update the workstation ECL. For more information on updating existing workstation ECLs, see Sending a memo to users to update their ECLs in the Domino 5 Administration Help database. This topic is covered in more detail in the Deploying Domino Applications course. ECL Considerations Even if the ECL restrictions are stringent and the user is not allowed to modify the workstation ECL, the ECL does not prevent users from executing programs if they choose. However, users do receive the following warning: Back to Table of Contents
Workstation Security Scenarios Scenario 1: Protecting shared workstations Some workstations in your company are shared by more than one Notes user. Which tools would be appropriate to use to protect a shared workstation? Answer: Users at a shared workstation should always do the following: Scenario 2: Rolling out custom applications Your company has a group of application developers that design the company's applications. Which tools would be appropriate to ensure that all employees grant the appropriate access to use the company's applications? Answer: Add the application developers' names to the Administration ECL, granting them all access. Then, send a memo to users to refresh the workstation ECL. Scenario 3: Protecting IDs On which of the following IDs would it be appropriate to require multiple passwords? Answer: Organization and organizational unit certifier IDs. It is typically unnecessary to require multiple passwords for server and user IDs. Server Access Scenarios From a security perspective, what should the administrator consider and do to connect the servers in these two domains for mail routing? Scenario 2: Connecting Servers in Two Domains for Database Access A consultant, Charlie Doucette/Saturn/Planet, needs to communicate with servers in the World Domain. World has many servers, all of which are identified in their own organizational unit, /SVR/World. The relationship between the companies, Planet and World, is such that Charlie should be allowed to assist in the development of any database. How should security be set up? Are there any database security issues you can spot? Scenario Solutions Answer to Scenario 1: Connecting Two Domains for Mail Routing To connect servers in the World and Earth Domains for mail routing only, the administrators at each site should complete the following tasks. 1. Since there is no evidence that their hierarchical names have any ancestors in common, servers in the World and Earth domains should cross-certify. Cross certify World and Earth at the Server ID level, as follows:
The administrator should consider future communications, such as whether or not another server in the World Domain will need to communicate with another server in the Earth Domain, and what the certification model for that domain is. The best practice is to issue a cross-certificate on the Server ID level to provide the highest protection in the organization. 2. Modify the Server Access lists in each server's Server document to ensure that the servers will be granted access to each other. 3. Create a Connection document in each domain's Domino Directory:
4. Ensure the default Access Control List (ACL) on MAIL.BOX is Depositor. This allows the router for both servers to place mail in the file. 5. Add each server's name to the group designated for other domains, such as OtherDomainServers. Answer to Scenario 2: Connecting Two Domains for Database Access Security between the World and Planet domains would best be configured as follows: 1. The most secure option is to cross-certify Charlie and the OU for World's servers. This allows Charlie to work from his own workstation; however, his ID would be the only one allowed to communicate with World's servers. Others certified by /Saturn/Planet would not be able to authenticate. Cross-certify as follows:
Note: If replication between servers is necessary, Charlie's server would have to be cross certified with the OU for World's servers. 2. Update the Server Access lists for World's servers to allow Charlie (and the server) access to:
Note: Make sure that the Only allow server access to users in this Directory is set to No on the servers that Charlie needs to access. Otherwise, create a Person document for Charlie Doucette. 3. Update the ACLs for the databases on which Charlie will work to allow Charlie to make changes. The database administrator may decide to provide such access by means of a group. Back to Table of Contents | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|||||
|
