UMRA tables - Concept

Previous topic:

UMRA tables - Introduction

General

With UMRA, solutions can be created for the delegation of one or more user management tasks. Forms & Delegation includes two separate applications, the UMRA Console and UMRA Forms. In this document, it is assumed that you already have basic knowledge of working with UMRA. If this is not the case, please make yourself familiar first with the UMRA basics.

The UMRA Console is used by systems administrator to build an interface for the end user and to add and configure built-in script actions for the delegation project. The interface is created using forms which can be fully customized with your own titles, text fields, user input fields, buttons, tables, graphics, etc. Once the form project has been properly set up, the delegate user can run it in the UMRA Forms application to perform a specific user management task. The underlying scripting intelligence is neither accessible nor visible for the delegate user.

Selecting data using form tables

In a form, the administrator can also add form tables. Form tables are used to display user resource data from Active Direcory and other information systems.

LDAP table showing users in Active Directory as part of a Reset Password delegation form

In the UMRA Console, the administrator specifies which script actions should be run on the selected table entries. The execution of these script actions can be assigned to a button (e.g. "Reset Password"). In UMRA, a wide variety of script actions is included to create, manage and delete Active Directory objects. Finally, the administrator also specifies who has priviliges to run the project.

In the following two figures, the use of a form table is shown in more detail. As part of a delegation project to reset passwords, an LDAP table is inserted in the form window to retrieve all users in a specific organizational unit in Active Directory using the query

(&(objectClass=user)(!(objectClass=computer)))

with a binding to LDAP://OU=<NameOU>, DC=MyDomain, DC=local.

 Defining an LDAP query for an LDAP table

This query retrieves all objects of the "user" object class in the OU "<NameOU>". Computer accounts are exempted from the results. In the resulting form table, a user can be selected for whom the password needs to be reset. The script action Edit User logon takes the user input to reset the password for the selected user and is executed when the button Reset Password is clicked. In the lower screen of the figure below, the resulting form for the delegate user is shown.

Reset password delegation project. The result of the LDAP query is displayed in the LDAP table (shown here with a red marquee)

In a project form, several table types are available which are shown in the table below:

Network table

A network table is used for Windows NT 4 environments and can be of one of the following network data types:

• User accounts of an OU,

• User accounts of a global group,

• User accounts of a domain

• User accounts of a single computer.

Specifying the network data type only determines the scope of the network calls to be executed by UMRA and the columns that can be shown for the corresponding network data table. To determine the data that must be collected, you must specify the actual parameters or arguments that are used to collect the network data. These are different for each network data type (see the table below).

The columns can be assigned to a variable. When a delegate user selects an entry in the resulting network table, the name of the variable and the corresponding value will be passed to the UMRA service. See the section Processing user input for more information.

Fixed table

The content of this table is either entered directly in UMRA or taken from a flat text file. It is used to to present the end user with specific fixed content in a form, such as a division, department, OU, domain etc. The characteristics of a fixed table are that the information is not derived from Active Directory, that it only contains 1 column and that it always has the same contents.

Simple fixed table (list of entries)

Generic table - LDAP query

This powerful generic table type allows you to query Active Directory and show the results in a form table. To run a (complex) LDAP search, the following information should be specified:

1. LDAP binding - the scope of the LDAP search;

2. LDAP filter - the objects you wish to filter on;

3. Attributes - the attributes you wish to retrieve for these objects. These components will be individually discussed.

LDAP binding

Starting with Windows 2000, the LDAP provider is used to access Active Directory. This binding method requires a binding string, which can be defined in three different ways in UMRA:

LDAP filter

An LDAP search filter can be defined as a clause specifying the conditions that must be met by Active Directory objects. Only those objects meeting the requirements are returned.

A condition takes the form of of a conditional statement, such as "(cn=TestUser)". Each condition must be enclosed in parenthesis. In general, a condition includes an attribute and a value, separated by an operator.

Conditions can be combined using the following operators (note that the operators "<" and ">" are not supported).

Conditions can also be nested using parenthesis. Furthermore, you can use the "*" wildcard character in the search filter.

An example of an LDAP filter is shown in the figure below :

(&(objectCategory=person)(objectClass=user) (userAccountControl:1.2.840.113556.1.4.803:=2))

This filter, used to obtain disabled user objects, includes 3 conditions, which should all be met (indicated by the AND ("&") operator).

The userAccountControl attribute in this example needs some further explanation. This is a so called bitmask attribute, a single attribute containing numerous property values for controlling user account behaviour. A bitmask attribute can be evaluated using an LDAP matching rule using the following syntax:

attributename:ruleOID:=value

where attributename is the LDAPDisplayName of the attribute, ruleOID is the object ID (OID) for the matching rule control, and value is the decimal value you want to use for comparison. In the example above, the string "1.2.840.113556.1.4.803=2" represents an LDAP matching rule for disabled user accounts.

Attributes

Each object in Active Directory has a set of attributes, defined by and depending on its type and class. Using the LDAP filter you have filtered on some objects representing single entities (users, computers, printers, applications, etc.) and their attributes. In the Attributes tab you can define the LDAP display name for the attributes you wish to return for the filtered objects. In the example shown below, the attributes Name, Description and sAMAccountName are specified as the attributes to be returned.

Attributes can either be selected from an extensive list of built-in attributes, or entered by the user. For a full list of attributes, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/attributes_all.asp or check the MSDN library.

The final result of an LDAP search is displayed in a generic table (see figure below). In the same way, you can retrieve user accounts in a specific OU, show a list of groups, etc.

To process selected table entries, the column holding the attribute values can be assigned to a variable and used as input for a script action. For more information, see section Processing user input.

Generic table - Database query

IIn a large enterprise environment, not all user resource data are stored in Active Directory. Other information systems, an HR system or a phone system for example, may also hold user related information. In an UMRA project form, a generic table can be inserted to display information from these systems. As part of the table setup, the administrator needs to specify the database to connect to, as well as a database query to define which data should be retrieved and shown in the table.

The generic table for databases can be used to connect to any database or information system. MS Access databases can be accessed directly through the Jet engine. Other databases (SQL, ERP, HR systems, PeopleSoft, etc.) can be accessed through OLE DB. The number of available OLE DB providers will depend on your local configuration (see figure below).

List of available OLE DB database connections

The option to connect to other databases is an extremely powerful feature in UMRA, since it allows you to combine Active Directory with user data from a wide range of other information systems. Figures 9 and 10 show an example where a generic form table is configured to connect to an HR system (SQL server). When the connection settings have been specified correctly, the message "Test connection succeeded" will be displayed when you click the Test Connection button.

Setting up a SQL database connection

When the connection data have been specified, a binding string is created to connect to the database.

Binding string to connect to the database

Once the connection has been properly set up, a SQL query can be created. In the example below, a SQL query has been specified to retrieve names of employees, locations and phone numbers for the IT department from the EmployeePhone table:

SELECT Employee, Department, Location, Phone FROM EmployeePhone WHERE Department='IT'.

Specifying the database query

In the figure below, the result of this database query is shown. The query has returned the data in the columns Employee, Department, Location and Phone for all rows where Department is equal to "IT".

Result of a database query is shown in an UMRA form

Next topics:

UMRA tables - Special table type - Generic table Variable

UMRA tables - Processing User Input

Hands-on:

Examples - UMRA tables - Creating an LDAP table

Examples - UMRA tables - Creating a form table to connect to a database

Examples - UMRA tables - Showing the content of a variable in a form table