abstract (object classes)
Abstract classes are used to build other object classes, but never for building direct instances of the class. A special abstract class called top is the ultimate superclass of all object classes. To build a class that doesn’t inherit any attributes, you build a class that is a direct subclass of top.
ApacheDS (Apache Directory Server) is an embeddable, extendable, standards compliant, modern LDAP server written entirely in Java, and available under the Apache Software License.
auxiliary (object classes)
You use auxiliary classes to mix and match. An auxiliary class augments the other object classes of an entry without the costs tied to inheritance. The auxiliary class is never involved in inheritance because it is never the super class for a structural or abstract class. Instead, auxiliary classes are explicitly included in an entry rather than included implicitly via inheritance. You use auxiliary classes to add specific functionality to a standard object class without modifying the original object definition. The same auxiliary class may be added to entries with different object classes and this is the most significant advantage of the auxiliary class. In other words, the auxiliary class is not part of a chain of inheritance and you can use it with entries of differing classes.
So, which is better: inheritance or Auxiliary class? The main thing to consider is the users who must create new entries. They must explicitly include both object classes unless you have some kind of user interface that abstracts this from them. If you use inheritance instead, they need to include only one object class. With the auxiliary option, problems can occur if a user forgets one of the object classes.
If the object holding this attribute corresponds to a person, it is typically the person’s full name.
Directory Information Tree
LDAP Data Interchange Format
Example LDIF file with organizational and person entries:
dn: o=burlesontech.com objectclass: top objectclass: organization o: burlesontech.com dn: ou=People, o=burlesontech.com objectclass: organizationalUnit ou: people dn: ou=marketing, o=burlesontech.com objectclass: organizationalUnit ou: marketing dn: cn=Cody Burleson, ou=people, o=burlesontech.com objectclass: top objectclass: organizationalPerson cn: Cody Burleson sn: Burleson givenname: Cody uid: cburleson ou: marketing
Object Identifier used to uniquely name each entity in the LDAP schema. The syntax is a string of numbers separated by periods. For example:
The string can be of any length and can contain any number of segments. The left-most segments are considered ‘most significant’. An OID can be subdivided simply by adding more segments to the end; the collective group of all OIDs beginning with a specific series of numbers is commonly called an ‘arch’.
Since OIDs are hierarchical, your organization can obtain one OID and then branch it as needed. For example, if your organization’s OID was 1.1, you could use 1.1.1, 1.1.2, 1.1.3, 184.108.40.206, etc. A root OID for your organization, a.k.a. Private Enterprise Number (PEN), can be obtained from IANA, the Internet Assigned Numbers Authority. You can typically receive a PEN within a few days after applying online although IANA commits only to a minimum of 30 days.
There is a specific arch that is reserved for private use within an enterprise. That arch is 220.127.116.11.4.1. Following the private-OID arch, organizations add their own Private Enterprise Number (PEN) to form a sub-arch that belongs totally to that organization and is globally unique. My company, Burleson Technology Group, has been assigned the Private Enterprise Number 31751, so our LDAP arch is 18.104.22.168.4.1.31751. Thus, if we created any unique entities in our LDAP schema, that’s the arch we would start with. We could, of course, branch it or add to the end, so that OIDs like 22.214.171.124.4.1.31751.1 or 126.96.36.199.4.1.317188.8.131.52 would be valid for our schema.
There is a specific arch (184.108.40.206.3) which is reserved by the IANA for experimentation and you can assign OIDs within this arch for temporary purposes, such as testing or for experimenting with your schema while waiting for your permanent PEN. OIDs within this experimental arch are not guaranteed to be globally unique, and therefore should not be published external to your organization nor used for production LDAP directories.
OUs are typically used to create a hierarchy of containers within a domain. Only OUs within the same domain can have relationships. OUs of the same name in different domains are independent.
Relative Distinuished Name
The family name (last name) of a person
structural (object classes)
Each directory entry (instance) must contain at least one structural class. A structural class always uses inheritance, and it must be a subclass of some other object class. Only structural classes can use inheritance; abstract and auxiliary classes cannot use inheritance. A structural class can be a super class of another object class.