Managing LDAP directory services using UMRA

Although primarily focusing on Microsoft Active Directory, User Management Resource Administrator (UMRA) can also manage any other directory service, as long as the directory service supports the Lightweight Directory Access Protocol (LDAP).

Examples of the directory services that can be managed with UMRA include Novell eDirectory, Linux OpenLDAP and Microsoft's Active Directory.

6.1. Introduction

Although primarily focusing on Microsoft Active Directory, User Management Resource Administrator (UMRA) can also manage any other directory service, as long as the directory service supports the Lightweight Directory Access Protocol (LDAP).

Examples of the directory services that can be managed with UMRA include Novell eDirectory, Linux OpenLDAP and Microsoft's Active Directory.

Main functions

The main reasons to use the LDAP functions of UMRA deal with the integration of networks with hybrid directory services. The UMRA LDAP functions include:

 Create user accounts and setup all attributes

 Manage group memberships

 Reset user account passwords

 Delete user accounts

 Manage all other directory service objects

With the UMRA LDAP functions, multiple directory services can be updated by executing a single task.

Example: When a form (of UMRA Forms and Delegation) is submitted, a user account can be created in Microsoft's Active Directory and Novell eDirectory in a single task.

Deployment scenarios

The UMRA LDAP functions are most often deployed for the following tasks:

 Synchronization of Active Directory updates with other directory services (Novell eDirectory, LINUX OpenLDAP);

 Synchronization of database system updates with (multiple) directory services;

 Helpdesk task delegation to manage the user account life cycle process, e.g. create user accounts, reset passwords etc.

for hybrid directory services networks.

Secure LDAP (SSL) support

The LDAP functions of UMRA support both secure and non-secure LDAP implementations. Secure LDAP is implemented using SSL.

The SASL authentication methods are not supported in UMRA.

6.2. Concept

Directory Service Infrastructure

The UMRA LDAP functions are typically used in a Microsoft Active Directory network environment with some other directory service that co-exists in the same network infrastructure. The other directory service is for instance Novell eDirectory or an OpenLDAP implementation on Linux. As long as the directory service supports LDAP, the directory service can be managed with UMRA.

UMRA Help

153 LDAP Server and LDAP Client

The computer that runs the directory service and supports LDAP is referred to as the LDAP Server. The software that connects to the LDAP Server is referred to as the LDAP Client. According to these conventions, the UMRA software always acts as the LDAP Client and the contacted directory service system is the LDAP Server.

Helpdesk scenario

In a helpdesk environment, the UMRA Forms client runs on a helpdesk computer. When a form is submitted by a helpdesk employee, the form and form input data is sent to the UMRA Service. The UMRA Service executes the script associated with the form. In a hybrid directory service environment, the script contains UMRA LDAP script actions to manage the LDAP directory service.

Figure 1: Network with helpdesk running UMRA Forms in a hybrid directory services network.

Security

The LDAP protocol supports a large variety of features for security and authentication. With UMRA, 2 options are available:

 Not secure: All communication with the LDAP Server and the UMRA software is not encrypted. Authentication is accomplished using an account name and a password that is sent as clear text. Although simple to implement, this option is not recommended because of security reasons. The option can be used for testing purposes.

Secure with SSL: All communication between the LDAP client, e.g. the UMRA software and the LDAP Server is encrypted using the SSL standard. This option is recommended and secure. All data is encrypted.

To implement this option, SSL certificates need to be installed on both the LDAP Client and Server. The methods how to do this, largely depends on the implementation of the operating system and directory service. For Microsoft Active Directory, Novell eDirectory and Linux OpenLDAP the exact implementations are described in this document. For other systems, a similar approach must be used.

154

6.3. UMRA LDAP script actions

Script actions overview

In UMRA, a number of script actions are available to manage an LDAP directory service. The script actions cover the most important LDAP functions to update a directory service and execute a query in the directory service. All LDAP calls are executed synchronously.

Script actions

UMRA LDAP action Description

Setup LDAP session on page 154 Initialize a secure or not secure LDAP session with the LDAP Server. The session parameters are stored in a variable that is used in subsequent UMRA LDAP actions.

Load LDAP modification data on page 155 Setup a data structure that is used to add and edit directory service items. The resulting LDAP modification data is stored in a variable that is referenced in subsequent script actions. The action is always used in combination with the Add and Edit UMRA LDAP actions.

Add directory service object (LDAP) on page

156 Add an item to the LDAP directory service. The data added is setup with action Load LDAP modification data.

Modify directory service object (LDAP) on

page 157 Update an existing item in the directory service. The data used to modify the existing directory service item is setup with action Load LDAP

modification data. Delete directory service object (LDAP) on

page 157 Delete an item from the directory service.

Search directory service (LDAP) on page 157 Execute a search action in the LDAP directory service. The results are returned in a generic table variable that can be used in subsequent script actions and forms.

Table 1: Overview of UMRA LDAP script actions Script action: Setup LDAP session

For each action to update or search the LDAP directory service, a session must be initialized first. The session is most often initialized in the beginning of the script and than used in all subsequent LDAP actions. The session is automatically released by the UMRA software when the script is finished.

Property Description

LDAP server The name of the host running the LDAP server. The name must be specified using the TCP/IP address or DNS name. Optionally, the name can be followed by a colon (:) and port number.

LDAP port Optional: The TCP port number of the LDAP server to which to connect. The property is ignored if the specified 'LDAP server' includes a port number. If not specified, the default port is used. For not secure LDAP, the default LDAP port is 389, for secure LDAP (SSL), the default port is 636.

UMRA Help

155 SSL encryption flag If set to 'Yes', the session uses SSL encryption to communicate. In this case, on both

the LDAP client and server side, appropriate SSL certificates need to be installed. If set to 'No', the action establishes a plain TCP connection and uses clear text (no

encryption). Several topics in this document describe how to setup secure LDAP.

User name The name of the user to connect to the LDAP server. If not specified, no user is authenticated, and no other LDAP actions can be executed. The format and exact name depends on the directory service.

User password The password of the user specified with property User name. Note that the password is stored with encryption.

LDAP session A data structure representing the resulting LDAP session. This property is an output only property and is generated automatically. The data is stored in a variable. (Default name: %LdapSession%) This property is used in other script actions.

Table 2: Properties of action Setup LDAP session

The LDAP session variable can be passed to other scripts that are executed within the context of the outer script. When the outer script ends, the LDAP session is released.

Script action: Load LDAP modification data

When a directory service is updated to create a new item or update an existing item, the operation is always specified by the one or more attributes, the attribute value(s) and the type of attribute value modification: add, delete or replace.

To support this mechanism, the script action is Load LDAP modification data is used. All attributes, attribute values and value modification types are specified with this action. The result is stored in a variable that holds all the attribute information. The variable is then used in the action to:

 Create the item with action Add directory service object (LDAP) on page 156 or

 Update the item with action Modify directory service object (LDAP) on page 157.

The action Load LDAP modification data does not communicate with the LDAP Server, that is, no session variable is required.

The LDAP modification data window is used to specify the LDAP modification data.

Figure 2: Specification of the LDAP modification data

156 In the example shown, the data is stored in variable %LdapData%. The data holds the modification values for 5 attributes:

objectClass, sn, givenName, homePhone and userPassword. The names of the attributes are specified using their LDAP names as specified in the schema of the directory service. The values for each attribute can be specified using variables. Each attribute can have one or more values.

Directory service schema

To specify the values of an attribute, the Setup LDAP modification data window is used.

Figure 3: Multiple value specification for a single attribute For the attribute you need to specify the following: