Origins

The International Telecommunication Union, ITU http://www.itu.int/home/index.html, is an organisation of the United Nations (sorry, Carra, now I guess all directories are on par with poodles) which submits recommendations for the coordination of global telecom and radio systems.  The Telecommunication Standardisation Sector, ITU-T, is the branch submits recommendations for telecommunication standards.  ITU-T was formerly known as Comité Consultatif International Téléphonique et Télégraphique, CCITT.

Published in volume eight of the 1988 CCITT Blue Book, X.500 is the recommendation for “The Directory”.  Additional recommendations X. 501, 509, 512, 518, 519, 520, 521, 525, and 530 farther defined ITU’s idea for directory service functionality.  Once ITU-T put forth the recommendation, several international standards bodies got involved, and eventually yielding the 9594-1 standard from ISO (from isos, name used by the International Organisation for Standardisation) and IEC (International Electro-technical Commission).   I’ve got the 1993 version (./9594-1-X.500.A4.ps) but never bothered to get the updates.

X.500 Components

Some of the terminology used within the X.500 recommendation is used in non-X.500 directories.  If you want to more about these or what they do, read the ISO/IEC standard

• Directory Information Base (DIB) is used to store the directory data
• Directory Information Tree (DIT) is a hierarchy within the DIB
• Directory Service Agent (DSA) is a server which stores the DIB
• Directory User Agent (DUA) is an application interface over which queries are made to the DSA
• Directory Access Protocol (DAP) is the method used by the DUA to communicate with the DSA
• Directory System Protocol (DSP) is used for communication between DSA’s
• Directory Management Domain (DMD) contains DSA’s within an organisation
• Directory Management Organization (DMO) is the actual organisation of the DMD
• Directory Information Shadowing Protocol (DISP) is used to replicate information between DSA’s in a DMD
• Directory Operational Binding Management Protocol (DOP) is policies which define the administrative information exchanged between DSA’s

LDAP

X.500 directory access protocol in its actual form involves a lot of overhead we just don’t want to incur to keep a guy, his password, his address, and his phone number all available somewhere.  Lightweight Directory Access Protocol, LDAP, retains the directory structure of X.500 with a simplified TCP/IP based access protocol.  Referrals were simplified and the replication protocol generalized.

The LDAP Technical Specification Roadmap is maintained by the Internet Engineering Task Force, IETF, as RFC 4510 (http://tools.ietf.org/html/rfc4510).  The multiple RFC’s encompassed by LDAP are included in section 1, “The LDAP Technical Specification”.

Directory Components – Schema:

Every directory has a schema set which defines its components.  The schema defines what type of objects exist in the directory and what attributes are valid for those objects.  Schema “attributes” are types of values which can be on an object – anything from an asset ID number to a vendor ID.  Schema “classes” are categories of entries which can be made – and a group of attributes that category means the object can have.  An attribute can be “mandatory” within a class – for example a user account may need a cn value, an objectClass, and an objectCategory.  You cannot make a user account without these values.  The remaining values in a class are “optional” – you may or may not have facsimileTelephoneNumber on your account.

There are three types of classes: abstract, auxiliary, and structural.  Abstract classes are classes which an object cannot directly be – cannot be the object’s objectClass – but are used through subordinate classes to define valid and required attributes..  Auxiliary classes are somewhat like abstract classes in that an object cannot be an auxclass – auxclass’s are instead ‘attached’ to structural classes to create additional valid attributes for the class.  Structural classes are the objectClass “things” you can make within the directory – a user account, a print queue, or even a replication partnership.  The semantics may vary between directory services, but the idea remains.

If you wish to add additional attributes to your objects, you need to extend the directory schema.  I will note here that Novell seems to allow undefined schema extensions.  Normally an organisation is issued an OID number (Object Identifier).  A private enterprise would normally request an OID assignment from IANA (existing assignments are published to http://www.iana.org/assignments/enterprise-numbers) or ANSI.  ANSI’s cost money whereas IANA’s don’t.  Guess which we use!  1.3.6.1.4.1.12704 has been issued to Alltel, 1.3.6.1.4.1.25709 has been issued to Windstream.  Additional decimal number groups past the organisation’s enterprise number can be sub-allocated within the organisation.  .5 within Alltel is used within the AD schema extensions, and 5.1 is specific to the test domain where 5.0 is specific to the production domain.  The breakout an OID number within Alltel’s production AD is:

1                              iso
1.3                            org
1.3.6                          dod
1.3.6.1                        internet
1.3.6.1.4                      private
1.3.6.1.4.1                    enterprise
1.3.6.1.4.1.12794              Alltel
1.3.6.1.4.1.12794.5            Alltel Active Directory
1.3.6.1.4.1.12794.5.0          Production AD
1.3.6.1.4.1.12794.5.0.1.#      Production AD Classes
1.3.6.1.4.1.12794.5.0.2.#      Production AD Attributes

So 1.3.6.1.4.1.12704.5.1.2.7 (cSOBESPolicy) is an attribute within the allteltest.com test domain – the seventh one at that – and 1.3.6.1.4.1.12704.5.0.1.1 (alltelPerson) is a class in the production alltel.com domain (the first and only one).  A different numbering scheme off the “1.3.6.1.4.1.12794” base should be used for other directories.

Once you have created new attributes and appended an aux-class to an existing class, you may (iPlanet, IBM LDAP) need to restart the LDAP service or you may (Active Directory) need to wait for the change to propagate.  Our customized attributes are associated to an aux-class of user called alltelPerson. 

Please do not randomly modify the schema – especially in Active Directory.  In AD you cannot remove the entries.  You can deactivate an attribute but it cannot be deleted.

Directory Components – Structure:

A directory structure will begin at its root – an “O”, organisation name, in iPlanet/NDS/IBM LDAP, or “DC”, domain component, in Active Directory.  OU’s, Organisational Units may be contained under the directory root to provide some organisation to the objects housed within the directory.  You may also see CN’s under the domain root –common name with an objectClass of container.  There may be several layers of OU’s or containers before you find the “leaf” objects – users, contacts, printers, servers, whatever.  The fully qualified LDAP syntax of an object begins at the object and ‘walks’ up the tree – “cn=e0082643,ou=core1,ou=lit,ou=ar,ou=sc,o=alltel” for my ID in the ALLTEL-TREE for example.  “Special” characters are encoded or escaped as required – “cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com”

LDAP Operations

Connections to LDAP are normally made on port 389 for clear text and 636 for encrypted.  Ldap.alltel.com (iplanet), metatreeldap.alltel.com (CSO metatree), litexchldap.alltel.com (active directory ldap), and any NetWare 6.0+ server within the alltel-tree use these standard ports, but alternate ports can be assigned within most directory servers.

Once a connection is made, it may be possible to query the directory.  A limited set of data should be returned as any directory enumeration at this point is done under an anonymous credential.  To specify the user with which you wish to perform directory operations, a BIND must be made.

Search operations include a base and scope (where to begin the search and how deep to traverse the directory under the base), and usually a filter (what to search for) and attributes requested.  Ldapsearch.exe (Win32 available from \\neohtwnlx810.windstream.com\NDSSupport\softlib\misc\ldaputils\) can be used to search an LDAP compliant directory.  Ldapsearch options: -h hostname.alltel.com  -b “ou=search,ou=base,dc=alltel,dc=com” –s “scope” –D “cn=user,ou=location,dc=alltel,dc=com” –W “RFC-2254 compliant filter” attributes to return go here

The search scope can be base (just the object defined as the search base), one (the search base and one level under), or sub (everything subordinate to the search base).  Eg:

ldapsearch -h litexchldap.alltel.com -b “ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com” -s “one” -LLL -D “cn=Landers\, Lisa,ou=GPOTest,ou=IT,ou=ACI,dc=alltel,dc=com” -W “(&(objectClass=user)(mail=*))” displayName mail

The –W option prompts for a password, alternately -w “PasswordGoesHere” can be used.  Once a password has been supplied in this example, the display name and email address for users who have an email address will be returned:

dn: CN=ACI WWC LDS Undeliverables,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: ACI WWC LDS Undeliverables
mail: ACI.WWC.LDS.Undeliverables@alltel.com
 
dn: CN=bob,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: bob
mail: bob@alltel.com
 
dn: CN=Landers\, Lisa,OU=GPOTest,OU=IT,OU=ACI,DC=alltel,DC=com
displayName: Landers, Lisa
mail: Lisa.Landers@alltel.com
 

Additional operations to add objects, delete objects, modify objects, and modify the distinguished name of the object can be done.  More information on this will be provided later.