LDAP Directory as Data Source

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 .

• The directory service has a hierarchy of users and groups that is supported by UME. The hierarchies supported by UMEare:
  • 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 UMEcan 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.

• 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 UMEfrom reading them from the LDAP directory. Otherwise the name is ambiguous. To block the group name in LDAP, use the UMEproperty 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 UMEfrom 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 UMEuser administration tools.
• You cannot assign UME groups to LDAP groups.

Choose from the following options:

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