Setup

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

• Extend the server schema to support the custom object classes and the attributes that are used by the Configuration Manager to store configuration data.

• Customize and store in the server the mapping information for the entries in the repository as well as the entities that are supported by the Configuration Manager.

Deployment Tools

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

• 88apoc-registry.ldif: A schema file that introduces the object classes and attributes that are required for the storage of configuration data.

• OrganizationMapping: A default properties file that describes the mapping between LDAP entries and Configuration Manager entities.

• UserProfileMapping: A default properties file that describes the mapping between LDAP user entry attributes and Configuration Manager user profile attributes.

• createServiceTree: A script that stores the mapping files in the LDAP repository.

• deployApoc: A script that extends the schema of the LDAP server and that stores the mapping files in the LDAP repository.

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 Java^TM 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
User/ObjectClass=inetorgperson
# Attribute whose value in user entries is unique within the repository
User/UniqueIdAttribute=uid
# Optional container in organization entries of the user entries, 
# remove line if not used
User/Container=ou=People
# 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
Role/ObjectClass=nsRoleDefinition
# Aligned list of corresponding naming attributes
Role/NamingAttribute=cn
# Physical attribute (usable in a filter) containing the DNs 
# of the roles of a user/host
Role/MemberAttribute=nsRoleDN
# Attribute whose query on a user or host return the DNs of the 
# roles it belongs to
Role/VirtualMemberAttribute=nsRole

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
Organization/ObjectClass=organization
# Aligned list of corresponding naming attributes
Organization/NamingAttribute=o

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
Domain/ObjectClass=ipNetwork
# Aligned list of corresponding naming attributes
Domain/NamingAttribute=cn

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
Host/ObjectClass=ipHost
# Attribute whose value in host entries is unique within the repository
Host/UniqueIdAttribute=cn
# Optional container in domain entries of the host entries, 
# remove line if not used
Host/Container=ou=Hosts

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
# person.sn
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
# organizationalPerson.st (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 = 
facsimiletelephonenumber,officeFax
# inetOrgPerson.mail
org.openoffice.UserProfile/Data/mail = mail

Deployment

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 Java^TM 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:

./createServiceTree

The user is then prompted for:

• Host name (default: localhost): host name of the LDAP server,

• Port number (default: 389): port number of the LDAP server,

• Base DN: base DN of the LDAP repository,

• User DN (default: cn=Directory Manager): full DN of a user with enough permissions to create new entries under the base DN,

• Password: password of that user,

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.