Lotus Domino 8/8.5 introduced a number of important Domino Directory and security enhancements. These include:
IBM Tivoli Directory Integrator
One of the most complicated problems to solve when implementing Lotus 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 for your mail directory, then TDI will allow granular control of user properties across all systems, with TDI serving as the arbiter and synchronizing "master".
The following diagram shows the TDI structure:
This also applies to Lotus Domino. 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. Lotus Domino 8 included a license for TDI to synchronize these directories in a manner that has previously been extremely difficult and expensive.
The following diagram 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 Lotus 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 Lotus Notes/Domino 8.5.3 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, Lotus Notes/Domino 8.5.3 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.)
DirLint Directory Tool
Domino 8 introduced 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 checks to see if the users' names, that are found in groups through directory assistance, are consistent.
DirLint is a command-line utility that is loaded by simply entering the load dirlint command in the server console. It provides an XML document as output. This document can be read using any Internet web browser. The Lotus Domino Server console screen is shown in the following screenshot:
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 shown in the following screenshot:
Authentication through Directory Assistance
In previous releases of Lotus 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. Starting in Lotus 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. The Configuration Settings document for authentication through Directory Assistance is shown in the following screenshot:
Directory Assistance LDAP Configuration Wizards
Domino 8.5.3 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 Lotus Domino server or connect to the LDAP server directly.
The following screenshot shows the LDAP configuration settings:
People view by Lotus Notes version
As users log in to Lotus Domino, the AdminP captures the Lotus Notes version used to access the server. The information is stored within the Person documents in the Domino Directory as shown in the following screenshot:
The new People | by Client Version view (see the following screenshot) allows you to go to the Domino Directory interface 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:
Internet password lockout
Starting in Lotus Domino 8, an Internet password lockout feature was offered. 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 Lotus Notes client so that services such as LDAP, POP, IMAP, Domino Internet Inter-ORB Protocol (DIIOP), Lotus QuickPlace, and Lotus Sametime are currently not supported with this feature. If your Lotus 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 Lotus Domino login facility. The following screenshot shows the settings for the Internet lockout feature:
When configuring the Internet password lockout feature via a security policy, the same options are presented as with the configuration document, as shown in the following screenshot:
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 Lotus Domino servers through denial of service attacks. This type of attack could significantly reduce effectiveness within the environment.
Enhanced local database encryption
Starting in Lotus Domino 8, the encryption level for all new databases will be set to Strong Encryption, as shown in the following screenshot. The ability to encrypt databases with an end user's ID, to prevent access by other users' IDs, is necessary 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. Lotus Domino will still provide backwards compatibility for the simple and medium encryption models, but from now on, all new replicas will be encrypted as strong:
Certifier Key Rollover
Lotus Domino administrators can assign a new set of public and private keys to a Domino Certificate Authority (CA). These keys are used to certify the keys of Organization Units (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 new types of certificates, called 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.
Single Sign-On (SSO) for LTPAToken2
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 other Domino or WebSphere servers in the same DNS domain that is enabled for SSO without having to log in again. LTPAToken2 is incompatible with Domino 7 and prior releases, but provides SSO security improvements. The new SSO feature makes logging in and using multiple servers in a mixed environment easier for users. Web browsers must have cookies enabled, as 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.
Certificate revocation checking through the Online Certificate Status Protocol
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 Lotus Notes client. OCSP is enabled through a policy, using the Enable OCSP checking setting in the Keys and Certificates tab, as shown in the following screenshot:
Other Lotus Domino 8/8.5 directory/security features include LDAP server improvements for WebSphere Member Manager (WMM) and larger key support.
IBM Lotus Notes Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM Informix Interview Questions|
|IBM DB2 Interview Questions||DB2 Using SQL Interview Questions|
|IBM Mainframe Interview Questions||Active Directory Interview Questions|
|DB2 SQL Programming Interview Questions||IBM Integration Bus Interview Questions|
|IBM DataPower Interview Questions||Microsoft Exchange Server 2013 Interview Questions|
|Mainframe DB2 Interview Questions||Windows Server Support Interview Questions|
Ibm Lotus Notes Tutorial
Lotus Notes 8.5.3 And Soa
Overview Of New Lotus Notes 8.5.3 Client Features
Lotus Domino 8.5.3 Server Features
Deployment Enhancements In Notes/domino 8.5.3
Domino 8.5.3 Enhancements
Upgrading To Lotus Notes And Domino 8.5.3
Coexistence Between Notes/domino Releases
New Features In Notes/domino 8.5.3 Development
Integration With Other Lotus/ibm Products
Domino Configuration Tuner
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.