One of the most complicated problems to solve when implementing Domino (or any system that requires a directory to function) is locating the single authoritative source to use for access or identity management. Tivoli Directory Integrator (TDI) is a directory integration engine that provides a system that allows business rules to be applied to synchronize data in any direction. TDI provides different "assembly lines" (integration components that use the TDI API to connect various stores so as to allow TDI to apply those business rules).

For example, if you have Microsoft Active Directory for file and print services, an LDAP store for web authentication, SAP or PeopleSoft for HR, or Lotus Domino, then TDI will allow granular control of user properties across all systems, with TDI serving as the arbiter and synchronizing "master."

This applies to Domino as follows. With e-mail, every message or calendar invitation that is sent requires a directory lookup to find the recipient for delivery. In typical organizations, the e-mail directory and the authoritative directory are not the same. Domino 8 includes a license for TDI to synchronize these directories in a manner that previously has been extremely difficult and expensive.

The following illustration shows a connection from Microsoft Active Directory as the directory partner for Lotus Domino, where directory entries flow bi-directionally between the two systems.

Previous versions of Domino included a tool known as ADSynch to perform a similar function. However, this tool was not as flexible or scalable as TDI. As the name suggests, ADSynch only synchronizes Active Directory and Domino. TDI can connect to nearly any system.

This model provides a single user interface for ID generation and management. If a user is created on either side, IDs and ancillary entries are created on the other. This could be with two systems as illustrated above, or with many systems and entries flowing to all the other systems user-specific attributes as defined by TDI.

When implementing Notes/Domino 8 in a "green field" environment or as a migration, the directory integration piece is a primary component, not just another feature to be added. With the addition of TDI, Notes/Domino 8 lets you bring in many different directories and provide services much more easily than before. However, this does not mean that directory integration should be considered less important just because it's not as difficult. Disparate directories in organizations today are more prevalent than five years ago, so this directory integration functionality has become more logistically complicated, as tools such as TDI have evolved to make the technical aspects simpler. (For a more complete review of the TDI features and functionality, you should refer to the IBM Tivoli Directory Integrator documentation.)

Domino 8 introduces a new tool called DirLint. This tool lets you verify the information that is contained within the directory. It runs against the directory and helps you identify issues, including invalid syntax in names and issues with the naming hierarchy scheme. It also validates that users' names found in groups through directory assistance are consistent.

DirLint is a command-line utility that is loaded by simply typing load dirlint on the server console. It provides an XML document as output. This document can be read using any Internet web browser.

The information that is produced will be stored in \DominodataIBMIBM_TECHNICAL_ SUPPORTlintout_(ServerName)_(Date) as shown in the previous screenshot. An example of the information provided in the XML file is as follows:

In previous releases of Domino, directory assistance provided all directories for both authentication and name resolution when addressing messages. This created a situation where ambiguous names would be displayed while a message was being addressed if there was an "authentication only" directory included in the directory assistance task. In Domino 8, you have the option through directory assistance to specify that the server only references directories contained within the document during the authentication process. This allows you to effectively deploy directory assistance for authentication without affecting end users during the addressing of messages.

Domino 8 offers configuration wizards for LDAP directories. In previous releases, you needed to know a significant amount of information about the LDAP directories that were being connected via directory assistance. You still need to understand basic directory assistance and LDAP concepts, but the new Suggest and Verify buttons on the configuration document help you complete the document, thus ensuring the proper connectivity to the LDAP servers. Some of the wizard buttons run scripts on the Domino server or connect to the LDAP server directly.

As users log into Domino, the AdminP process captures the Notes version used to access the server. The information is stored within the Person documents in the Domino Directory.

The new People | by Client Version view allows you to go to the Domino directory and identify the clients that the users are using to access the server. In previous releases, this was a custom view that needed to be developed and maintained.

Domino 8 now offers an Internet password lockout feature. This feature provides a mechanism (via the inetlockout.nsf database) to track all access attempts to the HTTP environment so that the status of the login attempt is logged. The creation of the Internet lockout database can be done manually, during server startup after the process has been configured, upon the first request to view a document, or when a document needs to be created within the database. The only caveat is that the service must have been running for a period of 10 minutes if the server is not to be rebooted.

The Internet password lockout feature can be enabled for the entire environment through a configuration document, or via a policy that more granularly assigns the ability to lockout users from the HTTP access. The Configuration Settings document does the following:

The lockout feature only applies to HTTP access, and a traditional anti-spoofing mechanism is leveraged within the rich Notes client so that services such as LDAP, POP, IMAP, DIIOP, Lotus QuickPlace, and Lotus Sametime are currently not supported with this feature. If your Domino environment is using a customized DSAPI filter, there is a possibility that the Internet password lockout feature will not function, because customized DSAPI filters can be coded to bypass the standard Domino login facility.

When configuring Internet password lockout via a security policy, the same options are presented as with the configuration document.

It is important to note that enabling this feature could increase the initial call volume to your help desk or the administrative overhead required to manage passwords if the HTTP password feature is used significantly within the organization. Also, malicious attacks can occur on the Domino servers through denial of service attacks. This type of an attack could significantly reduce effectiveness within the environment.

In Domino 8 the encryption level for all new databases will be set for strong encryption. The ability to encrypt databases with an end user's ID to prevent access by other users' IDs is necessary so as to ensure the protection of data once a database is brought to the local workstation. In previous releases, databases had the ability to be encrypted at the simple, medium, or strong level, depending on the needs and requirements of the environment and the end users. Domino will still provide backwards compatibility for the simple and medium encryption models, but going forward, all new replicas will be encrypted as strong.

Domino administrators can assign a new set of public and private keys to a Domino certificate authority. These keys are used to certify the keys of Organization Unit(s) (OUs), servers, and users in that organization. The process of assigning new keys is known as key rollover. Rolling over a CA key may become necessary if the current key is considered too short for adequate encryption, the current key is too old, or if the value of the current private key has been compromised.

When an administrator assigns a new set of keys to a Domino certificate authority, they are created and self-certified and added to the top-level certifier ID file in the pending key area of the ID file. The keys that were previously used are added to the archived keys area of the ID file, and rollover certificates binding the new and old keys are added to the rollover certificate area of the ID file.

In order to support certifier key rollover, the Domino trust model has been extended to include a new type of certificate, rollover certificates. These certificates are issued by an entity to itself. In a hierarchical certificate, there is a single issuer name, a single subject name, and a single subject key. In a rollover certificate, there is a single name (which is both the issuer and the subject) and two subject keys—one key is used to sign the certificate and attests to the fact that the subject name is legitimately in possession of the other key.

Generally, when a key is rolled over, two roll-over certificates are issued—one of them is signed by the old key saying that the new key is valid, and the other is signed by the new key saying that the old key is valid. Each certificate has its own expiration date.

Rollover certificates are essential for limiting the expiration dates of certificates issued to the older keys. One of the reasons for rolling over a key is that a former key has been compromised or considered to be old enough for the danger of compromise to be unacceptable. In such cases, limiting the expiration date of a rollover certificate limits the lifetime of a formerly issued child certificate. This is done by specifying an early enough expiration date in the rollover certificate.

Multi-server session-based authentication, also known as single sign-on (SSO), allows web users to log in once to a Domino or WebSphere server, and then access any other Domino or WebSphere servers in the same DNS domain that are enabled for SSO without having to log in again. The SSO feature makes logging in and using multiple servers in a mixed environment easier for users. Web browsers must have cookies enabled, since the authentication token that is generated by the server is sent to the browser in a cookie.

SSO may be set up by creating a domain-wide configuration document in the directory and enabling the multi-servers option for session-based authentication in a website or a server document.

The Online Certificate Status Protocol (OCSP) enables applications to determine the revocation state of an identified certificate. OCSP checks are made during S/MIME signature verification and mail encryption by the Notes client. OCSP is enabled through a policy, using the Enable OCSP checking setting on the Keys and Certificates tab.

Other new Domino 8 directory/security features include LDAP server improvements for WebSphere Member Manager (WMM) and larger key support.