 |
Security variables
Updated: 09/04/2001
Related link:
More Professor INI |  |
Security is on everyone's mind these days, including Professor INI's. And what better time to explore NOTES.INI security variables than this month, in the special security issue of Iris Today.
An update on ECLSetup
In the April, 2001, issue of Iris Today, Professor INI published two questions about the use of ECLSetup. ECLSetup was introduced in 5.0.3 to address the issue of deploying updated Admin ECL settings to client ECL workstations.
Administrators can set this variable to retrieve the Admin ECL settings automatically when the client first starts up. Moreover, depending on the setting, the Admin ECL settings could either completely overwrite the client ECL or be merged with the settings in the client ECL. For more information, see Ask Professor INI in the April, 2001, issue of Iris Today.
Note that ECLSetup will not be supported beyond the R5 code stream, as administrators will have other means of deploying and updating Admin ECLs to their Notes users in Rnext.
Q. Are there NOTES.INI variables that control S/MIME mail encryption?
NOTES.INI offers two variables for S/MIME mail encryption, SMIME_Strong_Algorithm and SMIME_Weak_Algorithm. These variables change the default algorithm used for encrypting MIME messages.
When a Notes client uses S/MIME to encrypt a message, Notes chooses a data encryption algorithm that depends on the length of the public key in the recipient's certificate. If the recipient's public key length is greater than 512 bits, the default algorithm is 3DES (if the sending Notes client is using North American Notes). If the public key length is 512 bits or less, the default algorithm is 40 bit RC2.
Some international Notes users may have public keys longer than 512 bits but will not be able to decrypt S/MIME messages that use 3DES data encryption. (Prior to 5.0.4, Unites States government export restrictions required different encryption strengths on exported copies of software.) Therefore, they will not be able to decrypt a message from a North American Notes client. In such an instance, you can use the NOTES.INI variable SMIME_Strong_Algorithm to specify an algorithm available to the international Notes recipient, for example:
SMIME_Strong_Algorithm=DES
SMIME_Strong_Algorithm=RC2_56
SMIME_Strong_Algorithm=RC2_40
SMIME_Weak_Algorithm specifies the encryption method for encrypting MIME messages to recipients whose public keys are shorter than 512 bits, for example:
SMIME_Weak_Algorithm=RC2_40
SMIME_Weak_Algorithm=RC2_56
SMIME_Weak_Algorithm=RC2_64
For more information on SMIME_Strong_Algorithm and SMIME_Weak_Algorithm, consult the Domino R5 Administration Help.
Q. Can NOTES.INI help my Web security?
There are four variables you can use to help control Web user access to your site:
- WebNameAuthentic
- NABWebLookupView
- NoAmbiguousWebNames
- NoMABForWebNames
WebNameAuthentic
WebNameAuthentic=1 instructs HTTP authentication to use the Domino Release 4.5 method of HTTP authentication (that is, the "you are who you log in as" method). For example, if a user enters "jsmith" and their correct password in the Name and Password dialog box, Domino searches through the $Users view of the Domino Directory. If it finds a match and the password matches, then the user is authenticated as "jsmith." This user would need to be entered as "jsmith" in any Group document and in database ACLs in order to gain the correct access to each database.
NABWebLookupView
NABWebLookupView=viewname directs the server to search the Domino Directory for the name the user entered into the Name and Password dialog box, using the specified view. This user-created view is used instead of the $Users view and allows administrators to design a new view in the Domino Directory that is similar to the $Users view. For example, an administrator may design a formula for the first column of their view (Name), that may not include first names, last names, short names, and so on. Users would then be forced to enter their full names to log in.
NoAmbiguousWebNames
NoAmbiguousWebNames=1 forces Domino to match Web user names to only one Person document in the Domino Directory. Setting this flag results in an authentication failure (that is, "Error 401 Authentication Exception") any time more than one Person document matches a Web user name. Users will have to log in with a unique user name to authenticate.
For example, if a user enters "jdoe" in the Name and Password dialog box, Domino searches the $User view of the Directory for any matches. As an example, assume that it finds two matches (John Doe/Lotus and John Doe/Acme). In this case, the user would receive an "Error 401 Authentication Exception" because the name entered (jdoe) is ambiguous. At this point the user would need to enter their full hierarchical name (John Doe/Acme) in the Name and Password dialog box so that they could be authenticated correctly.
Please note that if your site is using NoAmbiguousWebNames=1 and has users with the same name (either in the same Domino Directory or in different directories, if Directory Assistance is being used), this could cause problems with authentication. For example, if you have two "John Smiths" in two different directories, and if either one enters "John Smith" in the Name and Password dialog box, neither will be authenticated because this name is ambiguous. The administrator would need to edit the Person document and change the user name fields so that each has a different middle initial (for example, John M. Smith and John S. Smith). Alternately, the administrator could change the short name field so that each is unique (for example, jmsmith and jssmith). The users can then use this "unique" name when prompted to authenticate via the Name and Password dialog box.
NoMABForWebNames
NoMABForWebNames=1 allows the use of cascaded Address Books, instead of the Master Address Book (MAB), for Domino 4.6.2a and later. This variable tells Domino to use the information on the NAMES line in the NOTES.INI file instead of the Master Address Book, to determine the Address Books to use for basic Web authentication. The Master Address Book must still be used for X.509 client certificate authentication. In R5, Web clients cannot authenticate from cascaded Public Address Books or Domino Directories. To authenticate Web clients using secondary address books or directories in R5, Directory Assistance is the only supported method.
DIIOP_IOR_HOST
While we're on the subject of Web security, note that the NOTES.INI variable DIIOP_IOR_HOST lets you configure DIIOP servers for firewall support. When there is a firewall between your Domino server and your Java applets/applications that need to use the CORBA-enabled lotus.domino classes, you will need to set DIIOP_IOR_HOST to the Public IP address or hostname of the Domino server (as it is known outside the firewall). The Java applets/applications will thereafter be able to go through an appropriately configured firewall to allow the IIOP ports a connection to the hidden Domino server.
Q. What about SSL?
Domino 5.0 and later supports Secure Sockets Layer (SSL) for secure communication using POP3, IMAP, LDAP, and NNTP. To enable SSL, you need to first find out what version of SSL your server supports. Domino supports SSL versions 2.0 and 3.0. It can also negotiate the best SSL version to use with a particular server. Note that in R5, SSL ciphers can be specified in the Server document for HTTP, which is the preferred/supported method. For more information, see Domino R5 Administration Help.
The NOTES.INI variable SSLCipherSpec lets you select an SSL cipher specification in order to limit the ciphers used by SSL. This enables Domino sites to force users to make requests with a domestic browser version, for instance, and therefore use 128-bit ciphers. Cipher specifications are two digit numbers taken from the following list of possible ciphers. Specifying a domestic-only cipher for an export server has no effect. You specify multiple ciphers by stringing them together back-to-back, including leading zeros, for example, 010203.
01 SSL_RSA_WITH_NULL_MD5
02 SSL_RSA_WITH_NULL_SHA
03 SSL_RSA_EXPORT_WITH_RC4_40_MD5
04 SSL_RSA_WITH_RC4_128_MD5
05 SSL_RSA_WITH_RC4_128_SHA
06 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
09 SSL_RSA_WITH_DES_CBC_SHA
0A SSL_RSA_WITH_3DES_EDE_CBC_SHA
You can use SSLCipherSpec to specify an SSL cipher specification for LDAP, IMAP, POP3, NNTP, and HTTP services. However, you can only select multiple ciphers for HTTP. For all other services, you can specify only one cipher.
To log what occurs during the SSL handshake process, you can use the following two NOTES.INI variables:
TraceSSLHandshake=1
ReportSSLHandshakeErrors=1
TraceSSLHandshake=1 sends output to the console or to a text file if you use Debug_Outfile. It logs the session between the browser and the server, traces information about the SSL handshake, and reports errors when and if they occur. When you set ReportSSLHandshakeErrors=1, any error that occurs in the handshake between the browser and the server is output to the console and the log.
TraceSSLHandshake and ReportSSLHandshakeErrors can be set independently of each other. However, we recommend you use them together, to get the reported errors along with the transaction between the browser and server.
Do you have a NOTES.INI question? Send it in to Professor INI. We'll answer as many questions as we can in future "Ask Professor INI" columns. Keep in mind, however, that we may not be able to answer every question, nor can we quickly respond to requests that require immediate attention. If you need an immediate response to a question, we recommend you post it in the Iris Cafe Notes/Domino Gold Release Forum where someone from the general Notes community might be able to help, or contact Lotus Customer Support. |