After trying several methodologies to create a consistent method for application to use LDAP directories, we have found this to work well for most applications we have encountered.
Of course, there will always be applications that need something not provided here, and that is when you contact us. Custom Attributes
All attributes that were added beyond the "Base" schema are documented in this section. (We refer to the base schema as what was provided from the LDAP vendor by default)
Although this discussion is specific to eDirectory from Novell, the implementation has been done on other vendor products. The differences to be aware of are what is provided by the vendor in their "base" schema and the inheritance from ndsLoginProperties. The ndsLoginProperties provides the attributes required for an object to authenticate to the directory.
dicAppData#This attribute provides developers some flexibility, this custom attribute types was defined. This attribute is for use by the developer to store parameters for his application. This attribute maybe sized (we used 64512 as a maximum). As an example, the developer may wish to store XML or key-value pairs in this attribute. This attribute is multi-valued.
The values could be used to populate the application specific attribute with the default values. Application Specific Attribute
Each dicAppInfo ObjectClass will have an “application specific attribute” with the same name as this uid that is added to the dicPersonInfo auxiliary ObjectClasses.
This application specific attribute should be populated with something when a user is granted authorization to the application.
The ACL for this application specific attribute should be restricted such that changes may only be made by the application object itself or their designee. It would also be possible to not allow the user object it self from reading this attribute. Custom ObjectClasses
The purpose of the dicPersonInfo ObjectClass is to allow the dynamic addition and removal of attributes to typical people entries within the directory. This Auxiliary class should be added to the typical people entries when they are created.
This ObjectClass contains the following Attributes:
- Application Specific Attribute
- Of course this ObjectClass can be used to add any additional attributes to the people entries.
The application object class is the dicAppInfo object class. These objects contain information about a specific application (application name, ID, location, etc). This object is derived from the top, dynamicGroupAux, ndsLoginProperties and device ObjectClasses and adds additional functional attributes. The primary attributes used in the dicAppInfo object are as follows:
- uid - (required) (nds=UniqueID) This attribute stores the application ID, a unique identifier of a particular instance of an application in the directory. Additionally, it is used to find application attribute information in the directory. This attribute should be unique within the entire directory. For our implementations we use always replace uid (i.e it never contains more than one value)
- cn - (required) (inherited from device) - This will be set to the same value as the uid. For our implementations we use always replace uid (i.e it never contains more than one value) this might be used for renaming compatibility.
- serialNumber - (inherited from device)
- seeAlso - (inherited from device)
- owner - (inherited from device)
- ou - (inherited from device)
- o - (inherited from device)
- l - (inherited from device)
- ipHostNumber - (inherited from device) Description: IP address as a dotted decimal, e.g. 192.168.1.1, omitting leading zeros The ipHostNumber and ipNetworkNumber attributes are defined in preference to dNSRecord (defined in RFC 1279), in order to simplify the DUA`s role in interpreting entries in the directory. A dNSRecord expresses a complete resource record, including time to live and class data, which is extraneous to this schema. The trailing zeros in a network address MUST be omitted. CIDR-style network addresses (e.g. 192.168.1/24) MAY be used.
- Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of RFC 1884, such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address.
- ipServicePort - (inherited from device) Single-valued - The port the service uses. (e.g. DNS uses port 53)
- description - (inherited from device) - The product name of the application. General description of this application.
- dicAppData - memberQueryURL - An LDAP query maybe entered in this attribute and then a request for the “member” attribute will return a list of all DNs that satisfy the LDAP query.
Since this ObjectClass inherits from the ndsLoginProperties ObjectClass, the dicAppInfo ObjectClass could be used as the service account for the application.
dicAppInfo Example#As the concept of the dicAppInfo ObjectClass may not be easily understood, an example of how this would work is provided in this section.
An application SiebelBest is one application that we used in our LAB and is used here for an example.
- . An entry for the SiebelBest is created from the dicAppInfo ObjectClass and the following entries are populated
uid = "SiebelBest" cn = "SiebelBest" serialNumber = ver 1.6 seeAlso (not Populated) owner = uid=smithJ, ou=people, dc=willeke, dc=com ou = Siebel Management Group o – Directory-Info.Com l - Butler ipHostNumber = 172.24.22.99 ipServicePort (not Populated) dicAppData = !type=USER!rights=READ
- . A password is assigned to this object. This object is then to be used as the services account for the application. Appropriate ACLs also need to be defined if they are beyond the standard ACL assignments.
- . A SiebelBest attribute is create of the same syntax as the dicAppData attribute.
- . The SiebelBest attribute is added to the nwPersonInfo auxiliary ObjectClass.
- . For all uses of the application the, the SiebelBest attribute is populated with whatever data the application developer decides. This might just be something like “|type=user”. This attribute maybe populated with anything the application owners choose. As an example, this could be a hashed XML properties file.
- . An ACL is created so that the SiebelBest Attribute can only be modified by the SiebelBest application object.
- . Since the dicAppInfo class inherits from dynamicGroupAux class, a Dynamic Group could be created to determine which users have a populated SiebelBest attribute. This would allow an administrator to determine who the application users are by entering a query that identified users with a populated SiebelBest attribute.