Directory Server, Version 6.1

 

The IBM Tivoli Directory Server

The IBM® Tivoli® Directory implements the Internet Engineering Task Force (IETF) LDAP V3 specifications. It also includes enhancements added by IBM in functional and performance areas. This version uses IBM DB2® as the backing store to provide per LDAP operation transaction integrity, high performance operations, and on-line backup and restore capability. The IBM Tivoli Directory Server interoperates with the IETF LDAP V3 based clients. Major features include:

  • A dynamically extensible directory schema - This means that administrators can define new attributes and object classes to enhance the directory schema. Changes can be made to the directory schema, too, which are subject to consistency checks. Users may dynamically modify the schema content without restarting the directory server. Because the schema itself is part of the directory, schema update operations are done through standard LDAP APIs. The major functions provided by the LDAPv3 dynamic extensible schema are:

    • Queriable schema information through LDAP APIs

    • Dynamic schema changes through LDAP APIs

    • Server Root DSE

  • NLS support – An IBM Tivoli Directory Server supports the UTF-8 (Universal Character Set Transformation Format) character set. This Unicode (or UCS) Transformation Format is an 8-bit encoding form that is designed for ease of use with existing ASCII-based systems. The IBM Tivoli Directory Server also supports data in multiple languages, and allows users to store, retrieve and manage information in a native language code page.

  • Replication – Replication is supported, which makes additional copies of the directory available, improving performance and reliability of the directory service. Replication topologies also support forwarding and gateway servers.

  • Security features – IBM Tivoli Directory Server provides a rich set of security features.

    Identification and authentication

    Identification and authentication are used to determine the identity of the LDAP clients; that is, verifying that users are who they say they are. A user name and password is a basic authentication scheme. This user identity is used for determining access rights and for user accountability.

    Simple Authentication and Security Layer (SASL)

    This support provides for additional authentication mechanisms. For more information, see Using Web Administration: and Configuring the DIGEST-MD5 mechanism.

    The Secure Sockets Layer (SSL) and Transaction Layer Security (TLS)

    This support provides encryption of data and authentication using X.509v3 public-key certificates. A server may be configured to run with or without SSL or TLS support or both. For more information, see Secure Sockets Layer and Transaction Layer Security.

    Access control

    After users are authenticated, it must be determined whether they have authorization or permission to perform the requested operation on the specific object. Authorization is often based on access control lists (ACLs). An ACL is a list of authorizations that can be attached to objects and attributes in the directory. An ACL lists what type of access each user or a group of users is allowed or denied. To make ACLs shorter and more manageable, users with the same access rights are often put into groups or the ACLs are filtered. The directory administrator can manage access control by specifying the access rights to objects for individual users or groups. Users can perform operations under alternate access rights by using proxied authorization. For proxied authorization, the user assumes the proxied identity and the ACL restrictions for the proxied identity. For more information, see Access control lists.

    Auditing

    The IBM Tivoli Directory Server can perform auditing of security-relevant events, such as user authentication and modification to the directory tree. The audit function provides a means for accountability by generating audit records containing the time, user identity, and additional information about the operation. The directory administrator manages the behavior of the audit function, such as selection of auditable events, as well as audit review and clearing of audit files. For more information , see Enabling the audit log and modifying audit log settings.

    Security roles

    IBM Tivoli Directory Server supports five different security roles.

    Primary directory administrator

    The Primary directory administrator is associated with a specific user account. There is only one Primary directory administrator account for the LDAP server. The Primary directory administrator has full rights to manage the LDAP server. The Primary directory administrator is created during product installation and configuration. The Primary directory administrator consists of a user ID and a password and predefined authorization to manipulate the entire directory. The Primary directory administrator creates the end user security role. This is an LDAP entry with a specific distinguished name (DN), user password, and other attributes that represent the particular end user. The Primary directory administrator also defines the level of authorization the end user will have over entries.

    Administrative group members

    Administrative group members are users that have been assigned a subset of administrative privileges. The administrative group is a way for the directory administrator to delegate a limited set of administrative tasks to one or more individual user accounts. Server administrative group members are explicitly assigned various roles that define the tasks that a group member is authorized to perform. These administrative roles include such specialized roles as Password Administrator and Server Start/Stop Administrator. For more information, see Creating the administrative group.

    Global administrative group members

    The global administrative group is a way for the directory administrator to delegate administrative rights in a distributed environment to the database backend. Global administrative group members are users that have been assigned the same set of privileges as the administrative group with regard to accessing entries in the database backend. Global administrative group members have complete access to the directory server backend. Global administrative group members do not have access to the audit log and thus the audit log can be used by local administrators to monitor global administrative group member activity.

    The global administrative group members have no privileges or access rights to any data or operations that are related to the configuration settings of the directory server. This is commonly called the configuration backend. All global administrative group members have the same set of privileges.

    LDAP user

    LDAP users are users whose privileges are determined by ACLs. Each LDAP user is identified with an LDAP entry containing the authentication and authorization information for that end user. The authentication and authorization information might also allow the end user to query and update other entries. Depending on the type of authentication mechanism used, after the end user ID and password are validated, the end user can access any of the attributes of any entry to which that end user has permissions.

    Master server DN

    The master server DN is a role used by replication that can update the entries under a replica's or a forwarding replica's replication context to which the DN is defined as a master server DN. The master server DN can create a replication context entry on a replica or forwarding replica if the DN is defined as the master server DN to that specific replication context or as a general master server DN.

    By sending a AES bind control, a master server DN can send AES encrypted data to a replica.

    The following are some important points about the master server DN:

    • There can be several master server DNs defined in a server's configuration file. There is an ibm-slapdReplication object that can contain a default or general ibm-slapdMasterDN, and there can be multiple ibm-slapdSupplier objects, each defining an ibm-slapdMasterDN for a specific replication context (that is, limited to a specific subtree). The administration password policy applies to them all.

    • Any of those master server DNs can bind to the directory.

    • Any of those master server DNs have access to update the ibm-slapdSuffix attribute of the entry
      cn=Directory, cn=RDBM Backends, cn=IBM Directory, 
      	cn=schemas, cn=Configuration
      in a server's configuration file. A master server DN does not have read or write access to any other entries in the configuration file.

    • No master server DN has access to any other part of the configuration file.

    • Only the general master server DN or the master server DN for the cn=IBMpolicies context can make updates to the schema.

    • The master server DN for a specific context has full read and write access to all entries within that context.

    • The general master server DN has full read and write access to all entries within all contexts.

    Password policy

    The password policy feature provided by the IBM Tivoli Directory Server allows the administrator to define the policy used for administrator and user passwords. The administrator places restrictions on passwords by specifying rules for syntax, validation, and lockout in the password policy. The administrator password policy configuration is stored in the configuration backend and can be modified only by the root administrator. The user password policy configuration is stored within the LDAP tree and can be modified by the root administrator or a member of the administrative group. The attribute values can be changed only when binding as administrator to the IBM Tivoli Directory Server. TDS provides three types of password policies: individual, group, and global password policies. For more information, see Setting password policy.

    Password encryption

    IBM Directory enables you to prevent unauthorized access to user passwords.

    The administrator can configure the server to encrypt userPassword attribute values in either a one-way encrypting format or a two-way encrypting format.

    One-way encrypting formats:

    • crypt

    • MD5

    • SHA-1

    • Salted SHA-1

    After the server is configured, any new passwords (for new users) or modified passwords (for existing users) are encrypted before they are stored in the directory database.

    For applications that require retrieval of clear passwords, such as middle-tier authentication agents, the directory administrator needs to configure the server to perform either a two-way encrypting or no encryption on user passwords.

    Two-way encrypting format:

    • AES

    When you configure the server using Web Administration, we can select one of the following encryption options:

    None

    No encryption. Passwords are stored in the clear text format.

    crypt

    Passwords are encrypted by the UNIX® crypt encrypting algorithm before they are stored in the directory.

    MD5

    Passwords are encrypted by the MD5 Message Digest algorithm before they are stored in the directory.

    SHA-1

    Passwords are encrypted by the SHA-1 encrypting algorithm before they are stored in the directory.

    Salted SHA-1

    Passwords are encrypted by the Salted SHA-1 encrypting algorithm before they are stored in the directory.

    AES128

    Passwords are encrypted by the AES128 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

    AES192

    Passwords are encrypted by the AES192 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

    AES256

    Passwords are encrypted by the AES256 algorithm before they are stored in the directory and are retrieved as part of an entry in the original clear format.

    The default option is AES256. A change is registered in a password encryption directive of the server configuration file:

    ibm-SlapdPwEncryption: AES256

    The server configuration file is located in:

    <instance_directory>\etc\ibmslapd.conf 
    Notes:

    1. If the UNIX crypt method is used, only the first 8 characters are effective.

    2. A one-way encrypted password can be used for password matching but it cannot be decrypted. During user login, the login password is encrypted and compared with the stored version for matching verification.

  • Change log – Records changes made to the LDAP data and are logged in a separate database in the LDAP server to support meta-directories or client queries to monitor directory updates.

  • Dynamic configuration – Changes using LDAP APIs provides the capability to bind to a directory and issue a single extended operation along with any data that makes up the extended operation value. It supports the standard host, port, SSL, and authentication options used by all of the LDAP client utilities. In addition, a set of options is defined to specify the operation to be performed and the arguments for each extended operation.

  • Web Administration Tool – A Graphical User Interface (GUI) that can be used to administer and configure the IBM Directory. The administration and configuration functions enable the administrator to:

    • Perform the initial setup of the directory

    • Change configuration parameters and options

    • Manage the daily operations of the directory, such as adding or editing objects, for example, object classes, attributes, and entries.

  • Proxy server – A directory proxy server sits at the front-end of a distributed directory and provides efficient routing of user requests thereby improving performance in certain situations, and providing a unified directory view to the client. It can also be used at the front-end of a server cluster for providing fail over and load balancing.

  • Administration daemon (idsdiradm) – Enables remote management of an instance of the IBM Tivoli Directory Server. It must be installed on the machine where the IBM Tivoli Directory Server is installed and must be running continuously.

  • Configuration only mode – Gives an administrator remote access to the server even when errors are encountered during startup. The server does not depend on the successful initialization of the database back end. An administrator can use an LDAP protocol to query and update the configuration for the server.

  • Attribute uniqueness controls – Can be configured to ensure that specified attributes always have unique values within a directory on a single directory server.

  • Language tags – Enables the directory to associate natural language codes with values held in a directory and enables clients to query the directory for values that meet certain natural language requirements.

  • Sorting on searches – Sorts the entries found by the search using the first 240 bytes of the specified attribute values.

  • Paged results – Provides paging capabilities for LDAP clients that want to receive just a subset of search results (a page) instead of the entire list.

  • Transactions – Enable an application to group a set of entry updates together in one transaction.

  • Multiple instances – Enables a user to have more than one directory instance on a server.

  • Referrals – Support for LDAP referrals, allowing directories to be distributed across multiple LDAP servers where each single server may contain only a subset of the whole directory data.

  • Attribute encryption- Enables local administrative group members who are assigned DirDataAdmin and SchemaAdmin roles to specify attributes that are to be encrypted in the directory database using a subset of the encryption schemes supported for password information. For more information, see Encrypted Attributes

  • Pass-through authentication- A mechanism using which if a client attempts to bind to a directory server and if the user credential is not available locally, then the server attempts to verify the credential from another external directory server or a pass-through server on behalf of the client. For more information, see Pass-through authentication.

  • SNMP for server management- The SNMP agent can be used with the IBM Tivoli Directory Integrator (TDI) assembly line to monitor and report the performance and wellness information of the directory server.

  • Active directory synchronization- A tool for synchronizing users and groups between an existing Microsoft® Active Directory and an IBM Tivoli Directory Server 6.1 directory.




[ Top of Page | Previous Page | Next Page | Contents | Index ]