LDAPviewer will read and parse any LDAP schema file found in the Users/username/AppData/Roaming/LV/schemas/ (Windows) or /home/username/LV/schemas/ (for Linux/BSD) directory with a file suffix of .schema.
LDAPviewer's normal behaviour is to interrogate the LDAP server (if using LDAPv3) and to display (under the Schema tab) the currently connected LDAP server's list of available objects (ldapSyntaxes, objectClasses, attributeTypes and matchingRules) from the collections available in the subSchema entry. These collection are constructed by the LDAP server from its configured schemas.
This behavior has three potential limitations, one of a minor nature and two of a more serious nature.
First, the minor limitation is that it takes time to interrogate the LDAP server and parse the resulting data. When schema files are supplied they are read once when LDAPviewer is loaded and run time parsing is limited to establishing the component name (or OID in the case of LdapSyntaxes).
Second, some LDAP servers limit access to subSchema information meaning this useful information may not always be available (and never in the case of LDAPv2 servers). Adding one or more schema files to the schemas directory by-passes this limitation by providing an alternative source. Note: Access information including credentials may be supplied using the More DITs feature of Connection Profiles.
Third, attributes and objectClasses may be constructed by the user and the resulting schema configured for the LDAP server. These schema filess may be regarded as self documenting (even though many have raised tersness to an art form). However, many objects used or supported by the LDAP server are defined internally and are neither visible in user schemas nor are they available through the various collections maintained in subSchema (and interrogated by LDAPviewer). It may, however, be useful to display enhanced information or interrogate LDAPviewer to discover more about these objects especially as they are used by a particular project or implementation. To cover this case LDAPviewer supports an extended schema format with a file suffix of .schemax.
.schemax files are intended simply to supply information to the LDAPviewer user and for no other purpose. They do not, in any way, affect the operation of the LDAP server or LDAPviewer's processing of results obtained from the LDAP server. The .schemax format and syntax rules are exactly the same as those for .schema files but .schemax files support a number of additional object types and an extended DESC (X-DESC) description field and an X-NOT-CLEAR-TEXT field.
X-NOT-CLEAR-TEXT 'TRUE'Note: The definition of any attributetype in a .schemax file will replace that read by LDAPviewer either from a .schema file or by interrogation of the LDAP server, it is vital for the sake of completeness and accuracy that the standard object (as it appears in a .schema file) is reproduced in its entirety in the .schemax file with X-NOT-CLEAR-TEXT 'TRUE' added.
X-DESC 'extended text or description'This field may be added anywhere to any object type supported by .schema or .schemax files. Thus, if the user wishes to add descriptive material about the precise usage or limitations of an object in a specific DIT, for example, the use of the 'l' ('localityName') attribute, then that definition, in its entirety, would be added to a .schemax file and the additional X-DESC field added as shown below:
# standard definition of the l or locality name attribute in the core.schema file attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) SUP name ) # extended definition as it may appear in a .schemax file with X-DESC added # X-DESC is position idendependent attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) SUP name X-DESC 'town or city of client')Note: The definition of any object in a .schemax file will replace that read by LDAPviewer either from a .schema file or by interrogation of the LDAP server, it is vital for the sake of completeness and accuracy that the standard object (as it appears in a .schema file) is reproduced in its entirety in the .schemax file with X-DESC added.
LdapSyntax ( OID DESC 'text' X-DESC 'extended text' )Note: LdapSyntaxes are uniquely merged with those from the LDAP server since they may contain a number of X- extension fields denoting binary attributes or other special constraints. Standard LdapSyntaxes do not pemrmit a NAME field only a DESC field.
supportedExtension ( OID X-DESC 'textual description' )
supportedFeature ( OID X-DESC 'textual description' )
supportedExtension ( OID X-DESC 'textual description' )
The standard distribution of LDAPviewer includes a single objects.schemax file containing many hidden attributes used by OpenLDAP and textual information about most defined suuportedControl, supportedFeatures and supportedExtensions attributes. This file may be either extended by the user or used as a template for additional user specific .schemax files.
The following shows a snippet from this file:
ldapSyntax ( 1.3.6.1.4.1.1466.115.121.1.4 DESC 'Audio' X-NOT-HUMAN-READABLE 'TRUE' X-DESC 'Unspecified format audio file LDAPviewer supports MP3 only' ) supportedExtension (1.3.6.1.4.1.4203.1.11.1 X-DESC 'Modify Password Extended Control (RFC 3062)') supportedFeature ( 1.3.6.1.1.14 DESC 'Modify-Increment (RFC 4525) Applies to Integer and other numeric LDAP Syntaxes' ) supportedControl ( 1.3.6.1.1.12 X-DESC 'Assertion Control (RFC4528)' ) attributetype( 1.3.6.1.4.1.4203.1.12.2.1 NAME 'configContext' DESC 'config context' X-DESC 'Defines the equivalent to namingContexts for OLC control of OpenLDAP cn=config' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) attributeType ( 1.3.6.1.4.1.4203.666.1.7 NAME 'entryCSN' DESC 'change sequence number of the entry content' EQUALITY CSNMatch ORDERING CSNOrderingMatch SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64} SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
© LV Project 2016. Creative Commons Attribution 4.0 International License.