Show TOC Start of Content Area

Background documentation LDAP Directory as Data Source  Locate the document in its SAP Library structure

Purpose

The user management engine (UME) can use a directory service as its data source for user management data. You can link the UME to the directory service as either a read-only or read-write data source.

More information: SAP Note 673824.

If you want to use an Application Server for ABAP (AS for ABAP) as the data source, but synch AS for ABAP with the directory service, see Configuring the UME for Directory Service Synch with AS ABAP.

Prerequisites

        The directory service has a hierarchy of users and groups that is supported by UME. The hierarchies supported by UME are:

        Groups as tree

        Flat hierarchy

More information: Organization of Users and Groups in LDAP Directory.

        The administrator of the directory service must create a user that UME can use to connect to the directory service. This user should have read and search permissions for all branches of the directory service. If UME also needs to write to the directory service, the user must additionally have create and change authorizations.

Constraints

        The Distinguished Names (DNs) of user and group objects must not be longer than 240 characters.

        The UME maintains internally, the default groups, Everyone, Authenticated Users, and Anonymous Users. If you create groups with these names with the native user interface of your LDAP directory, you must block the UME from reading them from the LDAP directory. Otherwise the name is ambiguous. To block the group name in LDAP, use the UME property ume.ldap.blocked_groups.

        Similarly, if you create user accounts with the same user ID as the service users used internally, you must block the UME from reading them from the LDAP directory. Service user IDs adhere to the naming convention <application_name>_service. To block the user account ID in LDAP, use the UME properties ume.ldap.blocked_accounts and ume.ldap.blocked_users.

        If user management is set up with write access to an LDAP directory, the following restriction applies: When assigning members to a group that is stored in the LDAP directory, you can only assign users or groups that are also stored in the LDAP directory. You cannot assign users or groups from the database to groups from the LDAP directory. 

You can, however, assign users and groups stored in the LDAP directory to a group in the database.

      You cannot search for users with locked passwords. Searching for users with locked passwords returns no results.

      If you are using an LDAP directory with a deep hierarchy, you cannot assign users or groups as members of another group using the UME user administration tools.

      You cannot assign UME groups to LDAP groups.

Available Data Source Configuration Files

Choose from the following options:

Note

Data source configuration files for certified LDAP directory vendors are delivered with the AS for Java or are available from SAP Note 983808. To find the configuration file, use the Config Tool.

More information: Editing UME Configuration Files.

For recently certified LDAP directories, contact the LDAP directory vendor directly. SAP has set up a program to certify LDAP directory solutions for use with UME. For a list of certified LDAP vendors, visit the SAP Service Marketplace at service.sap.com/securitypartners Partners for directory services (Interface to LDAP enabled directories).

Option 1: Read-Writer Directory Service

Description:

The following data is written to and read from the LDAP server:

      Users (displayname, lastname, fax, email, title, department, description, mobile, telephone, streetaddress. uniquename, and group membership – and any other attributes defined through attribute mapping)

      User accounts (logonid, password, ID of the assigned user)

      Groups (displayname, description, uniquename, and the group members)

The following data is written to and read from the database:

        Additional data (for example, information about when a user was last changed)

        Other principal types (for example, roles)

        Additional attributes (for example, attributes not covered by the standard object classes of the LDAP server)

Use case: You have a mixed system landscape including both SAP and non-SAP systems, or you have an existing corporate LDAP directory in your system landscape. You want to store standard user data such as name, address, e-mail address, and so on in the directory, while you store application-specific data in the database.

Configuration file:

        If the LDAP directory has a flat hierarchy: dataSourceConfiguration_<LDAP_directory_vendor>_not_readonly_db.xml

        If the LDAP directory has a deep hierarchy: dataSourceConfiguration_<LDAP_directory_vendor>_deep_not_readonly_db.xml

Option 2: Read-Only Directory Service

Description: You cannot create, modify, or delete users or groups in the LDAP server. All newly created principals and additional data are stored in the database.

Use case: You have an existing corporate LDAP directory in your system landscape and have existing processes for administering user data on this directory. You are using a portal and want all users that register themselves in the portal to be stored separately from the user data on the corporate directory.

Configuration file:

        If the LDAP directory has a flat hierarchy: dataSourceConfiguration_<LDAP_directory_vendor>_readonly_db.xml

        If the LDAP directory has a deep hierarchy: dataSourceConfiguration_<LDAP_directory_vendor>_deep_readonly_db.xml

End of Content Area