What are the capabilities of the z/OS LDAP server?

You can use the z/OS® LDAP server to provide a directory service of your own. Your directory can contain just about anything you want to put in it. Some of the z/OS LDAP server’s more interesting features and capabilities include:

  • Multiple concurrent database instances (referred to as backends): The LDAP server can be configured to serve multiple databases at the same time. This means that a single z/OS LDAP server can respond to requests for many logically different portions of the LDAP tree. A z/OS LDAP server can be configured to provide access to RACF® and store application-specific information.
  • Robust general-purpose databases The LDAP server comes with TDBM and LDBM backends. There are no restrictions on the types of information that these backends can contain. The TDBM backend is based on Db2® and is a highly scalable database implementation. The LDBM backend keeps its entries in memory for quick access and requires a minimum amount of setup. When the LDAP server is not running, LDBM stores its directory information in z/OS UNIX System Services files.
    Note: Db2 is required to use TDBM, but is not required for LDBM.
  • Access to RACF data: The LDAP server can be configured to provide read/write access to RACF user, group, connection, and general resource profiles using the LDAP protocol. The LDAP server can also be used to manage RACF options that affect classes. (RACF is a component of the Security Server for z/OS.) If the RACF data is shared across the sysplex, then users, groups, connections, and resource profiles in the sysplex can be managed using LDAP. The LDAP server’s access to RACF is managed by an additional configurable backend called SDBM. See Accessing RACF information for more information.
    Note: To use SDBM for ONLY authentication (LDAP bind processing), any security manager implementing the SAF service required by the RACROUTE REQUEST=VERIFY,ENVIR=CREATE macro can be used. A password or a password phrase can be used for authentication. To use SDBM for accessing and updating user, group, connection, and resource profile information, and to set class options, RACF is required.
  • Configuration backend: The LDAP server can be configured with a CDBM backend. The CDBM backend is used to store configuration information. See Setting up for CDBM for more information.
  • Loading and unloading data: The LDAP server can load many entries into a TDBM directory using the ldif2ds utility. See ldif2ds utility for more information. The LDAP server can also unload many entries from a TDBM, LDBM, or CDBM directory using the ds2ldif utility. See ds2ldif utility for more information.
  • Access control: The LDAP server provides a rich and powerful access control facility, allowing you to control access to the information in your database or databases. You can control access to entries based on LDAP authentication information, including users and groups. Group membership can be either static, dynamic, or nested. Access control is configurable down to individual attributes within entries. Also, access controls can be set up to explicitly deny access to information. See Using access control about access control and Static, dynamic, and nested groups for more information about groups.
  • Threads: The LDAP server is threaded for optimal performance. A single multi-threaded z/OS LDAP server process handles all incoming requests, reducing the amount of system overhead required.
  • Multiple concurrent servers: The LDAP server can be configured to permit multiple LDAP servers to serve the TDBM, LDBM, CDBM, or GDBM directory at the same time. The multiple servers might run on the same z/OS image, and they might run on multiple z/OS images in a Parallel Sysplex. This improves availability and might offer improved performance in certain configurations. See Configuring the operational mode for more information.
  • Basic replication: The LDAP server can be configured to maintain replica copies of its database. Master/consumer replication is vital in high-volume environments where a single LDAP server just does not provide the necessary availability or reliability. Peer to peer replication is also supported. See Basic replication for more information. This feature is contrasted with multiple concurrent servers.
  • Advanced replication: The LDAP server can be configured to act as a supplier, consumer, cascading, or gateway server in an advanced replication environment. An advanced replication environment allows for only certain subtrees or entries in a TDBM, LDBM, or CDBM backend to be replicated to other servers. See Advanced replication for more information.
  • Referrals: The LDAP server is able to refer clients to additional directory servers. Using referrals you can distribute processing overhead, distribute administration of data along organizational boundaries, and provide potential for widespread interconnection beyond an organization’s own boundaries. See Referrals for more information.
  • Aliases: An alias entry can be created in the directory to point to another entry in the directory. During search operations, an alias entry can provide a convenient public name for an entry or subtree, hiding the more complex actual name of the entry or subtree. It can also avoid the need to duplicate an entry in multiple subtrees. See Alias for more information.
  • Change Logging: The LDAP server can be configured to create change log entries in the GDBM backend. Each change log entry contains information about a change to an entry in a TDBM, CDBM, or LDBM backend, to the LDAP server schema, or to a RACF user, group, connection, or resource profile. The GDBM backend can be configured to store its entries in Db2 (similar to TDBM) or in z/OS UNIX System Services files (similar to LDBM). See Change logging for more information.
  • Configuration: The LDAP server configuration process can be simplified by using the dsconfig configuration utility. This utility requires minimal user interaction and allows novice LDAP users to quickly configure an LDAP server. See Configuring an LDAP server using the dsconfig utility for more information.

    If you do not use the dsconfig utility, the LDAP server is highly configurable through a single configuration file that allows you to change just about everything you would ever want to change. Configuration options have reasonable defaults, making your job much easier. See Creating the ds.conf file for more information.

  • Secure communications: The LDAP server can be configured to encrypt data to and from LDAP clients using the z/OS Cryptographic Services System SSL. The LDAP server supports the Start TLS extended operation to switch a non-secure connection to a secure connection. It has various ciphers for encryption to choose from, all that provide server and optionally client authentication by using X.509 certificates. See Setting up for SSL/TLS for more information.
  • Dynamic workload management: The LDAP server can be configured to participate in dynamic workload management in a Parallel Sysplex by using TCP/IP connection optimization. With multiple concurrent server instances configured in this way, availability is improved, including resource usage. In addition, performance improvements might be experienced as sysplex resource usage is more evenly balanced across z/OS systems in the sysplex. See Configuring the operational mode for more information.
  • Retrieve Policy Director data: This capability is deprecated. The z/OS LDAP server, when using the EXOP backend, supports two LDAP extended operations, GetDnForUserid and GetPrivileges, that retrieve Policy Director data from any LDAP server. See Using extended operations to access Policy Director data for more information.
  • Native authentication: The z/OS LDAP server allows clients to bind to entries in a TDBM, LDBM, or CDBM backend by using the system for verifying the authentication attempt. The client can perform a simple bind supplying an LDAP DN of an entry in a TDBM, LDBM, or CDBM backend along with a security manager-maintained password or password phrase. Password or password phrase authentication is then performed by the security manager. See Native authentication for more information.
    Note: To use native authentication, any security manager implementing the SAF service required by the RACROUTE REQUEST=VERIFY,ENVIR=CREATE macro function call can be used.
  • LDAP Version 3 protocol support: The LDAP server provides support for Version 3 of the LDAP protocol in addition to the LDAP Version 2 protocol. Version 3 includes:
    • All protocol operations
    • Implicit bind
    • Certificate (or Simple Authentication and Security Layer) bind
    • Version 3 referrals
    • Aliases
    • Controls
    • Root DSE support
    • Globalization (UTF-8) support
    • Modify name supported for all entries including subtree move
    • Schema publication
    • Additional syntax support
    • Online schema update capability
  • Dynamic schema: The LDAP server allows the schema to be changed dynamically through the LDAP protocol. See LDAP directory schema for more information.
  • Globalization (UTF-8) support: The LDAP server allows storage, update, and retrieval, through LDAP operations, of national language data using LDAP Version 3 protocol. See UTF-8 support for more information.
  • SASL external bind and client and server authentication: The LDAP server allows client applications to use a certificate when communicating with the server using SSL/TLS communications. To use a certificate on bind, the server must be configured to perform both client and server authentication. This ensures that both entities are who they claim to be. See Setting up for SSL/TLS for more information.
  • SASL GSS API Kerberos bind with mutual authentication: The LDAP server allows clients to bind to the server using Kerberos credentials. Mutual authentication is used to verify both the client and server identities. See Kerberos authentication for more information.
  • SASL CRAM-MD5 and DIGEST-MD5 authentication: The LDAP server allows clients to bind to the server using DIGEST-MD5 (RFC 2831) and CRAM-MD5 (RFC 2195) authentication bind methods. See CRAM-MD5 and DIGEST-MD5 authentication for more information.
  • Support for root DSE: The LDAP server supports search operations, including subtree search, against the root of the directory tree as described in RFC 2251. The so-called Root DSE can be accessed using LDAP V3 search operations. See Root DSE and z/OS IBM Tivoli Directory Server Client Programming for z/OS for more information.
  • Extended group membership searching: The LDAP server supports extended group membership searching which allows the LDAP server to find a DN that might be a member of static and nested groups in a backend (TDBM, LDBM, or CDBM) where the DN does not reside. The LDAP server can find the group memberships for the DNs in the other backends that are configured. See the extendedGroupSearching configuration file option, Configuration file options for more information.
  • Supported server controls: The LDAP server supports the following:
    • authenticateOnly
    • Do Not Replicate
    • IBMLdapProxyControl
    • IBMModifyDNRealignDNAttributesControl
    • IBMModifyDNTimelimitControl
    • IBMSchemaReplaceByValueControl
    • manageDsaIT
    • No Replication Conflict Resolution
    • pagedResults
    • PasswordPolicy
    • PersistentSearch
    • Refresh Entry
    • replicateOperationalAttributes
    • Replication Supplier ID Bind
    • Server Administration
    • SortKeyRequest
    See Supported server controls for more information.
  • Supported extended operations: The LDAP server supports the following:
    • Account status
    • Cascading control replication
    • changeLogAddEntry
    • Control replication
    • Control replication error log
    • Control replication queue
    • Effective password policy
    • GetDnForUserid
    • GetEffectiveACL
    • GetPrivileges
    • Quiesce or unquiesce context
    • Remote auditing
    • Remote authorization
    • RemoteCryptoPKCS#11
    • RemoteCryptoCCA
    • Replication topology
    • Start TLS
    • unloadRequest
    • User type
    See Supported extended operations for more information.
  • Attribute encryption or hashing: The LDAP server supports encryption or hashing of the values of several critical attributes to prevent unauthorized access to these attribute values in TDBM, LDBM, and CDBM backends. The attributes that can be encrypted or hashed are as follows:
    • ibm-replicaKeyPwd
    • ibm-slapdAdminPw
    • ibm-slapdMasterPw
    • replicaCredentials
    • secretKey
    • userPassword
    See Configuring for encryption or hashing for more information.
  • Multiple socket ports: The LDAP server can be configured to listen for secure and nonsecure connections from clients on one or more IPv4 or IPv6 interfaces on a system. With the listen configuration option on the LDAP server, the host name, a specific IPv4 or IPv6 address, or all active and available IPv4 and IPv6 addresses available on the system, along with the port number, can target one or multiple IPv4 or IPv6 interfaces on a system. See the listen configuration option, listen ldap_URL, for more information.
  • Persistent search:The LDAP server provides an event notification mechanism for applications, directories, and meta directories that must maintain a cache of directory information or to synchronize directories when changes are made to an LDAP directory. Persistent search allows these applications to be notified when a change has occurred. See Supported server controls for more information.
  • ibm-entryuuid attribute: The LDAP server generates a unique identifier for any entry that is created or modified and does not already have a unique identifier assigned. The unique identifier is stored in the ibm-entryuuid attribute. The ibm-entryuuid attribute is replicated to servers that support the ibm-entryuuid attribute. See Configuration file options to configure the serverEtherAddr option in the LDAP server configuration file.
  • ibm-entryCheckSum and ibm-entryCheckSumOp attributes: The LDAP server supports the querying of a checksum of all non-operational attributes with the ibm-entryCheckSum operational attribute. The LDAP server also supports the ibm-entryCheckSumOp operational attribute, which is a checksum of the following operational attributes: aclEntry, aclPropagate, entryOwner, ownerPropagate, creatorsName, modifiersName, createTimestamp, modifyTimestamp, ibm-entryuuid, ibm-pwdIndividualPolicyDN, and ibm-pwdGroupPolicyDN. The ibm-entryCheckSum and ibm-entryCheckSumOp operational attributes are used by the ldapdiff utility to simplify comparisons of entries between two different servers. See ldapdiff utility for more information.
  • ibm-allMembers and ibm-allGroups attributes: The LDAP server supports the querying of the members of static, dynamic, and nested groups in a TDBM, LDBM, or CDBM backend by using the ibm-allMembers operational attribute. The LDAP server also supports the querying of the static, dynamic, and nested groups that a user belongs to with the ibm-allGroups operational attribute.
  • Plug-in support: The LDAP server can be configured to provide access to extensions to the LDAP server. The extensions are supplied by other products or created by you. Plug-in extensions are invoked before, during, or after the LDAP server processes a client request. The z/OS LDAP server provides two client operation plug-in extensions of its own: remote crypto and ICTX. See the plugin configuration option in Customizing the LDAP server configuration for more information about configuring a plug-in extension. See z/OS IBM Tivoli Directory Server Plug-in Reference for z/OS for more information about creating a plug-in extension and the remote crypto and ICTX plug-in extensions.
  • Workload Management: The LDAP server can be configured to use transaction names configured in Workload Manager (WLM) to use different performance goals for LDAP operations based upon the client's IP address or the bound user's distinguished name (DN). See Workload manager (WLM) for more information about using WLM with the LDAP server.
  • Comparing directories: The ldapdiff utility is provided to compare the directory contents of two different LDAP servers. This utility is useful in determining and optionally synchronizing data between a master and replica server before configuring basic or advanced replication. See ldapdiff utility for more information.
  • Extended operations utility: The ldapexop utility provides a command line interface for the following extended operations: Account status, Cascading control replication, Control replication, Control replication error log, Control replication queue, Effective password policy, GetEffectiveACL, User type, Quiesce or unquiesce context, and Replication topology. See ldapexop utility for more information.
  • Password policy: The LDAP server supports password policy which is a set of rules that control how passwords are defined, used, and administered. See Password policy for more information.
  • Group search limits: Groups can be used to set specific size and time limits for searches requested by members of the group, providing greater control over usage of LDAP server resources during search operations. See Managing group search limits for more information.
  • Paged and sorted search results: The LDAP server supports paged and sorted search results. Paged search results provide paging capabilities for LDAP client applications that want to receive just a subset of search results at a time. Sorted search results enable LDAP client applications to receive sorted search results based on a list of criterion, where each criteria represents a sort key. See pagedResults and SortKeyRequest for more information.
  • Administrative group and roles: The LDAP root administrator can delegate administrative authority to different users by placing them in the administrative group and assigning one or more administrative roles. The roles are assigned in the LDAP administrative group member entry or alternately the roles are assigned in RACF. See Administrative group and roles for more information.

Participation in multilevel security

Multilevel security is an enhanced security environment that can be configured on a z/OS system from the SECLABEL class and various SECLABEL-related options. In this environment, the security server and trusted resource managers enforce mandatory access control policies in addition to the typical discretionary access control policies. Resource managers that do not support mandatory access control processing can participate in a multilevel secure system, if they are physically managed, to guarantee that all information made available by that resource manager has the same single security label and all users of the resource manager are permitted to that security label. These servers are referred to as single-level security. Each LDAP server can participate in a multilevel security environment by being configured as a single-level server. For more information about configuring a z/OS system for multilevel security and how to configure an LDAP server in that environment, see z/OS Planning for Multilevel Security and the Common Criteria.

RFCs supported by z/OS LDAP

The z/OS LDAP server supports all or parts of the following Internet Engineering Task Force (IETF) request for comments: Although the LDAP V3 protocol RFCs are listed as supported, the specific function that z/OS LDAP supports is listed in the LDAP Version 3 protocol support section. See What are the capabilities of the z/OS LDAP server? for more information.
Note:
  1. RFC 2251 is listed as supported, however, the z/OS LDAP server does not support the documented binary option.
  2. RFCs 2251 and 2254 are listed as supported, however, the z/OS LDAP server does not support extensible search filters. Approximate search filters are treated as equality search filters in the z/OS LDAP server.
  3. RFC 2252 is listed as supported, however, the z/OS LDAP server does not support all documented schema syntaxes. See LDAP directory schema for more information about the schema syntaxes supported by the z/OS LDAP server.
LDAP RFCs rely on the International Telecommunication Union (ITU-T) standards to define many of the basic constructs:
  • X.500 The Directory: Overview of Concepts, Models and Services
  • X.501 The Directory: Models
  • X.520 The Directory: Selected Attribute Types
  • X.690 Abstract Syntax Notation One (ASN.1)

Draft RFCs

The z/OS LDAP server supports all or parts of the following request for comment (RFC) draft:
  • Password Policy for LDAP directories