Java Desktop System Configuration Manager Release 1.1 Installation Guide

Chapter 2 LDAP Server

This chapter provides information about setting up and deploying an LDAP server for use with the Configuration Manager.


Within the Java Desktop System Configuration Manager framework, configuration data are associated with entities, which are entries in the LDAP repository and correspond to elements of the organizational structure of the company.

The recognized entities are:

The organization and user entities are used to define a user tree, while the domain and host entities define a host tree. These two trees are independent but are manipulated in a similar way in the framework.

The relationship of organization and domain entities with other entries is defined by the physical location of the entries within the repository. That is, the organization and domain entities can include any entry that is located below these two entities in the tree. The relationship of roles to users or hosts is defined by the attributes of the user and host entries.

The configuration data that are associated with an entity are stored in special entries that are managed by the framework. These entries are identified by the service name and the service container that are associated with the entries.


To use an existing LDAP server with the Configuration Manager, you need to:

Deployment Tools

The following deployment tools from the installation CD are required to use an existing LDAP server with the Configuration Manager:

Schema Extension

The configuration data are stored in entry trees that are attached to the entries that the data are associated with. Before you can store the object classes and attributes that are used by these trees on an LDAP server, you must add the objects and classes to the LDAP server schema. For example, the schema extension file that is provided uses the LDIF format to add these objects and classes to the Sun JavaTM System Directory Server. To add these objects and classes to other LDAP servers, you need to use a format that is recognized by the servers.

Organizational Mapping

To define the mapping between the LDAP entries and Configuration Manager entities, the Organization mapping file must be edited. Values that match the layout of the LDAP repository must be provided for the various keys.

User entities are identified by an object class that all entities use, as well as an attribute whose value must be unique within the whole repository. A display name format can be provided which will affect how users are displayed in the management application and optionally a container entry can be defined if the user entries within an organization use such an entry. The key names and their default values are:

# Object class that all user entries use
# Attribute whose value in user entries is unique within the repository
# Optional container in organization entries of the user entries, 
# remove line if not used
# Display name format within the management application
User/DisplayNameFormat=sn, givenname

Role entities are identified by a list of possible object classes that they use, along with the corresponding naming attributes. These lists use the format <item1>,<item2>,...,<itemN> and must be aligned. That is, the lists must have the same number of items and the nth object class must be used with the nth naming attribute. Two keys define the relationship between roles and users as well as between roles and hosts. The VirtualMemberAttribute key must specify an attribute whose values can be queried from a user or host entry. The key must also contain the full DNs of the roles that the entry belongs to. The MemberAttribute key must specify an attribute from a user or host entry for the search filter. The key must also contains the full DNs of the roles that the user or host belongs to. The VirtualMemberAttribute key can be a Class Of Service virtual attribute, whereas the MemberAttribute key must be a physical attribute that can be used in a filter. The key names and their default values are:

# List of object classes for roles
# Aligned list of corresponding naming attributes
# Physical attribute (usable in a filter) containing the DNs 
# of the roles of a user/host
# Attribute whose query on a user or host return the DNs of the 
# roles it belongs to

Organization entities are identified in a way similar to roles, with two aligned lists of object classes and corresponding naming attributes. The key names and their default values are:

# List of object classes for organizations
# Aligned list of corresponding naming attributes

Domain entities are identified in a way that is similar to organization entities. The key names and their default values are:

# List of object classes for domains
# Aligned list of corresponding naming attributes

Host entities are identified in a way that is similar to user entities. The key names and their default values are:

# Object class that all host entries use
# Attribute whose value in host entries is unique within the repository
# Optional container in domain entries of the host entries, 
# remove line if not used

User Profile Mapping

To define the mapping between the LDAP user entries attributes and Configuration Manager user entities attributes, the User Profile mapping file must be edited. Each key corresponds to a Configuration Manager user attribute. A key can be assigned as a value to the name of an attribute in a user entry, as identified by the organizational mapping. Attributes which are used in the User/DisplayNameFormat setting must be assigned in the User Profile mapping. The key names and their default values are:

# inetOrgPerson.givenName
org.openoffice.UserProfile/Data/givenname = givenname
org.openoffice.UserProfile/Data/sn = sn
# inetOrgPerson.initials
org.openoffice.UserProfile/Data/initials = initials
# organizationalPerson.street
org.openoffice.UserProfile/Data/street = street,postalAddress,streetAddress 
# organizationalPerson.l (city)
org.openoffice.UserProfile/Data/l = l
# (state)
org.openoffice.UserProfile/Data/st = st
# organizationalPerson.postalCode
org.openoffice.UserProfile/Data/postalcode = postalcode
# country.c (country)
org.openoffice.UserProfile/Data/c = 
# organizationalPerson.o (company)
org.openoffice.UserProfile/Data/o = o,organizationName
# deprecated -- no LDAP corollary
org.openoffice.UserProfile/Data/position =
# organizationalPerson.title
org.openoffice.UserProfile/Data/title = title
# inetOrgPerson.homePhone
org.openoffice.UserProfile/Data/homephone = homephone
# organizationalPerson.telephoneNumber 
org.openoffice.UserProfile/Data/telephonenumber = telephonenumber
# organizationalPerson.facsimileTelephoneNumber
org.openoffice.UserProfile/Data/facsimiletelephonenumber = 
# inetOrgPerson.mail
org.openoffice.UserProfile/Data/mail = mail


Once the mapping files have been customized to reflect the state of the LDAP repository, they can be deployed. If the schema of the LDAP server already contains the required object classes and attributes, the script createServiceTree can be run directly, otherwise the script deployApoc must be run.

The deployApoc script is targeted for use with Sun JavaTM System Directory Servers. It will copy the provided schema extension file to the proper directory and cycle the LDAP server, then invoke the createServiceTree script. It must be run as a user with permissions to copy files in the schema repository and restart the server and be invoked by:

./deployApoc <Directoy Server Directory>

The <Directoy Server Directory> parameter must be the path to the slapd-<server name> subdirectory of a Directory Server installation. Assuming the installation used the default directories and the server is named myserver.mydomain, that directory would be /var/Sun/mps/slapd-myserver.mydomain.

The createServiceTree script, whether invoked directly or from the deployApoc script, will prompt the user for the location of the LDAP server (host name, port number and base DN) and for the definition of a user with administrative rights (full DN and password). The script then creates a bootstrap service tree in the LDAP server and stores the mapping files in it. It can be run as any user and is invoked by:


The user is then prompted for:

An entry whose DN is:

ou=ApocRegistry,ou=default,ou=OrganizationConfig,ou=1.0,ou=ApocService,ou=services, <baseDN>

is created and filled with the contents of the two mapping files.

As mentioned previously, the operations performed by the deployApoc script assume an LDAP server whose installation directories, layout, and schema extension procedure closely match Sun Java System Directory Server's one. Other directories will require a manual extension of the schema before being able to run the createServiceTree script. For further information concerning the use of OpenLDAP and ActiveDirectory, refer to Appendix C, Using OpenLDAP and Active Directory with the Configuration Manager.

The created tree, which matches the one which will hold configuration data associated to entities, is aligned with the structure of the trees used for service management in Sun Java System Identity Server.

Additional Considerations

The Configuration Manager framework requires that a connection to the LDAP server, with read and search permissions, can be created in order to identify which full DN is associated with a given user or host identifier coming from the desktop. As such, the repository must be configured so as to either allow anonymous connection, or a special user with read and search access must be created for that purpose.

The management application creates service trees under entries mapped into entities to hold the configuration data for these entities. As such, user entries used for management purposes need to have the right to create subentries under the entries they are managing.

Authentication of the users of the framework from the desktop clients can be done with two methods named Anonymous and GSSAPI. The Anonymous method requires that anonymous access for read and search is enabled throughout the repository as the desktop clients will not provide any credentials when attempting to retrieve data from the LDAP server. To use the GSSAPI method (using Kerberos for authentication), the LDAP server must be configured as described in the "Managing Authentication and Encryption” chapter of the Sun JavaTM System Directory Server 5 2004Q2 Administration Guide.