DirX Directory String Representation for DAP Binds

This chapter describes the DAP-style string representations of simple and structured DirX Directory attributes, search filters and distinguished names. This string representation is used with the administration programs dirxcp for DAP binds and dirxadm to enter and display directory information and, if you are creating new attribute types that extend your directory schema, as the syntax for those new attribute types. (See section Bind Types and Bind IDs of chapter DirX Directory Commands in the DirX Directory Administration Reference for details.)

This chapter provides:

  • A table of reserved characters for attributes

  • An overview of the elements and format of simple and structured attributes

  • An overview of elements and format of distinguished names

  • An overview of elements and format of search filters

  • A description of attribute syntax, including how to override it and how to use defined and undefined abbreviations

  • A description of the string representations of each DirX Directory simple attribute syntax

  • A reference page for each DirX Directory structured attribute that describes its string representation

Reserved Characters

The following table describes reserved characters for simple and structured attributes and distinguished names.

Character Purpose

=

Associates the attribute type and its value(s) or component(s).

‘’

For simple attributes: Indicates the start and end of an attribute value. Used to indicate that white space is part of an attribute value and should not be ignored. (By default, white space is ignored.) For example: ).

CN=‘Henry Mueller’

Curly braces ({}) perform the same function.

{}

For structured attributes: Indicates the start and end of a structured attribute component.

For simple attributes and distinguished names: Encloses the entire attribute (type and value) or distinguished name to indicate that white space is part of an attribute value. For example,
{CN=Henry Mueller} or {/O=My-Company}

Single quotes (‘’) perform the same function.

,

For structured attributes: Separates components.

For distinguished names: Separates multiple naming attribute value assertions (multiple AVAs).

;

For simple and structured attributes: Separates multiple values.

/

For distinguished names: Separates RDNs in distinguished name syntax.

\xnn

Specifies hexadecimal data where nn represents the hexadecimal characters. For example:
\xab\xff\xcd

\

Escapes a reserved character.

Simple and Structured Attributes

Simple attributes are in the form:

type=simple_value[;simple_value …​ ]

Structured attributes are in the form:

type=structured_value[;structured_value …​ ]

Each of the elements in simple and structured attributes is described in the following sections.

Attribute Types

For both simple and structured attributes, the type parameter identifies the attribute.

Internally attribute types are identified by OID (object identifiers), a unique series of integers separated by the period (.) character. For example, 2.5.4.3 is the OID for the Common-Name attribute type. You can identify attributes by OID, but to make it easier to specify attributes, the dirxadm and dirxcp commands allow you to identify them by attribute type abbreviations in command lines.

An abbreviation is an abbreviation of the attribute name. Abbreviations are specified in the DirX Directory abbreviation files. For example, the abbreviation C represents the Country attribute type, the abbreviation CN represents the Common-Name attribute type. Abbreviations are case-insensitive; for example, cn, Cn, and CN are all valid ways to specify the abbreviation for the Common-Name attribute type. When you display attributes, dirxcp and dirxadm use attribute type abbreviations by default. Use the -pretty option to display attribute names.

To display an attribute’s name, type abbreviations and OID, either use the dirxadm and dirxcp abbr show commands or list the contents of the abbreviation files, which contains them.

Simple Attribute Values

For simple attributes, the simple_value parameter is the value assigned to the attribute. simple_value can be only a simple value, not another attribute. To enter more than one simple_value, separate each with a semicolon as shown in the following example:

  • {TN=+1 964 123 456}
    {2.5.4.20=+1 964 123 456}
    {TN=+1 964 123 456;+1 965 234 543}

Structured Attribute Values

For structured attributes, the structured_value parameter is the value assigned to the attribute. structured value is a comma-separated sequence of component type/value pairs. In other words, structured_value has the form:

structured_value={comp_type=comp_value[,comp_type=comp_value]…​}

comp_value can either be a simple or a structured value. To enter more than one structured_value, separate each with a semicolon (;).

Some sample structured attributes follow:

  • FTN={PN=63875}
    2.5.4.23={PN=63875};{PN=12345}
    PACI={ID=Admin-ACI,PR=10,AL={BL={L=SIMPLE}}}

Component types (comp_type) can only be specified with their abbreviations. They do not have OIDs assigned.

Attribute Lists for Simple and Structured Attributes

Most dirxadm and dirxcp operations allow you to specify more than one simple or structured attribute on the command line. To specify more than one attribute, separate each attribute type and value string with white space. The following -attribute option specifies an OCL, DSC and TN simple attributes, all separated by a space. Note that the DSC and TN attributes are enclosed in braces ({ }) because they contain white space for readability.

  • -attribute OCL=OU {DSC=Engineering Department} {TN=+1 964 123 4567}

Attribute Values in a File

Single attribute values can also be specified in a file or written to a file. The syntax is as follows:

attribute[_ANY]_FILE=filename

where attribute specifies the attribute type and filename the name of the file containing the attribute value.

If the keyword _ANY is specified, the value file contains the valid ASN.1 encoded value of the attribute regardless of the syntax for the attribute that is defined in the directory schema. If _ANY is not used, the attribute syntax OCTET STRING is assumed, and the value file contains the binary representation of the attribute value. In this case, an error is returned if the syntax for the attribute specified in the schema is not OCTET STRING.

Multiple attribute values cannot be specified in a file.

Specifying the attribute value in a file is possible for the following dirxcp operations:

  • obj create (-attribute option)

  • obj modify (-addattr, -changeattr, -removeattr options)

  • obj compare (-attribute option)

  • obj show (-attribute option)

Examples:

  1. The following example adds a picture to the JPT attribute. The file "/tmp/john.jpg" contains the binary representation of the picture.

    modify /O=my-company/OU=sales/CN=Huber \
       -addattr JPT_FILE=/tmp/john.jpg

  2. Compare the JPT attribute. The file "pict_value.jpg" contains the value of the JPT attribute in binary representation.

    compare /O=my-company/OU=asw/CN=zapf \
        -attr JPT_FILE=pict_value.jpg

  3. Modify the value of the JPT attribute. The file "pict_old.jpg" contains the old value and the file "pict_new.jpg" contains the new value.

    modify /O=my-company/OU=sales/CN=Mayer \
       - changeattr JPT_FILE=pict_old.jpg JPT_FILE=pict_new.jpg

  4. Create an entry. The file "cert.cer" contains the ASN.1 encoded value of the user certificate attribute.

    create /O=my-company/OU=sales/CN=Huber -attr {OCL=per;orp;sau} \
       SN=Huber UC_ANY_FILE=cert.cer

  5. Show an entry. The ASN.1 encoded value of the user certificate attribute is written to the file "huber_certificate.cer".

    show /O=my-company/OU=sales/CN=Huber \
     -attr UC_ANY_FILE=huber_certificate.cer

Base-64 Encoded Attribute Values

Single attribute values can also be specified Base-64 encoded or be read Base-64 encoded. The syntax is as follows:

attribute[_ANY]_B64[=´attribute_value´]

where attribute specifies the attribute type and attribute_value specifies the Base-64 encoded attribute value when creating or modifying this value.

If the keyword _ANY is specified, the value contains the valid ASN.1 encoded value of the attribute regardless of the syntax for the attribute defined in the directory schema. If _ANY is not used, the syntax of the attribute according to the schema is assumed, and the value contains the Base 64-encoded representation of the attribute value.

Structured attributes can only be specified with the keyword _ANY. Otherwise an error is returned.

When the syntax of the attribute is not OCTET STRING null bytes in the value are not allowed.

Base-64 encoded attribute values must be enclosed in single quotes (´attribute value´).

Specifying the attribute value Base-64 encoded is possible for the following dirxcp operations:

  • obj create (-attribute option)

  • obj modify (-addattr, -changeattr, -removeattr options)

  • obj compare (-attribute option)

  • obj search (-attribute option)

  • obj show (-attribute option)

Examples:

The following example displays the Street Address attribute (STA) of the person
/o=My-Company/ou=Development/cn=Digger Base-64 encoded:

show {/o=my-company/ou=Development/cn=Digger} -attr sta_b64 -p

The output of the sample command as follows:

1) /O=My-Company/OU=Development/CN=Digger
   Street-Address : 'MjQgRG91Z2FuIFN0cmVldA=='

Distinguished Names

A distinguished name consists of a list of one or more relative distinguished names (RDNs), each beginning with a forward slash (/).The list of relative distinguished names starts from the root entry.For example:

  • /O=my-company/OU=dap11/CN=schmid, OU=ap11

Each RDN consists of one or more naming attributes in the following format:

type=value[, type=value]…​

where type is an abbreviation or an OID that corresponds to a naming attribute type and value is the string representation that corresponds to the attribute syntax assigned to the attribute type. For example:

  • c=de

or

  • 2.5.6.2=de

or

  • OU=dap11, L=munich

The maximum length of an ASN.1 encoded RDN is 470 bytes.The value length of the naming attribute is affected by

  • the length of the object identifier

  • the number of 2-byte UTF8 characters contained in the attribute value

  • the number of attribute value assertions (AVAs) the RDN consists of.

Search Filters

Use search filter expressions to specify a filter in a dirxcp search operation.A search filter is composed of one or more simple attributes, structured attributes, or distinguished name strings separated by search filter operators.The following virtual attributes must not be used in search filters:

  • numSubordinates

  • numAllSubordinates

  • structuralObjectClass

If the listed virtual attributes are used, an Unwilling to Perform error will be returned.

Recall from section Tcl Command Language in chapter DirX Directory Commands that you must enclose the filter expression in curly brackets ({}) or quotation marks ("") if attribute values contain a space character.

The operators in the following table can be used in search filter expressions.

Operator Meaning

&&

To “logically AND” two specified conditions

||

To “logically OR” two specified conditions

!

To “logically NEGATE” a specified condition

=

To specify equality

~=

To specify phonetic matching

>

To match values that are greater than or equal to a specified value

>=

To match values that are greater than or equal to a specified value

<

To match values that are less than or equal to a specified value

<=

To match values that are less than or equal to a specified value

*

To specify substrings

( )

To nest search filter expressions

White space in a search filter string expression is ignored.

Search Filter Expression Example

The following sample search filter string

  • (cn~=schmid)&&(ocl=orp||ocl=rep)&&!(sn=ronnie)

directs dirxcp to search for names that meet all the following criteria:

  • Have an object class attribute value of Organizational-Person or Residential-Person

  • Have a Common-Name attribute value that approximately matches schmid

  • Do not have a Surname attribute value of ronnie.

The following search filter string test for the presence of the Common-Name attribute type:

  • (c=de)&&(cn)

Search Operator Order of Precedence

Search filter operators have the following precedence when combined in expressions within a search filter string:

  1. The filter nesting operators () are evaluated first.

  2. The “logical NEGATE” operator is evaluated next.

  3. The “logical AND” operators are evaluated next.

  4. The “logical OR” operator is evaluated last.

Search Filter Expressions and Reserved Characters

You can use any of the reserved characters (described in section Reserved Characters above in this chapter) in a search filter string. For example, use the quote characters to enclose an attribute that uses white space as data within a search filter string:

  • {ou=sni && cn='Henri Mueller' && tn=89989}

The filter expression is enclosed in curly brackets because the cn attribute value contains the space character.

Search Filter Expressions and Matching Rules

Some structured attributes have special matching rules that require that they must be specified with special syntax when they are used in filters. For example, the structured attribute type Protocol-Information is normally specified as follows:

PI={NA=network_address, PRO=profiles}

However, because it has special matching rules, this attribute must be specified as an octet string without the components when used in a search filter string:

PI_OCT=octet_string

For each attribute type default matching rules are defined, for example a matching rule for equality matching, a matching rule for substring matching, etc.

The extensible match filter condition allows to specify a different matching rule than the default one. It also allows to extend the search on the attributes in the distinguished name that are not stored as attributes in an entry itself. The syntax of the extensible match filter condition is specified as follows:

EM={MR=matching_rule [, AT=attribute_type], MV=matching_value, DNA=boolean}

The MR=matching_rule component and the AT=attribute_type component can be specified either as object identifiers or as abbreviations. The MV=matching_value component specifies the searched attribute value. The DNA=boolean component can have the value 1, TRUE, 0, or FALSE. The value 1 or TRUE indicates that the attributes of the distinguished name of the entry are to be used in addition to those of the entry in evaluating the match.

The following filter tests for the presence of the Organizational Unit attribute with value Sales, using the matching rule Case-Ignore-Match, also evaluating the attributes of the distinguished name:

  • EM={AT=OU, MV=Sales, DNA=TRUE, MR=CIM}

To search for entries where the Organizational Unit attribute has a value starting with S specify the extensible match filter condition as follows:

  • EM={AT=OU, MV=S, DNA=TRUE, MR=CISM}

Attribute Syntax

Both simple and structured attributes are assigned default attribute syntaxes that determine the form in which you must supply the attribute values and the allowed character set.For example, the Common-Name simple attribute has as its default syntax Directory-String, which means the value must be a string of the first 256 Latin-1 characters of the Latin-1 (ISO 8859-1) character set.If you supply this attribute to the dirxadm or dirxcp commands, you must supply its value in the Latin-1 character set.Note that for the Directory-String syntax and a number of other syntaxes you can also supply strings of T61 characters as values.This is described in Chapter 1 in the dirxcp and dirxadm reference pages.

Attribute syntaxes are identified by name or abbreviation.For example, the abbreviation DST represents the Directory-String simple attribute syntax, and the abbreviation ACIITEM represents the Access-Control-Information-Item structured attribute syntax.

To see the names of attribute syntaxes, use the dirxadm and dirxcp abbr show commands or list the contents of the abbreviation files.

Overriding Default Attribute Syntax

The abbreviation files define the default syntax associated with each attribute type.When you specify an attribute, the dirxcp and dirxadm programs consult the abbreviation files to determine the attribute’s legal formats and its character encoding methods.

You can override the default attribute syntax by appending an underscore and the attribute syntax abbreviation to the specified attribute type, as follows:

attribute-type_attribute-syntax-abbreviation

where attribute-type specifies the attribute type and attribute-syntax-abbreviation is the attribute syntax abbreviation (which can be found by examining the abbreviation files).

For example, the attribute type CN has an attribute syntax of Directory-String. To encode the attribute type/value association CN=naik with a Printable-String syntax, append the abbreviation _PRI for printable string, as shown below:

  • CN_PRI=naik

This causes the value to use Printable-String syntax instead of Directory-String.

If you use an attribute syntax abbreviation to override an attribute’s default syntax, the dirxcp and dirxadm show and search operations return the attribute type and selected attribute syntax abbreviation to indicate that it is different from the default. For example, if you specify cn_pri=naik, the programs return cn_pri=naik in their output.

If the default syntax is overridden with the syntax ANY, the ASN.1 decoding is suppressed. This may be useful to write an ASN.1 encoded value of an attribute to a file. (See chapter titled Attribute Values in a File for details). Note that the dirxcp and dirxadm commands are not able to display ASN.1 encoded values.

Syntax Abbreviations

The following is a list of attribute syntax abbreviations which can be used to override default attribute syntaxes. Attribute syntax abbreviations are case-insensitive.

Syntax Abbreviation

ANY

ANY

ATTR_TYPE

ATT

BIT_STR

BIT

BMP_STR

BMP

BOOLEAN

BOO

DIR_STR

DSTR

DIR_STR_T61

DT61
(Note that the default is BMP.)

DIR_STR_PRI

DPRI

DIR_STR_BMP

DBMP

DIR_STR_UNI

DUNI

GENERALIZED_TIME

GET

IA5_STR

IA5

INTEGER

INT

NUMERIC_STR

NUM

OBJECT_ID

OID

OCTET_STR

OCT

PRINTABLE_STR

PRI

TTX_STR

TTX

T61_STR

T61

UNIVERSAL_STR

UNI

UTC_TIME

UTC

Undefined Types and Abbreviations

To specify an attribute type that has not been defined in an abbreviation file, use the attribute type OID and append to it the abbreviation of the attribute syntax, for example, 1.2.325.67890.4.2_PRI.

In the output, the dirxcp and dirxadm programs return a string in the form:

oid_attribute-syntax-abbreviation=attribute_value

For example:

1.2.325.67890.4.2_PRI=xyz

which indicates that the attribute with the object identifier 1.2.325.67890.4.2 and the attribute syntax Printable-String has a value of xyz, which is to be encoded as a printable string.

Attribute Syntax and Equality Matching Rule Syntax

In some instances an attribute’s Equality-Matching Rule syntax differs from its attribute syntax. These attributes, their abbreviations, attribute syntax and Equality Matching Rule syntax are listed in the following table.

Abbr. Attribute-Name Attribute Syntax Equality-Match-Rule

AT

Attribute-Type

ATTR_TYPE_DESC

ATTR_TYPE

CDSA

Cooperating-DSA

COOPERATING_DSA

DN

CK

Consumer-Knowledge

CONS_INFO

SUPPL_OR_CONS_INFO_MATCH_SET

DCR

DIT-Content-Rules

DITCONTENT_RULE_DESCR

OBJECT_ID

DSAP

DSA-Policy

DSA_POLICIES

DN

DSR

DIT-Structure-Rules

DITSTRUCT_RULE_DESCR

INTEGER

EACI

Entry-ACI

ACIITEM

DIR_STR

MAC

My-Access-Point

ACC_POINT

DN

MR

Matching-Rules

MRULE_DESCR

OBJECT_ID

MRU

Matching-Rule-Use

MRULE_USE_DESCR

OBJECT_ID

NF

Name-Forms

NAME_FORM_DESCR

OBJECT_ID

NSK

Non-Specific-Knowledge

MASTER_AND_SHAD_ACC_POINTS

MASTER_AND_SHAD_ACC_POINTS_MATCH

OC

Object-Classes

OBJECT_CLASS_DESCR

OBJECT_ID

PACI

Prescriptive-ACI

ACIITEM

DIR_STR

PI

Protocol-Information

PROTO_INFO

OCTET_STR

SACI

Subentry-ACI

ACIITEM

DIR_STR

SES

Secondary-Shadows

SUPPL_AND_CONSS

DN

SK

Specific-Knowledge

MASTER_AND_SHAD_ACC_POINTS

MASTER_AND_SHAD_ACC_POINTS_MATCH

SPK

Superior-Knowledge

ACC_POINT

DN

SUK

Supplier-Knowledge

SUPPL_INFO

SUPPL_OR_CONS_INFO_MATCH_SET

USP

User-Policy

USR_POLICIES

DN

Attribute Syntax vs. Equality Matching Rule Syntax

For those attributes for which the Equality Matching Rule syntax differs from the attribute syntax, you must specify the attribute to dirxcp and dirxadm according to the following conditions

  • Use the attribute syntax with the:

    -attribute option for create operations

    -addattr option for modify operations

    -changeattr option for modify operations (but only for the new attribute value)

  • Use the Equality Matching Rule syntax in the:

    -filter option for search operations, if EQUALITY matching has been chosen

    -removeattr option for modify operations, if an attribute with it’s value has been entered (e.g., TN=41098)

    -changeattr option for modify operations (but only for the OLD attribute value)

    -attribute option for compare operations

Each of the attributes for which the syntaxes differ is described in the following table.

Syntax Notes

Attribute-Syntax:
ATTR_TYPE_DESC
Equality Matching Syntax: ATTR_TYPE

The Equality Matching-Rule is objectIdentifierFirstComponentMatch, which means that only the component ID of the ATTR_TYPE_DESCR should match. Enter the attribute as: AT=CN or AT=2.5.4.3. This Equality Matching Rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
COOPERATING_DSA
Equality Matching Syntax:
DN

The Equality Matching-Rule is DistinguishedNameFirstComponentMatch, which means that only the component DSA of the COOPERATING_DSA should match. Enter the attribute as: CDSA={/O=my-company/OU=asw/CN=dsa/CN=asw-dsa}. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
CONS_INFO
Equality Matching Syntax: SUPPL_OR_CONS_INFO_MATCH_SET

The Equality-Matching-Rule is that the component AE of the Access-Point subcomponent CON of the CONS_INFO and additionally the component AGR should match. Enter the attribute as CK={AE={/O=my-company/OU=asw/CN=dsa/CN=asw-dsa}, AGR=10.

Attribute-Syntax: DITCONTENT_RULE_DESCR
Equality-Matching-Syntax:
OBJECT_ID

The Equality-Matching-Rule is objectIdentifierFirstComponentMatch, which means that only the component SOC of the DITCONTENT_RULE_DESCR should match. Enter the attribute as DCR=ORP or DCR=2.5.6.7. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
DSA_POLICIES
Equality-Matching-Syntax:
DN

The Equality-Matching-Rule is DistinguishedNameFirstComponentMatch, which means that only the component DSA of the DSA_POLICIES should match. Enter the attribute as DSAP={/O=my-company/OU=asw/CN=dsa/CN=asw-dsa}. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax: DITSTRUCT_RULE_DESCR
Equality-Matching-Syntax:
INTEGER

The Equality-Matching-Rule is integerFirstComponentMatch, which means that only the component ID of the DITSTRUCT_RULE_DESCR should match. Enter the attribute as DSR=7. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
ACIITEM
Equality-Matching-Syntax:
DIR_STR

The Equality-Matching-Rule is directoryStringFirstComponentMatch, which means that only the component ID of the ACIITEM should match. Enter the attribute as PACI=Administrator-ACI. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
ACC_POINT
Equality-Matching-Syntax:
DN

The Equality-Matching-Rule is that the component AE of the ACC_POINT should match. Enter the attribute as MAC={/O=my-company/OU=asw/CN=dsa/CN=dsa1}. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
MRULE_DESCR
Equality-Matching-Syntax:
OBJECT_ID

The Equality-Matching-Rule is objectIdentifierFirstComponentMatch, which means that only the component ID of the MRULE_DESCR should match. Enter the attribute as MR=CEM or MR=2.5.13.5. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
MRULE_USE_DESCR
Equality-Matching-Syntax:
OBJECT_ID

The Equality-Matching-Rule is objectIdentifierFirstComponentMatch, which means that only the component ID of the MRULE_USE_DESCR should match. Enter the attribute as MRU=CEM or MRU=2.5.13.5. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax: NAME_FORM_DESCR
Equality-Matching-Syntax:
OBJECT_ID

The Equality-Matching-Rule is objectIdentifierFirstComponentMatch,which means that only the component ID of the NAME_FORM_DESCR should match. Enter the attribute as NF=LNF or NF=2.5.15.1. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax: MASTER_AND_SHAD_ACC_POINTS
Equality-Matching-Syntax: MASTER_AND_SHAD_ACC_POINTS_MATCH

The Equality-Matching-Rule is that the component AE of all Access-Points should match. Enter the attribute as NSK={AE={/O=my-company/OU=asw/CN=dsa/CN=dsa1};
{/O=my-company/OU=asw/CN=dsa/CN=dsa2}}

Attribute-Syntax: OBJECT_CLASS_DESCR
Equality-Matching-Syntax:
OBJECT_ID

The Equality-Matching-Rule is objectIdentifierFirstComponentMatch, which means that only the component ID of the OBJECT_CLASS_DESCR should match. Enter the attribute as OC=ORP or OC=2.5.6.7. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
PROTO_INFO
Equality-Matching-Syntax: OCTET_STR

The Equality-Matching-Rule is that the component NA of the PROTO_INFO should match. Enter the attribute as PI=\x0a\x0b. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
SUPPL_AND_CONSS
Equality-Matching-Syntax:
DN

The Equality-Matching-Rule is that the component AE of the Access-Point subcomponent SUP of the SUPPL_AND_CONSS should match. Enter the attribute as SES={/O=my-company/OU=asw}. This matching rule is a simple one and only requires the attribute value without any component name.

Attribute-Syntax:
USR_POLICIES
Equality-Matching-Syntax:
DN

The Equality-Matching-Rule is DistinguishedNameFirstComponentMatch, which means that only the component USN of the USR_POLICIES should match. Enter the attribute as USP={/O=my-company/OU=asw}. This matching rule is a simple one and only requires the attribute value without any component name.

String Representations for Simple Attribute Syntaxes

The following section describes the string representations for simple attribute syntaxes.

Attribute Type Syntax

Specify an attribute type as an abbreviation (defined in the Attribute Definition Block in an abbreviation file) or the attribute type’s object identifier (OID) in dotted notation (for example, 1.2.5.6).

Bit String Syntax

Specify a bit string as a sequence of 1’s and 0’s (for example, 11110100100001001101101).

Boolean Syntax

Specify a boolean as the integer 1 (true) or 0 (false) or the keyword TRUE or FALSE.

Country Name Syntax

Specify a country name as a two-letter code according to the definitions in ISO 3166. Appendix A lists the countries and their two-letter name codes.

Destination Indicator Syntax

Specify the country and city needed to provide the public telegram service according to CCITT Rec. F.1 and Rec. F.31 It is a printable string (alphabetical characters only) of maximum length 128.

Directory String Syntax

Specify a directory string using any of the following four syntaxes.

  • T61 String Syntax - If the Tcl variable _t61 is set to TRUE, you must use the T.61 character set for the directory string (for example, R\xF9m\xF9, which has the Latin-1 representation Rømø). If the Tcl variable _t61 is set to FALSE, you must use the BMP string syntax. See the description of BMP string syntax below in this section.

  • Printable Syntax - Specify the directory string as a sequence of characters. Valid characters are A to Z, a to z, 0 to 9, the space character, and the special characters: ’ (apostrophe), ( (left parentheses), ) (right parentheses), + (plus sign), , (comma), - (hyphen), . (period), / (slash), : (colon), = (equal sign), and ? (question mark) (for example, South Africa).

  • BMP String Syntax - Specify the directory string as a BMP string. A BMP (Basic Multilingual Plane) string is the internal representation of strings used by X.500 protocols and DSAs. Specify a BMP string depending on the value of the TCL variables _t61 and _localcode. (See section TCL Variables in the DirX Directory Administration Reference for details.) When _t61=TRUE T61 format is used as described above (for example, Locality_T61=”M\xc8unchen”, T61 format of the value München). _t61=FALSE species a range of Latin-1 (ISO 8859-1) characters, with Hex values ranging from 20 to 7E and A0 to FF (for example, Locality_BMP=”M\xfcnchen”, Latin-1 format of the value München). (See also ISO 10646 Part 1: Architecture and Basic Multilingual Plane.)

  • Universal String Syntax - Specify the directory string using BMP string syntax. See the description of BMP string syntax above in this section.

  • UTF-8 String Syntax - Specify the directory string using UTF-8 string syntax. A UTF-8 string is a transformation format of the Universal Character Set (UCS) as defined in ISO 10646. See RFC 2279 for details.

DSE Type Syntax

DSE Type syntax is a bit string syntax that represents the role that the DSE plays in regard to the entry and its distribution. Note that DSEs can have multiple DSE types. For example, a DSE representing a subordinate reference can also represent a shadowed context prefix that is an administrative point. However, some combinations of DSE types are meaningless.) (Every DSE in a DSA has a DSA-specific attribute of this syntax; the attribute is accessible using dirxadm only.)

Specify DSE type syntax in the following format:

DSE_TYPE = DSE_Type_combination

where:

dse_type

Is the abbreviation or OID that corresponds to an attribute with the DSE Type syntax. (The DSET attribute is the sole example of such an attribute. The DSET attribute is not part of a normal Directory entry, visible using the Directory service. Instead it is an attribute of the DSE (DSA Specific Entry) that represents aspects of entries in particular DSAs.)

DSE_Type_combination

Is a list of one or more keywords separated by the + (plus sign) that define the role or roles of the DSE. The possible keywords are:

  • ROOT - Used exclusively by the DSE that represents the root of the DIT in a particular DSA.

  • GLUE - A DSE that represents a name only. A DSA uses glue DSEs to hold the names of the superiors of the context prefixes and cross references where there is no other knowledge associated with them. You cannot assign any other DSE types to a DSE typed as GLUE.

  • CP - A DSE that represents the context prefix of a naming context.

  • ENTRY - A DSE that represents the entry itself, normally including the user attributes. If the SHADOW bit is not set, the DSE represents the master copy of the entry and holds all the attributes associated with the entry.

  • ALIAS - A DSE that represents an alias entry.

  • SUBR - A DSE that represents a specific subordinate reference and holds a corresponding knowledge attribute.

  • NSSR - A DSE that represents a non-specific subordinate reference, and holds a corresponding knowledge attribute.

  • SUPR - Used to mark a root DSE that holds a knowledge attribute that represents a specific superior reference. (See the ROOT keyword.)

  • XR - A DSE that represents a cross-reference, and holds a corresponding knowledge attribute.

  • ADM_POINT - A DSE that represents an administrative point.

  • SUBENTRY - A DSE that represents a subentry.

  • SHADOW - A DSE that represents shadowed information.

  • IMM_SUPR - A DSE that represents an immediate superior reference and holds a corresponding knowledge attribute.

  • RHOB - A DSE that holds policy information (either administrative point or subentry information), which has been received from a superior DSA as the result of a hierarchical operational binding.

  • SA - An additional characteristic of a subordinate reference DSE (i.e., of type SUBR), which is used to indicate that the context prefix pointed to by the reference is an alias and not a normal entry.

The following lists the most commonly used types and combinations in the absence of shadowing:

  • ROOT+SUPR

  • GLUE (must be used alone)

  • ENTRY +CP+ADM_POINT

  • ALIAS +CP

  • SUBENTRY (used alone)

  • IMM_SUPR (used alone)

An example of an attribute in DSE Type syntax follows:

  • DSET=ENTRY+ADM_POINT

  • DSET=GLUE

Generalized Time Syntax

Specify generalized time as a simple string. The value of the string is the concatenation of the 8 year-month-day digits (YYYYMMDD), plus the six hour-minute-second digits (HHMMSS), plus a time zone difference of Z (designating GMT), +HHMM, or -HHMM. The three possible forms, then, are:

  • YYYYMMDDHHMMSSZ

  • YYYYMMDDHHMMSS+HHMM

  • YYYYMMDDHHMMSS-HHMM

For example, 19970101123000Z specifies Jan 1, 1997, 12:30:00 GMT.

The only difference between generalized time and UTC time is that the year is specified with four digits instead of two.

IA5 String Syntax

Specify an IA5 string using 7-bit ASCII characters, with valid Hex values in the range 20 to 7E (for example, smith@my-company.de).

Integer String Syntax

Specify as an integer in the range 0 to 2**32 -1 (4,294,967,295). For example, 65535.

International ISDN Number Syntax

Specify as a numeric string (see Numeric String Syntax) of maximum length 16 which complies with the internationally agreed format for ISDN addresses given in CCITT Rec. E.164.

ISO646 String Syntax

Specify an ISO 646 string using 7-bit ASCII characters, with valid Hex values in the range 20 to 7E (for example, Washington D.C.).

Local Scope Policy Syntax

Local Scope Policy syntax is used for DSA configuration attributes that specify the interpretation of the local-scope service control.

Specify Local Scope Policy syntax in the following format:

LocalScopePolicy=DSA | LOCAL-DOMAIN | DMD

where:

LocalScopePolicy

Is an abbreviation or OID that corresponds to an attribute with the Local Scope Policy syntax. (The local-scope-policy (LSP) attribute, which specifies the interpretation of the local-scope service control, is an example of such an attribute. It is a single-valued attribute of the root DSE, and is accessible using dirxadm only.)

LSP=local_scope_interpretation

Defines the local scope for the DSA. local_scope_interpretation takes one of the following values:

  • DSA - The local scope is the scope of the DSA. The DSA responds on the basis of information that it holds itself, and does not chain or create referrals or continuation references

  • LOCAL-DOMAIN - The local scope is the scope of the local domain of the DSA. The DSA chains or creates referrals or continuation references only to the group of DSAs in the local domain. A DSA belongs to the same local domain as the local DSA if a DSA policy exists for this DSA with the value OPT=LOCAL-DOMAIN

  • DMD - The local scope is the scope of the Directory Management Domain (DMD) of the DSA. The DSA will chain or create referrals or continuation references only within the group of DSAs configured within the DMD. A DSA belongs to the same DMD as the local DSA if a DSA policy exists for this DSA with the value OPT=DMD

The default value is DSA.

An example of a Local Scope Policy Attribute follows:

LSP=DMD

Numeric String Syntax

Specify as a sequence of digits (0 to 9) and space (for example, 4711 13).

Object ID Syntax

Specify an OID as an abbreviation (defined in the OID Definition Block in an abbreviation file) or a dotted notation. For example, Organizational-Person could be specified as ORP or 2.5.6.7.

Octet String Syntax

Specify an octet string using single-byte Hex values (00 to FF) or their Latin-1 character representation (for example \x01\x02ABC).

Preferred Delivery Method Syntax

Preferred-delivery-method syntax is a syntax for single-valued attributes that document the order of preference for message delivery methods. Specify this syntax in the following format:

preferredDeliveryMethod=option [+option…​]

option is one or more of the following keywords that describe the delivery methods and the order of preference:

  • ANY - Any method of delivery

  • MHS - Message handling system delivery

  • PHYSICAL - Physical delivery

  • TELEX - Telex delivery

  • TELETEX - Teletex delivery

  • G3_FAX - G3 FAX delivery

  • G4_FAX - G4 FAX delivery

  • IA5 - IA5 terminal delivery

  • VIDEOTEX - Videotex delivery

  • TELEPHONE - Telephone delivery

The keywords are specified diminishing order of preference, with the most preferred method first in the list. Separate multiple keywords with a plus sign (+). For example:

PDM=MHS+TELETEX+TELEPHONE

Printable String Syntax

Specify a printable string as a sequence of characters. Valid characters are

  • A to Z,
    a to z,
    0 to 9,
    the space character,

and the special characters:

  • ’ (apostrophe),
    ( (left parentheses),
    ) (right parentheses),
    + (plus sign),
    , (comma),
    - (hyphen),
    . (period),
    / (slash),
    : (colon),
    = (equal sign),
    ? (question mark).

An example of Printable String Syntax follows:

Smith/My-Company.

SDSE Type Syntax

Specify a SDSE (shadow DSE) type the same as a DSE type (described earlier in this section).

TTX String Syntax

Specify a Teletex (TTX) string the same as a directory T61 string (described earlier in this section).

Unique Identifier Syntax

Specify a unique identifier the same as a bit string. See the description of bit string syntax earlier in this section.

Universal String Syntax

Specify a universal string the same as a BMP string. See the description of BMP string syntax in the Directory String Syntax section of this chapter.

UTC Time Syntax

Specify UTC time as a simple string. The value of the string is the concatenation of the six year-month-day digits (YYMMDD), plus the six hour-minute-second digits (HHMMSS), plus a time zone difference of Z (designating GMT), +HHMM, or -HHMM. The three possible forms, then, are:

  • YYMMDDHHMMSSZ

  • YYMMDDHHMMSS+HHMM

  • YYMMDDHHMMSS-HHMM

For example, 970101123000Z specifies Jan 1, 1997, 12:30:00 GMT.

X121 Address Syntax

Specify as a numeric string (see Numeric String Syntax) of maximum length 15 which complies with an address as defined by CCITT Rec.X.121 associated with an object.

String Representations for Structured Attribute Syntaxes

This section describes the following structured attribute syntaxes supported by DirX Directory.

  • Syntaxes for knowledge attribute types

    • Access-Point

    • Consumer-Information

    • Master-And-Shadow-Access-Points

    • Supplier-Information

    • Suppliers-And-Consumers

  • Syntaxes for certificate attribute types and certificate subcomponents

    • Certificate (Signed)

    • Certificate (Unsigned)

    • Certificate Pair

    • Cert-List (Signed)

    • Cert-List (Unsigned)

  • Syntaxes for operational attribute types and subcomponents

    • ACI-Item

    • Cooperating-DSA

    • DSA-Policies

    • Paging-Policies

    • Shadowing-Agreement-Info

    • SOB-Policies

    • Update-Status

    • User-Policies

  • Syntaxes for miscellaneous attribute types and subcomponents

    • Continuation-Reference

    • Facsimile-Telephone-Number

    • Name-And-Optional-UID

    • Partial-Outcome-Qualifier

    • Postal-Address

    • Presentation-Address

    • Protocol-Information

    • Subtree-Specification

    • Teletex-Terminal-Identifier

    • Telex-Number

Access-Point

An attribute syntax for knowledge attributes that specify DSA access points (that is, the names and addresses of DSAs that can interact with the holding DSA using a Directory protocol).

Synopsis

AccessPoint = {AE=application_entity_title,
    PSAP=presentation_address
    [,PRINFO=protocol_info]
    [,DISP-KIND=disp_kind]}

Attribute Type

AccessPoint

The abbreviation or OID that corresponds to a structured attribute with the Access-Point (ACC_POINT) syntax. SPK (Superior Knowledge) is an example of such an attribute.

Components

AE=application_entity_title

The distinguished name of the DSA.

PSAP=presentation_address

The presentation address of the DSA. Specify presentation_address as a Presentation-Address attribute. (See Presentation-Address for details.)

PRINFO=protocol_info

A structured component with the Protocol-Information syntax. See Protocol-Information in this chapter for a complete description of protocol information format. If it is specified, its NSAP address component must correspond to one of the NSAP addresses given in the presentation address

The PRINFO component is not required for TCP/IP communications; it can be omitted.
DISP-KIND=disp_kind

Whether the DSA participates in the central cooperating DSA table administration (CENTRALADMIN) or supports only X.500 compliant shadowing (X500).

This value is specified when creating a shadowing agreement. (See the sob create operation in the DirX Directory Administration Reference for details.) Perform a sob show operation to display the value.

Description

The Access-Point specifies distinguished names and addresses of DSAs that can interact with the holding DSA using a Directory protocol. The DSA uses, for example, the SPK (Superior Knowledge) attribute information when constructing a continuation reference returned in a DAP or DSP referral or when performing chaining.

Example

SPK={AE={/O=My-Company/CN=dsa},
PSAP={TS=Server19,NA='TCP/IP!internet=136.30.74.3+port=102'}}

Consumer-Information

An attribute syntax for DSA-specific attributes of context prefixes. The Consumer Knowledge attribute (CK) is the only such attribute in the default DSA schema. It describes consumer DSAs that shadow all or part of the corresponding naming context. It specifies the access points of each DSA together with the numeric identifier for the corresponding operational binding.

Synopsis

ConsumerInformation = {CON=access_point_of_consumer,
AGR=operational_binding_ID}

Attribute Type

ConsumerInformation

The abbreviation or OID that corresponds to a structured attribute with the Consumer-Information (CONS_INFO) syntax. CK (Consumer Knowledge) is such an attribute. The CK attribute is an attribute of the context prefixes of shadowed naming contexts in supplier DSAs, and is accessible with dirxadm only.

Components

CON=access_point_of_consumer

The access point of a consumer DSA which shadows all or part of the naming context corresponding to the context prefix holding this attribute. Specify access_point_of_consumer as an Access-Point syntax. (See Access-Point for details.)

AGR=operational_binding_ID

The identifier of the operational binding for the shadow agreement. Specify operational_binding_ID in the following format:

{ID=operational_binding_identifier,
VERS=version_ number}

where:

ID=operational_binding_identifier

Is an integer that identifies the shadow agreement binding. The ID is assigned by the holding DSA as part of the establishment of the operational binding, and is unique within the scope of the two DSAs.

VERS=version_number

Is an integer that identifies the version of the shadow agreement binding. This integer increases when the operational binding is modified.

Description

Information about shadow consumers for a particular naming context held by a shadow supplier DSA are represented by a multi-valued Consumer Knowledge operational attribute associated with the context prefix of the naming context. The information identifies the access points of the consumer DSAs and also the identifiers for the corresponding shadowing agreements. Note that there can be several shadowing agreements involving this naming context with a specific consumer DSA.

Examples

CK={CON={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa},
    PSAP={TS=Server19,NA='TCP/IP!internet=123.45.67.89+port=102'},
    AGR={ID=10,VERS=20}
    }

Master-And-Shadow-Access-Points

An attribute syntax for distributed-operation attributes that specify access points for partner DSAs within a distributed DIT. The SK attribute (Specific Knowledge) is an example of such an attribute in the default DSA schema.

Synopsis

MasterAndShadowAccPoints={MOS=MasterOrShadowAccPoint}

The value is a set of components of type MasterOrShadowAccPoint

Attribute Type

MasterAndShadowAccPoints

The abbreviation or OID that corresponds to a structured attribute with the Master-And-Shadow-Acc-Points (MASTER_AND_SHAD_ACC_POINTS) syntax. The SK (Specific Knowledge) attribute is an operational attribute that represent knowledge references, and is accessible using dirxadm only. The SK attribute is used for DSEs of type subordinate reference, cross-reference and immediate superior reference.

Components

MOS=MasterOrShadowAccPoint

The access for the master or a shadow DSA. Specify MasterOrShadowAccPoint in the following format:

{MSAP=access_point
[,CAT=category]}

where:

MSAP=access_point

Is the access point for the master or a shadow DSA. access_point is an AccessPoint component. See AccessPoint for details on the component format.

CAT=category

Specifies whether the access point is for the master or a shadow DSA. Specify category as one of the following keywords:

  • MASTER

  • SHADOW

The default is MASTER. Only one MasterOrShadowAccPoint value can be assigned a category of MASTER.

Description

This syntax must be used for the administration of subordinate references, cross-references and immediate superior references. Access points for the corresponding master and shadow DSAs are represented with the MasterAndShadowAccPoints (MASTER_AND_SHAD_ACC_POINTS) syntax. The access points are specified with an AccessPoint component and the category of the DSA (master or shadow) is also specified.

Examples

SK={MOS={MSAP={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa1},
               PSAP={TS=Server19,
                     NA='TCP/IP!internet=123.45.67.89+port=102'}},
         CAT=MASTER};
        {MSAP={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa2},
               PSAP={TS=Server19,
                     NA='TCP/IP!internet=139.88.99.1+port=102'}},
         CAT=SHADOW}
   }

Supplier-Information

An attribute syntax for attributes that specify information known to a shadow consumer DSA about the shadow supplier DSA in a shadow agreement. There is only one such attribute in the default DSA schema: SUK (Supplier-Knowledge).

Synopsis

SupplierInformation={SUP=access_point,
    AGR=agreement_ID,
    ISM=is_master
    [,NSM=access_point]}

Attribute Type

SupplierInformation

The abbreviation or OID that corresponds to a structured attribute with the Supplier-Information (SUPPL_INFO) syntax. For example, SUK is an attribute of a context prefix of a shadowed naming context.

Components

SUP=access_point

The access point for the shadow supplier DSA that shadows all or part of the naming context covered by the shadow agreement specified with the AGR subcomponent. The shadow-supplier DSA can be the master DSA only if the agreement is not a secondary shadowing agreement. access_point is an AccessPoint subcomponent. See AccessPoint for details on the attribute format.

AGR=agreement_ID

The identifier of the operational binding for the shadow agreement. Specify operational_binding_ID in the following format:

{ID=operational_binding_identifier,
VERS=version_ number}

where:

ID=operational_binding_identifier

Is an integer that identifies the shadow agreement binding. The ID is assigned by the holding DSA as part of the establishment of the operational binding, and is unique within the scope of the two DSAs.

VERS=version_number

Is an integer that identifies the version of the shadow agreement binding. This integer increases when the operational binding is modified.

ISM=is_master

A Boolean value that specifies whether the supplier holds the master copy of the naming context. The value is represented using BOOLEAN attribute syntax. (See the Simple Attribute Syntax for a description of BOOLEAN syntax representation.) The default value is TRUE (the supplier holds the master copies). If the value is FALSE; the shadowing agreement is a secondary shadowing agreement.

NSM=access_point

If the shadow supplier in the shadow agreement specified by the ARG component does not hold the master copy of the naming context, the NSM component defines the master DSA’s access point. The NSM subcomponent is optional but should be used to optimize operations (for example, update operations) that are passed to the DSA that holds the master naming context. access_point is an AccessPoint subcomponent. See AccessPoint for details on the subcomponent format.

Description

Information about a shadow supplier is represented with the SupplierInformation (SUPPL_INFO) syntax. This information known by a shadow consumer DSA is hold in the SUK attribute of the shadowed context prefix and consists of the ID and version number that identify the shadow agreement between the supplier and the consumer, the access point for the supplier of the copy of the naming context, and an indication of whether this supplier holds the master copy of the naming context. In addition, the information can optionally include the access point for the master if the supplier does not hold the master copy.

Examples

SUK={SUP={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa1},
          PSAP={TS=Server19,
                NA='TCP/IP!internet=123.45.67.89+port=102'}},
     AGR={ID=1,
          VERS=1},
     ISM=TRUE,
     NSM={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa2},
          PSAP={TS=Server19,
                NA='TCP/IP!internet=139.88.99.1+port=102'}};
         {AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa3},
          PSAP={TS=Server19,
                NA='TCP/IP!internet=139.88.99.2+port=102'}}
    }

Supplier-And-Consumers

An attribute syntax for attributes that document the suppliers of secondary shadows and their consumers. In the default DSA schema, this is used only in the SES (Secondary-Shadows) operational attribute.

Synopsis

SupplierAndConsumers*={SUP=_access_point,
CON=access_point[;_access_point_]…​}

Attribute Type

SupplierAndConsumers

The abbreviation or OID that corresponds to a structured attribute with the Supplier-And-Consumers (SUPPL_AND_CONSS) syntax. For example, SES (Secondary-Shadows) is an attribute of a context prefix.

Components

SUP=access_point

The access point for each shadow supplier that has a secondary shadow. Specify access_point as an Access-Point subcomponent. See Access-Point for more information.

CON=access_point

The access point for each shadow consumer of the suppliers named with the SUP component. Specify access_point as an AccessPoint subcomponent. See Access-Point for more information.

Description

The suppliers of secondary shadows and their consumers are represented with the Supplier-And-Consumers attribute syntax. The syntax uses an Access-Point attribute to identify the access points.

Examples

SES={SUP={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa1},
         PSAP={TS=Server19,
               NA='TCP/IP!internet=123.45.67.89+port=102'}}},
     CON={AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa2},
         PSAP={TS=Server19,
               NA='TCP/IP!internet=139.88.99.2+port=102'}}};
	   {AE={/O=my-company/OU=asw/CN=dsa/CN=sni-dsa3},
         PSAP={TS=Server19,
               NA='TCP/IP!internet=139.88.99.3+port=102'}}}
    }

Certificate (Signed)

An attribute syntax for schema attributes that specify authentication certificates that store the public key of a user and the public key of the user’s certification authority.

Synopsis

Cert = {CU=certificate_unsigned,
    ALG=algorithm,
    EV=encrypted_value}

Attribute Type

Cert

The abbreviation or OID that corresponds to a structured attribute with the Cert (Cert) syntax. Two attributes in the default schema have this syntax:

  • UC (user-certificate), an attribute of entries with object class strong-authentication-user

  • CAC (CA-Certificate), an attribute of entries representing Certification Authorities

Components

CU=certificate_unsigned

The unsigned user certificate. The certificate_unsigned parameter is in the form of a Certificate (Unsigned) component. See Certificate (Unsigned) for details on its format.

ALG=_algorithm

The OID that identifies the signature algorithm used to sign (i.e., hash the data and sign it) the certificate and any parameters used by that algorithm. Specify algorithm in the following format:

{AL=object_identifier[,ALP=algorithm_parameters]}

where:

AL=object_identifier

Is the OID or abbreviation that identifies the algorithm used to sign the certificate. This parameter represents the combination of the method used to hash the certificate information and the public-key cryptography system employed.

ALP=algorithm_parameters

Are parameters used by the algorithm for the signature. The form depends on the object identifier specified by the AL component, but is generally absent (no additional parameters needed).

EV=encrypted_value

The encrypted value. This value is the result of the following procedure:

  1. The unencrypted certificate list is encoded using ASN.1 under the constraints documented in clause 9 of X.509.

  2. The results are hashed using the hashing algorithm specified by the object identifier

  3. The hash results are encrypted using the encryption algorithm specified by the object identifier, and making use of the private key of the signing entity

  4. The result is expressed as a bit string

Description

Certificates that store either a user’s public key or the public key of the user’s certification authority (known as CA certificates) are represented with the Certificate attribute syntax. Both forms of certificates are unsigned until a signature is provided by the relevant certification authority. The signature represents the encrypted hash of an encoding of the certificate.

Examples

CAC={CU={VER=V3,
         SN=10,
         SIG={AL=2.5.8.1.1,
	        ALP=1024
             },
         IS={/O=my-company/OU=asw},
         VAL={VNA=9412011200Z,
	        VNB=9412011500Z
             },
         SUB={/O=my-company/OU=asw/CN=wythenshawe},
         SUBK={AL={AL=2.5.8.1.1,
	             ALP=1024
               	  },
PK=001100010011001000110011110010011000001100010000001
   	      },
    	 IUID=0011000100110010001100,
    	 SUID=1111010100101001011110
        },
     ALG={AL=2.5.8.1.1,
 	    ALP=1024
	 },
     EV=0011000100110010001100}

Certificate (Unsigned)

A syntax for a component of an unsigned certificate.

Synopsis

CU = {[VER=version_number]
    ,SN=serial_number
    ,SIG=signature_algorithm
    ,IS=DN_of_issuer
    ,VAL=validity
    ,SUB=DN_of_subject
    ,SUBK=public_key_for_subject
    [,IUID=unique_ID_of_issuer]
    [,SUID=subject_unique_id]
    [,EXT=extensions;extensions;…​]}

Components

VER=version_number

The version number of the user certificate. Up to 3 versions are supported. Specify the version number as one of the following keywords.

  • V1 - Includes neither unique-identifiers or extensions (The default.)

  • V2 - Optionally includes unique-identifiers, but does not include extensions

  • V3 - Optionally includes unique-identifiers and extensions

SN=serial_number

An integer that specifies the serial number of the user certificate. The number is unique for the Certification Authority.

SIG=signature_algorithm

The OID that identifies the algorithm used to sign the certificate and any parameters used by that algorithm. Specify signature_algorithm in the following format:

{AL=object_identifier
[,ALP=algorithm_parameters]}

where:

AL=object_identifier

Is the OID or abbreviation that identifies the algorithm used to sign the certificate. This parameter represents the combination of the method used to hash the certificate information and the public-key cryptography system employed.

ALP=algorithm_parameters

Are parameters used by the algorithm for the signature. The form depends on the object identifier specified by the AL component, but is generally absent (no additional parameters needed).

IS=DN_of_issuer

The distinguished name of the certification authority that issued the certificate for the user.

VAL=validity

The period of time during which the certificate is valid. Specify validity as a range of dates in the following format:

{VNB=valid_not_before,
VNA=valid_not_after}

where:

VNB=valid_not_before

Is the time in UTC format that begins the range.

VNA=valid_not_after

Is the time in UTC format that terminates the range.

SUB=DN_of_subject

The distinguished name of the user for whom the certificate was created.

SUBK=public_key_for_subject

The user’s public key. Specify public_key_for_subject in the following format:

{AL=algorithm_for_subject,
PK=public_key}

where:

AL=algorithm_for_subject

Is the OID that identifies the algorithm used to encrypt the user’s public key and any parameters used by the algorithm. Specify algorithm_for_subject in the following format:

{AL=object_identifier[,ALP=algorithm_parameters]}

where:

AL=object_identifier

Is the OID of the algorithm used to encrypt the user’s public key.

ALP=algorithm_parameters

Are parameters used by the algorithm for the encryption.

PK=public_key

The public key for the certificate user. The format depends on the algorithm specified by the AL component. It typically consists of an ASN.1 encoding of the key components.

IUID=unique_ID_of_issuer

The UID (a bit string) of the certification authority that issued the certificate. This component is optional. When present, it distinguishes between two objects that possess the same distinguished name at different times. (They cannot both possess the same name at the same time.)

SUID=subject_unique_id

The UID (a bit string) of the user for whom the certificate was created.

_EXT=extensions

Extensions provide an open-ended method for holding additional information. Each extension consists of three components:

  • An identifier for the extension

  • A critical extension flag indicating whether the extension can be ignored if not understood

  • A value which represents the data corresponding to the extension

Specify extensions in the following format:

{ID=oid
[,CRIT=boolean value,]
EV=OCTET_STRING}

where:

ID=oid

Is the OID specifying the extension type.

CRIT=boolean value

Is an indication of whether or not the extension can be ignored by a user that does not understand the extension. If TRUE, the extension is critical, and the user must be able to understand the extension to use the certificate. (See Simple Attribute Syntax for a description of BOOLEAN syntax.)

EV=octet_string

Is the DER encoded extension information represented within an octet string. The format of the information is dependent on the value of the OID used to identify the extension.

Description

The unsigned components of certificates that store user and certificate authority keys are represented with the Certificate (Unsigned) attribute syntax. The certificates, which are issued by a certificate authority, store users’ certified public keys along with other pertinent information. They are used to authenticate the identity of the user.

Specifically the certificates hold the following information provided by the signing certificate authority:

  • A version number, a number ranging from V1 to V3 that is assigned by the certificate authority, and a version number also assigned by the certificate authority

  • An ID that identifies the algorithm to be used to sign the certificate with other parameters if needed

  • The distinguished name of the certification authority that issued the certificate, extended, if necessary with a unique UID

  • A validity period, specified by a begin date and an end date, that defines the lifetime of the certificate

  • The name of the user of the private key for which the certificate publishes the public key, extended, if necessary with a unique UID

  • An encoding of the public key components

  • Optionally, an open-ended set of extensions, which are additional information that can be used to define the usage or validity of the certificate

Examples

CU={VER=V3,
    SN=10,
    SIG={AL=1.3.14.3.2.2,
	   ALP=1024
        },
    IS={/O=my-company/OU=asw},
    VAL={VNA=9412011200Z,
	   VNB=9412011500Z
        },
    SUB={/O=my-company/OU=asw/CN=wythenshawe},
    SUBK={AL={AL=1.2.840.113549.1.1.1,
	      ALP=1024},
          PK=001100010011001000110011110010011000001100010000001     	 },
    IUID=0000110101001011010100,
    SUID=1011010101101101011000
   }

Certificate-Pair

An attribute syntax for attributes that specify cross-certificate pairs.

Synopsis

Cert-Pair = {[F=certificate]
    [,R=certificate]}

Attribute Type

Cert-Pair

The abbreviation or OID that corresponds to a structured attribute with the Certificate-Pair (CERT_PAIR) syntax. For example, CCP (Cross-Certificate-Pair) is such an attribute. The CCP attribute is an attribute normally associated with Certification Authorities.

Components

F=certificate

An unsigned certificate that stores the public key of a “forward” member of the cross-certificate pair. Specify certificate as a Certificate (Signed) attribute. See Certificate (Signed) for the attribute format.

R=certificate

An unsigned certificate that stores the public key of a “reverse” member of the cross-certificate pair. Specify certificate as a Certificate (Signed) attribute. See Certificate (Signed) for the attribute format.

Description

Certificate pairs are used within cross-certificate-pair attributes to cross-connect CAs (e.g., CAs associated with different organizations). Cross-connect CAs are represented with the Certificate-Pair attribute syntax. Certificate pairs are certificates for two CAs that mutually trust each other.

When combined with other CA certificates in a certificate path, the certificate pair makes it possible to create a trusted certification path that progresses from a certificate issued by a trusted CA to the certificate of the object whose signature is to be checked.

A cross-certificate-pair attribute can supply pairs of certificates for which the issuer of one is the subject of the other. It can alternatively supply just one of the pair (typically the forward component). The set of forward certificates in a cross-certificate-pair should represent a single unbroken directed graph (i.e., the subject of each certificate shall be the issuer of another forward certificate or of the originator’s certificate).

Example

CCP={F={CU={VER=V3,
            SN=10,
            SIG={AL=2.5.8.1.1,
                 ALP=1024
                },
            IS={/O=my-company/OU=asw},
            VAL={VNA=9412011200Z,
	           VNB=9412011500Z
                },
            SUB={/C=ie/O=sse},
            SUBK={AL={AL=2.5.8.1.1,
	                ALP=512
		     },
                  PK=0011000100110010001100111100100110000011000100
   	         },
    	    IUID=00101010110100101001,
    	    SUID=00111010110100111001
           },
        ALG={AL=2.5.8.1.1,
	       ALP=1024
	    },
        EV=0011000100110010001100
       },
     R={CU={VER=V3,
            SN=10,
            SIG={AL=2.5.8.1.1,
	           ALP=1024
                },
            IS={/C=ie/O=sse},
            VAL={VNA=9412011200Z,
	           VNB=9412011500Z
                },
            SUB={/O=my-company/OU=asw},
            SUBK={AL={AL=2.5.8.1.1,
	                ALP=512
		     },
                  PK=00110001001100100011001111001001100000110001000
   	         },
    	    IUID=10101010110100101001,
    	    SUID=00111010110000101001
           },
        ALG={AL=2.5.8.1.1,
	       ALP=1024
	    },
        EV=0011000100110010001100
       }
    }

Cert-List (Signed)

An attribute syntax for signed certificate lists, used solely by Certification Authorities to hold revocation lists (lists of identifiers for certificates that have been revoked, typically because they have become compromised, or are otherwise no longer valid).

Synopsis

CertList = {CLU=certificate_list_unsigned,
    ALG=algorithm,
    EV=*encrypted_value}*

Attribute Type

CertList

The abbreviation or OID that corresponds to a structured attribute with the Cert-List (CERT_LIST) syntax. Attributes with this syntax have two uses:

  • For CRL (Certificate-Revocation-List) information, to revoke user’s certificates

  • For ARL (Authority-Revocation-List) information, to revoke CA’s certificates

Both are types of information are attributes of Certification Authorities.

Components

CLU=certificate_list_unsigned

An unsigned certification list. Specify certificate_list_unsigned in the form of a Cert-List (Unsigned) component. See Cert-List (Unsigned) for a description of this component format.

ALG=algorithm

The OID that identifies the algorithm used to sign the certificate list together with any parameters used by that algorithm. Specify algorithm in the following format:

{AL=*object_identifier[,ALP=algorithm_parameters]}*

where:

AL=object_identifier

Is the OID or abbreviation that identifies the combination of hashing and encryption algorithms used to sign the certificate-list. This component is required by any algorithm that checks the signature.

ALP=algorithm_parameters

Are parameters used by the algorithm for the signature. The format is dependent on the value of the AL component, but in most cases, there will be no additional parameters.

EV=encrypted_value

The encrypted value is a result of the following procedure:

  1. The encrypted certificate list is encoded using ASN.1 under the constraints documented in clause 9 of X.509

  2. The encryption results are hashed using the hashing algorithm specified by the AL component

  3. The resulting hash is encrypted the encryption algorithm specified by the AL and the private key of the signing entity

  4. The result is expressed as a bit string

Description

Signed certificate lists are represented with the Cert-List (Signed) attribute syntax. The certificate list portion of the Cert-List (Signed) attribute is represented by an Cert-List (Unsigned) component (described in the Cert-List (Unsigned)). The signature portion consists of the digital signature in the form of a bit string, together with an object identifier that specifies the procedure by which the signature was created and (where necessary) any additional parameters for the signature process.

Example

ARL={CLU={VER=V2,
    	     SIG={AL=1.3.14.3.2.3},
    	     IS={/O=My-Company/OU=Corporate CA },
    	     TU=9612011200Z,
           NU=9612011300Z,
	     RC={SN=25,
               RD=9603011500Z};
	        {SN=75,
               RD=9608231005Z}},
      ALG={AL=1.3.14.3.2.3},
      EV=0011000100110010001100}

Cert-List (Unsigned)

A syntax for unsigned certificate lists. This syntax is never used as an attribute syntax. It specifies the syntax of information that, with a digital signature, comprises a certificate revocation list. The signed version of this information is defined in the Cert-List (Signed) attribute syntax, which describes the syntax of the values that used as actual attribute values.

Synopsis

CLU= {[VER=version_number]
    ,SIG=signature_algorithm
    ,IS=DN_of_issuer
    ,TU=this_update
    [,NU=next_update]
    [,RC=revoked_certificates;revoked_certificates;…​]
    [,EXT=extensions;extensions;…​]}

Components

VER=version_number

The version number of the certificate list. Up to two versions are supported. Specify the version number as one of the following keywords.

  • V1 (Version 1 lists do not have a corresponding version_number element; for version 1 lists, this argument should not be specified)

  • V2 (Version 2 optionally includes extensions)

SIG=signature_algorithm

The OID that identifies the algorithm used to sign the certificate list together with any parameters used by that algorithm. Specify signature_algorithm in the following format:

{AL=object_identifier[,ALP=algorithm_parameters]}

where:

AL=object_identifier

Is the OID or abbreviation that identifies the combination of hashing and encryption algorithms used to sign the certificate-list. This is required by any algorithm that checks the signature. It duplicates the information provided with the signature itself. (See the AL component in Cert-List (Signed) attribute syntax.)

ALP=algorithm_parameters

Are parameters used by the algorithm for the signature. The format depends on the value of the AL component, but in most cases, there will be no additional parameters. This information, if present, duplicates the information provided with the signature itself. (See the ALP component in Cert-List (Signed) attribute.)

IS=DN_of_issuer

The distinguished name of the certification authority that issued the certificate list.

TU=this_update

The date and time of issue of this certificate list, in UTC time format. The information is used to help assess the validity of the list.

NU=next_update

The date and time of the next planned update to the certificate list, in UTC time format. If this date and time have passed, the current list is obsolete. The CA will check current list for any certificates whose validity is in question. If the current list is unavailable, the CA will consider the certificates to be suspect.

RC=revoked_certificates

The list of certificates that have been invoked and are no longer valid. Specify revoked_certificates in the following format:

{SN=serial_number,
    RD=revocation_date
    [,EXT=extensions;extensions;…​]}

where:

SN=***serial_number

Is an integer that specifies the serial number of the revoked certificate.

RD=revocation_date

Is the date and time the certificate was revoked in UTC time format.

EXT=extensions;extensions;…​

Specifies extensions that apply to individual certificates. It cannot be supplied for V1 lists.

Extensions in certificates and certificate lists provide an open-ended method for holding additional information. Each extension consists of three components:

  • An identifier for the extension

  • A critical extension flag indicating whether the extension can be ignored if not understood

  • A value which represents the data corresponding to the extension

  • Specify extensions in the following format:

  • {ID=oid
    [,CRIT=boolean value,]
    EV=octet_string}

  • where:

    ID=oid

    Is the OID for the form of the extension information.

    CRIT=boolean value

    Indicates whether or not the extension can be ignored by a user of this information that does not understand the extension . If TRUE, the extension is critical, and the user must be able to understand the extension to use the certificate. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

    EV=octet_string

    Is the DER encoded extension information represented within an octet string, for example,

    EV=\x02\x01\x00

    The format of the information is dependent on the value of the OID used to identify the extension.

EXT=extensions

Extensions are used here to represents extensions for the list as a whole. Extensions cannot be specified for V1 lists.

Specify extensions in the following format:

{ID=oid[,CRIT=boolean_value,] EV=octet_string}

See the previous *RC=*revoked_certificates section for further details.

Description

Certificate revocation lists (CRLs) are represented with the Certificate-List (Unsigned) (CertListUnsigned) attribute syntax. A CRL is issued regularly by each issuing certification authority (CA), and contains a list of those certificates issued by the CA that have been declared invalid although their validity period has not expired. A separate list is provided for user certificates and CA-certificates issued by a particular CA.

Revoked certificates are invalid, usually because the user’s or CA’s private key has been compromised. Note that a signature signed by the owner of a revoked certificate may still be valid (just as transactions may be valid for a lost credit-card if they predate the time of loss).

Version 2 certificates contain the means of augmenting the information contained in the CRL in two ways:

  • Extension information can be associated with any certificate identifier

  • Extension information can be associated with the CRL as a whole.

The purpose of a CRL is to ensure that certificates can be trusted if their identifiers are not on the most recent CRL. For this to work, a CRL must be up to date, and users must be able to determine that the CRL that they have obtained is the latest one.

Example

CLU={VER=V2,
    	            SIG={AL=1.3.14.3.2.3},
    	            IS={/O=My-Company/OU=Corporate CA },
    	            TU=9612011200Z,
                  NU=9612011300Z,
	            RC={SN=25,
                      RD=9603011500Z};
	               {SN=75,
                      RD=9608231005Z}
	           }

ACI-Item

An attribute syntax for attributes that specify one of the following:

  • Access control policies (for prescriptive ACI or subentry-ACI operational attributes)

  • Local access control requirements applicable to a single entry when used in the entry ACI operational attribute.

Synopsis

ACII = {ID=id_tag,
    PR=integer,
    AL={authentication_level},
    IF={item_first} | UF={user_first}}

Attribute Type

ACII

The abbreviation or OID that corresponds to a structured attribute with the ACI-Item (ACIITEM) syntax. The attributes with ACIITEM attribute syntax are:

  • Prescriptive-ACI (PACI) - An operational attribute of a subentry that contains access control information applicable to entries within a subentry’s scope.

  • Entry-ACI (EACI) - An operational attribute of an entry that contains access control information applicable to the entry in which it appears and to that entry’s contents.

  • Subentry-ACI (SACI) - An operational attribute of an administrative point that contains access control information that applies to each of the subentries associated with the administrative point.

Components

ID=id_tag

A string (of up to 64 characters long) that identifies the ACIITEM using a string that can be meaningful to an administrator. Specify the string in DIR_STR format. (See Simple Attribute Syntax for a description of DIR_STR format.)

PR=integer

An integer that specifies the precedence of the ACIITEM relative to other ACIITEMs. If the ACI evaluation encounters a grant and a denial that relate to the same user and action on the same protected object, and the grant has a higher precedence than the denial, the grant wins.

If both have the same precedence, the rules of implicit preference are followed:

  • The ACIITEM with the more specifically defined user wins

  • If there is no more specifically defined user, the ACIITEM with the more specifically defined protected-object wins, or the denial wins.

Specify integer as a value from 0 to 255, with 0 corresponding to a default and 255 to a mandatory policy.

AL={authentication_level}

The minimum authentication level required to access the entry. Specify authentication_level in the format:

BL={L=*level}*

where level is one of the keywords:

  • NONE - Requires user identification

  • SIMPLE - Requires user identification and password authentication

  • STRONG - Requires user authentication using public key cryptography. An ldap sasl bind operation with mechanism EXTERNAL is mapped onto the authentication level STRONG.

IF={item_first}

The protected items and their permissions. This component can help provide a variety of access capabilities to different users and user classes through a simply expressed set of protected items.

Specify item_first in the format:

PI={protected_items},
IP={item_permission[};{item_permission …​]}

where:

PI={protected_items_}

Is a structured component that represents a set of protected items. Each component is optional and defines a protected item. Specify protected_items in the format:

[E=boolean]
[,AUAT=boolean]
[,AT=attribute_list]
[,AAV=attribute_list]
[,AUATV=boolean]

where:

E=boolean

Determines whether the permissions apply to the entry. Further permissions are usually needed to access the information in the entry. However, there is one exception: the entry can be deleted without regard to the access rights to the attributes. The value is represented using BOOLEAN attribute syntax. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

AUAT=boolean

Determines whether the permissions apply to all user attributes as a whole. Further permissions are usually needed to access the information in the entry. However, there is one exception: the entry can be deleted without regard to the access rights to the attributes.

This component cannot be used to define permissions for operational attributes. The value is represented using BOOLEAN attribute syntax. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

AT=attribute_list

Specifies that the permissions apply to the attribute types identified by abbreviation or OID in attribute_list. Consult the attribute definition block section of the abbreviation files or use the dirxadm or dirxcp show abbr operation to obtain the list of attribute type abbreviations and OIDs.

Additional permissions are usually needed to access the information in the entry with one exception: the entry can be deleted without regard to the access rights to the attributes.

This component can be used to define permissions for explicitly identified operational attributes.

AAV=attribute_list

Specifies that the permissions apply to the attribute values associated with the attribute types identified by abbreviation or OID in attribute_list. Consult the attribute definition block section of the abbreviation files or use the dirxadm or dirxcp show abbr operation to obtain the list of attribute type abbreviations and OIDs.

In general, access must be granted first to each attribute before access to the attribute values is granted. However, there is one exception: in a modify-entry operation; attribute values can be added or removed without regard to the access rights on the attribute.

AUATV=boolean

Determines whether the permissions apply to all user attribute information associated with the entry, including all values of user attributes. The value is represented using BOOLEAN attribute syntax. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

IP={item_permission_[};{item_permission …​]}

item_permission represents one or more permissions to be applied to protected_items. Specify item_permission in the format:

[PR=integer,]
UC={user_class},
GAD=permissions

where:

PR=integer

Specifies the precedence of the ACIITEM relative to other ACIITEMs. (See the PR component for more information on ACIITEM precedence.) Specify a value from 0 to 255. This is an optional component. If it is not specified, the precedence level used is the level specified in the ACIIITEM PR component.

UC={user_class}

Specifies the users to which the permissions apply. Specify user_class in the format:

[AU=boolean] [,TH=boolean] [,N={name_and_opt_uid}] [,UG={user_group}] [,SUB={subtree}]

where each component is optional and defines a set of users:

AU=boolean

Determines whether the permissions apply to every directory user that has been authenticated in compliance with the authentication level specified by the AL component. The value is represented using BOOLEAN attribute syntax. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

TH=boolean

Determines whether the permissions apply to the authenticated user with the same distinguished name as the entry being accessed. (Authentication is performed using the method defined by the AL component.)

N={name_and_opt_uid}

*Specifies that the permissions apply to the user with the specified distinguished name and (optionally) UID. The UID component can only be used with users authenticated with the strong method of authentication. (See the *AL component for more information.) See the description of the Name-And-Optional-UID structured attribute for information on how to specify the name_and_opt_uid argument. Supply the distinguished name of the object absolute (relative to the root of the DIT).

UG={user_group}

Specifies the distinguished name and (optionally) UID of a Group-of-Unique-Names object (GOUN), or the distinguished name of a Group-Of-Names object (GON) with nested group support (auxiliary object class IMPGRP), or the distinguished name of a Dynamic-Group object (DYNGRP). The permissions apply to all members of the object. Supply the distinguished name of the object absolute (relative to the root of the DIT).

SUB={subtree}

Specifies that the permissions apply to the set of users whose distinguished names fall within the definition of the specified subtree. See the description of the Subtree-Specification structured attribute for an explanation of its component syntax.

GAD=permissions

Specifies the access rights to be granted or denied. Specify permissions as one of more of the following keywords, separated by the plus sign (+):

grantAdd

denyAdd

grantBrowse

denyBrowse

grantCompare

denyCompare

grantDiscloseOnError

denyDiscloseOnError

grantExport

denyExport

grantFilterMatch

denyFilterMatch

grantImport

denyImport

grantModify

denyModify

grantRead

denyRead

grantRemove

denyRemove

grantRename

denyRename

grantReturnDN

denyReturnDN

Do not mix permissions that grant and deny access in a single ACIITEM. Grant and denial permissions evaluate authentication levels slightly differently, so that the meaning of the user classes is potentially different. For example, with the authentication level set to simple, a granting access to all users will insist that they have authenticated using simple authentication. Denying access to all users will deny all users whatever the means of authentication.

The meanings of these permissions are described in the following table.

Permission Meaning

Add

For entries: controls the ability to create an entry in the DIT (subject to the access controls on all attributes and values to be placed in the new entry). In order to add an entry, permission to add its mandatory attributes and their values must t least be granted. For attributes: controls the ability to add an attribute (subject to the ability to add all specified attribute values). For attribute values: controls the ability to add an attribute value to an existing attribute

Browse

For entries: controls whether directory operations (i.e., list and search operations) can access entries that they do not specifically name

Compare

For attributes and their values: controls whether attributes and values can be used in compare operations

DiscloseOnError

For entries: controls whether the entry’s name can be returned in an error or empty result. If not granted, the Directory returns an error as if the entry did not exist. For attributes: controls whether the attribute’s presence can be disclosed in attribute or security errors. If not granted, the Directory returns an error as if the attribute did not exist. For attribute values: controls whether the attribute value’s presence can be disclosed in attribute or security errors. If not granted, the Directory returns an error as if the attribute did not exist.

Export

For modify DN operations: controls whether an entry can be moved (with its subordinates, if any) from its present position in the DIT to another position in which it has a different superior entry. The Export permission must be held by the old superior entry. If the last RDN of the entry being moved is changed, the entry must also possess the Rename permission.

FilterMatch

For attributes and their values only: controls whether the attributes and values can be matched with corresponding values in a search filter. If the cannot, the filter must be evaluated as if the attribute or value was either absent or could not be accessed.

Import

For modifyDN operations only: applies when an entry is being moved (with its subordinates, if any) to another position in the DIT where it has a different superior entry: The Import permission must be held by the new superior entry. The entry must itself grant Export permissions for success.

Modify

For entries only: controls whether the information contained in an entry can be modified using a modify operation. Note that appropriate attribute and value permissions must also be granted in order to modify any attributes and values in the entry. (Modifying the RDN is no affected by the Modify permission.)

Read

For entries: controls whether Directory read or compare operations that specifically name an entry can read that entry. Further permissions are required to access the attributes and their values. For attributes and values: controls whether read or search operations can return attributes and values as entry information.

Remove

For entries: controls the ability to remove an entry from the DIT regardless of controls on attributes or attribute values within the entry. For attributes: controls the ability to remove an attribute and all of its values. For attribute values: controls the ability to remove an attribute value from an existing attribute.

Rename

For entries only: controls whether an entry can be renamed with a new RDN subject to the consequential changes to the distinguished names of subordinate entries. (It may not be possible to rename an entry when there is a subordinate reference that is subordinate to the entry.) Note, however, that permissions within subordinate entries are not taken into account when evaluating permissions for this operation.

ReturnDN

For entries only: controls whether an entry’s distinguished name can be returned in an operation result. If this permission is not granted, an alias name can in some cases be returned; if it is not possible to return an alias, information about the entry is withheld.
UF={user_first}

A component that specifies user classes and their permissions This component can help provide a variety of access capabilities to different items through a simple set of user classes.

Specify user_first in the format:

UC={user_class},
UP={user_permission[};{user_permission …​]}

where:

UC={user_class}

Represents a set of users. Specify user_class in the same format as the UC component of the IF (item_first) component’s IP (item_permission) component.

UP={user_permission[};{user_permission …​]}

Represents one or more permissions to be applied to user_class. Specify user_permission in the format:

[PR=integer,]
PI={ protected_items},
GAD=permissions

where:

PR=integer

Has the same format and meanings as the PR component of item_permission (IP).

PI=protected_items

Has the same format and meaning as the PI component of item_first (IF).

GAD=permissions

Has the same format and meaning as the GAD component of item_permission (IP).

Description

Access control information is represented with the ACIITEM attribute syntax. Each ACIITEM grants or denies defined permissions to specific users and protected items.

The id_tag component provides an identifier for each ACIITEM. You can use it to remove a specific ACIITEM value, or to protect it with a prescriptive-ACI, subentry-ACI or entry-ACI, as appropriate.

The item_first and user_first components represent different ways to organize access control information. Use item_first if you want to group permissions by protected items (entries). Alternately, you can use user_first to group permissions by user classes.

Example

PACI={ID=Some authenticated users can Read all entries,
      PR=50,
      AL={BL={L=SIMPLE}},
      UF={UC={N={DN={/O=My-Company/CN=admin}};
                {DN={/O=My-Company/OU=Sales/CN=Mayer}};
                {DN={/O=My-Company/OU=Manufacturing/CN=Ketzer}},
              SUB={BAS={/O=My-Company/OU=Development}}},
          UP={PI={E=TRUE},
              GAD=grantRead+grantBrowse+grantReturnDN};
             {PI={AUATV=TRUE},
              GAD=grantRead+grantCompare+grantFilterMatch};
             {PR=51,
              PI={AT=UP},
              GAD=denyRead+denyFilterMatch}}};
     {ID=Authenticated users can Modify their passwords,
      PR=100,
      AL={BL={L=SIMPLE}},
      UF={UC={TH=TRUE},
          UP={PI={E=TRUE},
             GAD=grantModify};
             {PI={AT=UP,
                  AAV=UP},
              GAD=grantAdd+grantRemove}}};
     {ID=The administrator has additional permissions,
      PR=254,
      AL={BL={L=SIMPLE}},
      UF={UC={N={DN={/O=My-Company/CN=admin}}},
          UP={PI={E=TRUE},
              GAD=grantAdd+grantRemove+grantModify};
             {PI={AUATV=TRUE},
              GAD=grantAdd+grantRemove};
             {PI={AT=CRN;CRT;MN;MT},
              GAD=grantRead}}
      }

Cooperating-DSA

An attribute syntax for attributes that hold information about the administered operational bindings with partner DSAs or LDIF agreements. There is only one such attribute in the default schema: CDSA (Cooperating-DSA-Table), which is an attribute of a subentry of the root DSE. The Cooperating-DSA attribute syntax is only used for display purposes; it cannot be used for input.

Synopsis

CooperatingDSA = {SUPP=supplier_access_point
    [,CONS=consumer_access_point]
    [,SOB=shadow_operational_binding]}

Attribute Type

CooperatingDSA

The abbreviation or OID that corresponds to a structured attribute with the Cooperating-DSA (COOPERATING_DSA) syntax. The DirX Directory specific CDSA (Cooperating-DSA) attribute is such an attribute. The CDSA attribute is a system-maintained attribute of a subentry of the root DSE that can only be displayed with dirxadm.

Components

SUPP=supplier_access_point

Specifies the distinguished name and address of the supplier DSA of a shadowing or LDIF agreement. (See Access-Point structured attribute syntax for details.)

CONS=consumer_access_point

Specifies the distinguished name and address of the consumer DSA of a shadowing agreement. This component is not present for LDIF agreements. (See Access-Point structured attribute syntax for details.)

SOB=shadow_operational_binding

A structured component that defines the shadow binding. shadow_operational_binding is displayed in the format:

{SAI=shadow_agreement_info
    [,AGR=agreement_id]
    [,OBMV=operational_binding_validity]
    ,OBS=operational_binding_state
    [,RPOL=relating_sob_policies]}

SAI=shadow_agreement_info

A structured component that defines the components of a shadowing agreement. See Shadowing-Agreement-Info for a complete description of shadowing agreement information format.

AGR=agreement_ID

A structured component that identifies the operations binding. agreement_id is in the following form:
{ID=integer,VERS=integer}

where

ID=integer specifies the agreement ID and VERS=integer the binding version.

OBMV=operational_binding_validity

A structured component that defines the range of dates during which the binding is valid. operational_binding_validity is in the following form:

{[VF=valid_from][,VU=valid_until]}

where

valid_from is a generalized time string or the keyword NOW, which defines the beginning of the range of dates. The default value NOW defines the start of the date range as the current date.

valid_until is a generalized time string or the keyword TERMINATION, which is the default value and defines the end of the range as never.

OBS=operational_binding_state

Specifies the status of an operational binding. operational_binding_state is one of the following keywords:

  • COOPERATIVE - The shadowing or LDIF agreement is active.

  • NONCOOPERATIVE - The shadowing or LDIF agreement is inactive.

RPOL=relating_sob_policies

A component that identifies the SOB-Policies performed for this shadowing operational binding. See SOB-Policies for a detailed description of the relating_sob_policies format.

Description

The Cooperating-DSA attribute is a DSA-generated attribute of a subentry of the root DSE that displays the status of operational bindings between the DSAs participating in shadowing agreements or LDIF agreements. DirX Directory supports only shadowing operational bindings (SOB) that specifies shadowing or LDIF agreements.

This Cooperating-DSA attribute is multi-valued; it contains a value for every DSA involved in a SOB and for every LDIF agreement. The attribute should not be modified by users, and, being a root-DSE subentry attribute, can be accessed by dirxadm only. The dirxadm lob and sob functions can be used to create, modify, or delete the information displayed by this attribute syntax.

Examples

  1. In the following example the CDSA (Cooperating-DSA) attribute displays the attribute values of two LDIF agreements.

    CDSA={SUPP={AE={/O=My-Company/CN=DSA1},
      PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=123.45.67.89+port=21100}},

LDIF agreement 1:
      SOB={SAI={SS={AREA={CP={/O=My-Company},
                RA={BAS={/}}},ATT={DEF=TRUE}},
                UM={SI={S={PS={WS=1000,UI=1}}}}},
           AGR={ID=14057,VERS=0},
           OBMV={VF=030401064822Z},
           OBS=NONCOOPERATIVE,
           RPOL={SUPP={MAXLOC=1024},
                 LDSUPP={BINO=NONE,MAXROW=200,
                         CS=UTF8,CHANGEO=FALSE}}};

LDIF agreement 2:
          {SAI={SS={AREA={CP={/O=My-Company2},},
                RA={BAS={/}}},ATT={DEF=TRUE}},
                UM={SI={S={PS={WS=1000,UI=1}}}}},
           AGR={ID=16058,VERS=0},
           OBMV={VF=030401064822Z},
           OBS=NONCOOPERATIVE,
           RPOL={LDSUPP={CS=LATIN1,CHANGEO=FALSE}}}}

  2. In the following example the CDSA (Cooperating-DSA) attribute displays the attribute values of two shadowing agreements.

    {CDSA={SUPP={AE={/O=My-Company/CN=DSA1}
      PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=123.45.67.89+port=21100}},

       CONS={AE={/O=My-Company/CN=DSA2},
      PSAP={TS=DSA2,NA=TCP/IP_IDM!internet=123.45.67.88+port=21100}},

agreement 1:
       SOB={SAI={SS={AREA={CP={/O=My-Company},
                 RA={BAS={/}}},ATT={DEF=TRUE}},
                 UM={SI={S={PS={WS=1000,UI=1}}}}},
            AGR={ID=0,VERS=0},
            OBMV={VF=030401065354Z},
            OBS=NONCOOPERATIVE,
            RPOL={INI={ATU=TRUE},
                  SUPP={MAXLOC=100},
                  CONS={MAXLOC=100,REPLS=TRUE}}};

automatically generated agreement to propagate agreement information to consumer DSA:
           {SAI={SS={AREA={CP={/CN=Cooperating-DSAS-Subentry},
                 RA={DEF=TRUE}},ATT={DEF=TRUE}},
                 UM={SI={OC=TRUE}}},
            AGR={ID=1,VERS=0},
            OBMV={VF=030401065354Z},
            OBS=COOPERATIVE};

agreement 2:
           {SAI={SS={AREA={CP={/O=My-Company2},
                 RA={BAS={/}}},ATT={DEF=TRUE}},
                 UM={SI={S={PS={WS=1000,UI=1}}}}},
            AGR={ID=16058,VERS=0},
            OBMV={VF=030401065354Z},
            OBS=NONCOOPERATIVE,
            RPOL={SUPP={US=TOTAL},CONS={US=TOTAL}}}}}

Cooperating-DSA-Status

An attribute syntax for attributes that hold information about the administered operational bindings with partner DSAs. The Cooperating-DSA-Status attribute is only used for display purposes in dirxadm sob show or lob show operations. It cannot be used for input.

Synopsis

CoopDsaStatus = {DSA=cooperating_DSA
    [,RMSN=recent_MSN]
    ,SYNC=sync_status
    [,ASR=async_reason]}

Components

DSA=cooperating_DSA

The distinguished name and address of the supplier or consumer DSA in a shadowing agreement. See the Access-Point structured attribute syntax for details.

RMSN=recent_MSN

An integer value that identifies the modification sequence number (MSN) of the last confirmed operation. This component is only shown for synchronous shadowing agreements (the DISP_kind value for the –consumerkind option is set to SYNCHRON). See the dirxadm sob create operation in the DirX Directory Administration Reference for details.).

SYNC=sync_status

A Boolean value that shows the synchronous data status of the consumer DSA. A value of TRUE indicates that the consumer DSA’s data status is synchronized with the data status of the supplier DSA. This component is only shown for synchronous shadowing agreements (the DISP_kind value for the –consumerkind option is set to SYNCHRON). See the dirxadm sob create operation in the DirX Directory Administration Reference for details.).

ASR=async_reason

A text value that indicates the reason for a value of FALSE in the SYNC component. This component is only shown for synchronous shadowing agreements (the DISP_kind value for the –consumerkind and option is set to SYNCHRON). See the dirxadm sob create operation in the DirX Directory Administration Reference for details.

Description

The Cooperating-DSA-Status attribute is maintained by the DSA. It displays the current status of the supplier DSA when the command dirxadm sob show is invoked. It displays the current status of all consumer DSAs when the command dirxadm sob show –supplier dsa_name is invoked.

Examples

  1. The following example shows sample output of the command:

    dirxadm sob show

    The sample output shows the status of a supplier DSA in a DirX Directory-compliant/synchronous shadowing configuration:

    {SUPP={DSA={AE={/CN=DirX-DSA-host1},
     PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=192.168.0.2+port=21200},
     KIND=SYNCHRON},RMSN=4,SYNC=TRUE}

  2. The following example shows sample output of the command:

    dirxadm sob show

    The sample output shows the status of a supplier DSA DirX Directory-compliant/asynchronous shadowing configuration:

    {SUPP={DSA={AE={/CN=DirX-DSA-host2},
     PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=192.168.0.3+port=21200},
     KIND=CENTRALADMIN}}

  3. The following example shows sample output of the command:

    dirxadm sob show –supplier {/CN=DirX-DSA-host2}

    The sample output shows the status of a consumer DSA in a DirX Directory-compliant/asynchronous shadowing configuration:

    {CONS={DSA={AE={/CN=DirX-DSA-host3},
     PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=192.168.0.4+port=21200},
     KIND=CENTRALADMIN}}

  4. The following example shows sample output of the command:

    dirxadm sob show –supplier {/CN=DirX-DSA-host1}

    The sample output shows the status of a consumer DSA in a DirX Directory-compliant/synchronous shadowing configuration:

    {CONS={DSA={AE={/CN=DirX-DSA-host4},
     PSAP={TS=DSA1,NA=TCP/IP_IDM!internet=192.168.0.5+port=21200},
     KIND=SYNCHRON},RMSN=1,SYNC=TRUE}

For more information on the sob show and lob show operations, see the section on dirxadm in the DirX Directory Administration Reference. For more information about asynchronous, synchronous, DirX Directory-compliant and X.500-compliant shadowing configurations and agreements, see the section on dirxadm sob create in the DirX Directory Administration Reference and the chapter “Creating a Shadow DSA” in the Administration Guide.

DSA-Policies

An attribute syntax for attributes that specify DSA policies. This attribute syntax is used solely by the DSAP (DSA-Policy) attribute, which is an attribute of the root DSE. The DSA-Policy attribute, which is accessible only by using dirxadm, defines the bilateral agreements between the present DSA (local DSA) and other remote DSAs known to it.

Synopsis

DsaPolicies = {DSA={DN_string},
    [,OPT=DSA_policy_options]
    [,KL=integer]
    [,TO=integer]
    [,AP={DSA_authentication_policy}]}

Attribute Type

DsaPolicies

The abbreviation or OID that corresponds to a structured attribute with the Dsa-Policies (DSA_POLICIES) syntax. The DSAP attribute is a DSA-specific operational attribute of the root DSE and is accessible only by using dirxadm.

Components

DSA=DN_string

The distinguished name of the DSA to which the policy options apply. This distinguished name is the name of the own DSA or a partner DSA. Specify a value of / (forward slash) to mark the policy as a default for all DSAs for which no specific policy is defined. Note that it is not possible to specify policies for a specific set or group of DSAs.

OPT=DSA_policy_options

Policy options that apply to the interoperation of this DSA with other DSAs. Specify DSA_policy_options as one or more keywords or the value 0 (zero). Separate multiple keywords with the + (plus sign). The keywords are:

  • CHAINING - Indicates that the present DSA is willing to send chained operations to this DSA. This keyword does not affect incoming chained operations. (This is the default value.)

  • LOCAL-DOMAIN - Indicates that the named DSA lies within the same local-domain as the present DSA, for the purpose of the local-scope bit in the service-control options. This option is relevant only if the LSP (Local-Scope-Policy) attribute is set to LOCAL-DOMAIN or DMD.

  • DMD - Indicates that the named DSA lies within the same DMD as the present DSA, for the purpose of the scope-of-referral service control. This option is only relevant if the LSP (Local-Scope-Policy) attribute is set to DMD.

  • COUNTRY - Indicates that the named DSA lies within the same country as the present DSA, for the purpose of the scope-of-referral service control.

Supplying the value 0 for DSA_policy_options means that the local DSA does not chain to this DSA and that this DSA is neither within the same local domain, DMD nor country as the local DSA.

KL=integer

An integer that defines the keep-line policy, a policy that defines the number of seconds a DSA will wait before disconnecting from an idle DSA-to-DSA connection and applies to DSP and DISP protocol. A DSP or DISP association is idle when there are no outstanding operations on it. If you do not specify a keep-line policy, the default value of 86400 seconds (24 hour) will be used.

TO=integer

An integer that defines the time-out policy, a policy that defines the number of seconds the DSA will wait before it aborts a DSP connection with a non-responding partner when performing a bind request. This policy is used to detect communication failures during DSP bind operations. The internal shadowing protocol recovery procedure handles communication failures automatically when performing DISP bind operations.

AP=DSA_authentication_policy

Authentication policy for the DSA. Specify DSA_authentication_policy in the following format:

[AMB={auth_methods}]
[,AMT={auth_methods}]
[,TD=trust_degree]
[,PWD=any_octet_string]
[,CE=credentials_expiration]
[,CV=credentials_validity]

where:

AMB={auth_methods}

Specifies the authentication method for binds allowed from the remote DSA. Only these authentication methods will be accepted by the local DSA for incoming DSP and DISP binds from the remote DSA. The local DSA will use the “strongest” authentication method specified for outgoing DSP and DISP binds to the remote DSA. Currently only the following authentication methods are allowed. Specify auth_methods in the following format:

AM=authentication_methods

A sequence of the following keywords separated by semicolons:

  • NONE - No authentication is performed. (Corresponds to an authentication level of NONE for access control.)

  • SIMPLE - Simple authentication is performed, but no password is supplied. (Corresponds to an authentication level of NONE for access control.)

  • SIMPLE-WITH-PWD - Simple authentication with a password is performed. A DN and password are passed in the clear. (Corresponds to an authentication level of SIMPLE for access control.)

  • SIMPLE-PROTECTED - Simple authentication is performed with a secure token. A DN, password, a random number, and a timestamp are passed after being protected with hashing encoding function. (Corresponds to an authentication level of SIMPLE for access control.)

The default is NONE;SIMPLE;SIMPLE-WITH-PWD;SIMPLE-PROTECTED. A DirX Directory DSA will use as default SIMPLE-PROTECTED for outgoing DSP and DISP binds.

AMT={auth_methods_}

Specifies the authentication methods that must be used by the remote DSA in order to be trusted for a chained operation. Specify auth_methods in the same format as the AMB component.

If you specify the component AMT={auth_methods}, you should specify the component TD=trust_degree.

The default value is to trust all DSAs independent of the authentication method used in the DSP bind.

TD=trust_degree

Specifies the degree of trust allowed to chained operations supplied by the DSA. Specify the trust_degree parameter as one or both of the following keywords:

  • READ - The DSA can grant access to incoming chained Read operations, subject to normal access control.

  • MODIFY - The DSA can grant access to incoming chained Modify operations, subject to normal access control.

If you specify both keywords, separate them with a + (plus sign).

If you specify the component TD=trust_degree, you should specify the component AMT={auth_methods}.

The default value is READ+MODIFY.

PWD=any_octet_string

The password of the DSA whose name is specified in the DSA component of the same attribute value. (This is the own DSA, a possible partner DSA, or a value of / (forward slash - that is all DSAs that are not explicitely listed in one of the DSAP attribute values use this password.)

The DSA uses this password in bind requests and bind results in DSA to DSA communications, for example when performing shadowing (DISP) or chaining (DSP).

The default value is DirXDSA. It is strongly recommended to use an individual password committed by a bilateral agreement.

CE=credentials_expiration

__Specifies the amount of time in seconds after a bind is initiated that the outgoing credentials in DSP and DISP binds will expire. This component is used only with simple-protected authentication. The default is 30.

CV=credentials_validity

__Specifies the time in seconds after a bind is initiated at which the incoming credentials in DSP and DISP binds will expire. This component is used only with simple-protected authentication. The default is 30.

Description

DSA-Policies is a syntax for the DSAP attribute. This attribute controls a DSA’s method of interaction with other DSAs. Specifically, it supplies information about the authentication procedures for DSP and DISP operations. The DSAP attribute is a multivalued attribute. Each value is assigned to a specific DSA or / and contains one or more policy options. The DSAP attribute can be managed only by using dirxadm.

Examples

  1. All DSAs deployed in a common directory service use the same password “dsa_pass“ in their bind operations. All binds are performed using the unprotected credentials that is they send name and password in clear text format. This policy is performed if all DSAs have the following single DSA Policy attribute value stored in their root DSE:

    DSAP={DSA={/},
      OPT=COUNTRY+DMD,
      KL=100,
      TO=60,
      AP={AMB={AM=SIMPLE-WITH-PWD},
          PWD=dsa_pass}

  2. A directory service is distributed over three DSAs named /o=my-company/cn=dsa-sales, /o=my-company/cn=dsa-development and /o=my-company/cn=dsa-hq. According to the policy of the company all DSAs perform bind operations with simple protected credentials based on individual DSA-Passwords. All DSAs trust each other to the "READ+MODIFY" degree (which is the default and can therefore be omitted). In order to perform this policy all DSAs must have the following three attribute values for the DSA Policy attribute stored in their root DSE:

    DSAP={DSA={/O=my-company/CN=dsa-hq},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-PROTECTED},
          TD=READ+MODIFY,
          PWD=pwdHQ01}};
DSAP={DSA={/O=my-company/CN=dsa-development},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-PROTECTED},
          TD=READ+MODIFY,
          PWD=pwdDEV01}};
DSAP={DSA={/O=my-company/CN=dsa-sales},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-PROTECTED},
          TD=READ+MODIFY,
          PWD=pwdSAL01}};

    The only component of the own DSAs Policy value necessary to make the DSA policy work is the PWD component. For example the DSA named /o=my-company/cn=dsa-hq (the first of the three values given above) is:

    DSAP={DSA={/O=my-company/CN=dsa-hq},AP={PWD=pwdHQ01}};

    However, if the full policy is specified for all DSAs the behaviour of the DSAs is automatically correct after a backup-media has been used to switch the roles of the DSAs.

  3. A directory service is distributed over three DSAs named
    /o=my-company/cn=dsa-intern-1, /o=my-company/cn=dsa-intern-2 and
    /o=my-company/cn=dsa-extern. According to the policy of the company all DSAs use individual DSA-passwords. The (internal) DSAs named “dsa-intern-1” and "dsa-inter-2" bind using the simple-protected credential choice and trust each other to perform modification operations. The bind operations performed to the third DSA named “dsa-extern“ use the simple unprotected credential choice. The degree they trust this third DSA is only “READ”. In order to perform this policy the two DSAs named dsa-intern-1 and
    dsa-intern-2 must have the following three attribute values for the DSA Policy attribute stored in their root DSE:

    DSAP={DSA={/O=my-company/CN=dsa-intern1},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-PROTECTED},
          TD=READ+MODIFY,
          PWD=pwdInt1}};
DSAP={DSA={/O=my-company/CN=dsa-intern2},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-PROTECTED},
          TD=READ+MODIFY,
          PWD=pwdInt2}};
DSAP={DSA={/O=my-company/CN=dsa-extern},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-WITH-PWD},
          TD=READ,
          PWD=pwdExt}};

The DSA named "dsa-extern" must have the following three attribute values for the DSA Policy attribute stored in its root DSE:

DSAP={DSA={/O=my-company/CN=dsa-intern1},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-WITH-PWD},
          PWD=pwdInt1}};
DSAP={DSA={/O=my-company/CN=dsa-intern2},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-WITH-PWD},
          PWD=pwdInt2}};
DSAP={DSA={/O=my-company/CN=dsa-extern},KL=100,TO=60,
      AP={AMB={AM=SIMPLE-WITH-PWD},
          PWD=pwdExt}};

Paging-Policies

An attribute syntax for attributes that specify paging policies. This attribute syntax is used solely by the PAGP (Paging-Policy) attribute, which is an attribute of the root DSE. The Paging-Policy attribute, which is accessible only by using dirxadm, defines the configuration parameters for paged results of search requests.

Synopsis

PagingPolicies = {[PTO=timeout]
    [,MAXNUM=max_number]
    [,MAXMEM=max_memory]}

Attribute Type

PagingPolicies

The abbreviation or OID that corresponds to a structured attribute with the Paging-Policies syntax. The PAGP attribute is a DSA-specific operational attribute of the root DSE and is accessible only by using dirxadm.

Components

PTO=timeout

The timeout value in seconds. Search results kept for paged results are released when the specified time period has expired and no subsequent request has been received for the search result. The default value is 300 seconds.

If an LDAP application tries to use an already expired resume/continuation information the paged search operation results in an unwilling to perform the operation error and the LDAP message [DSA]:invalid query ref.

MAXNUM=max_number

The maximum number of results kept for paged results. The default value is 64.

If max_number is too low, a paged search operation may result in an unwilling to perform the operation error and the LDAP message [DSA]: Paging count n exceeded, where n is the currently configured max_number value.

MAXMEM=max_memory

The maximum amount of memory in kilobytes that can be used to save one search result for paged results. The default value is 128 MB.

If max_memory is too low, a paged search operation may result in an unwilling to perform the operation error and the LDAP message [DSA]:Insufficient Paging Memory detected.

Description

For each search operation that contains a paged result request, the DSA initially keeps resume information in memory for efficient processing of subsequent search operations requesting follow-up pages.

Paging-Policies is a syntax for the PAGP attribute. This attribute controls a DSA’s method for handling resume information for search requests. The PAGP attribute is a single-valued attribute. It is valid for all search operations. The PAGP attribute can be managed only by using dirxadm.

Examples

In the following example, resume information kept for paged results is released when no subsequent request has been received for a period of 180 seconds.

Search operations are rejected with the error "Unwilling To Perform" when

  • a search operation containing a paged result request requires to allocate resume information while resume information is kept already for 15 other search operations

  • the resume information exceeds the maximum amount of 2 MB

PAGP={PTO=180,
      MAXNUM=15,
      MAXMEM=2048}

Shadowing-Agreement-Info

A syntax for specifying shadowing or LDIF agreements. This attribute syntax is used in the dirxadm lob and sob create command for the -agreement option and for displaying components of the Cooperating DSA table.

Synopsis

ShadowingAgreementInfo={SS={shadow_subject_unit_of_replication}
    [,CHANGEO=changes_only]
    [,UM={update_mode}]
    [,MAS={master_access_point}]
    [,SEC=secondary_shadows]}

Components

SS=shadow_subject_unit_of_replication

A structured component that defines the information (entries, attributes, and knowledge) to be replicated. This information is known as the “shadow subject” or “unit of replication.” Specify shadow_subject_unit_of_replication in the following format:

AREA={area_specification}
,ATT=attribute_selection
[,KNO={knowledge}]

where:

AREA={area_specification}

Identifies the naming context area to be replicated. Specify area_specification in the form:
CP={context_prefix_distinguished_name},
RA={replication_area_subtree_specification}

where: where:

context_prefix_distinguished_name

Specifies the context prefix of the naming context. This is the distinguished name of the node at the top of the naming context. The value / is root context.

replication_area_subtree_specification

Specifies whether the entire naming context should be replicated or only a subtree within the naming context. Specify replication_area_subtree_specification in the Subtree-Specification attribute syntax format (see Subtree-Specification for details).

ATT=attribute_selection

Filters the attributes to be replicated. In addition to the attributes specified here, access control operational attributes, Creation Time (CRT), Modification Time (MT), and object class attribute are always replicated. Further operational attributes, for example, Creators Name (CRN), must be explicitly included. Specify attribute_selection in one of the following formats:

  • {DEF=TRUE}

    This form causes all user attributes and the operational attributes described above to be replicated.

  • {[ATSCL=object_class_identifier,]CA={ALL=TRUE} |
    {INCL=attribute_list} |
    {EXCL=attribute_list}}
    [;{[ATSCL=…,]CA={…}};…]

    where:

    ATSCL=object_class_identifier_

    Specifies the abbreviation or OID that corresponds to an object class and specifies that the shadow supplier is to perform attribute selection of this class for shadowing. If the class is omitted, the selection applies to all classes.

    CA=…

    Specifies that either all attributes ({ALL=TRUE}) of the specified object class or only a part of the attributes are replicated. Include or exclude attributes by specifying the INCL or EXCL component, where attribute_list specifies one or more abbreviations or OIDs (separated by a semicolon (;)) that correspond to attribute types. INCL explicitly includes and EXCL explicitly excludes attribute types. When using the EXCL component, any attribute contained in an entry, which is not explicitly excluded, is implicitly included in the unit of replication. In case of conflicting specifications, INCL has priority over explicitly excluded attributes and EXCL has priority over implicitly included attributes. If all attributes ({ALL=TRUE}) is not specified, an INCL or an EXCL component must be specified.

KNO={knowledge}

Identifies the knowledge references to be replicated. Specify knowledge in the following form:
KT=*knowledge_type [, EK=*extended_knowledge]

where:

knowledge_type=MASTER | SHADOW | BOTH

Is a keyword that specifies the knowledge types to shadow when subordinate references are encountered at the base of the naming context. Specify the knowledge type with one of the following keywords:

  • MASTER - Shadow only the knowledge reference that references the master DSA for the subordinate naming context

  • SHADOW - Shadow only the knowledge references that reference commonly used shadows of the subordinate naming context. (In practice, this means shadows of the complete naming context, since less complete shadows are not always reliably useful.)

  • BOTH - Shadow both master and commonly used shadow references.

The default value (nothing specified) is that no knowledge references are replicated.

extended_knowledge=TRUE | FALSE

Is a Boolean value that specifies whether or not to replicate extended subordinate references, which are subordinate references that are not immediately subordinate to entries that are shadowed.

CHANGEO=changes_only

A boolean value that specifies whether only updates are saved (TRUE) or a total content file is saved (FALSE). Specify this component only for shadowing operational bindings. For LDIF agreements this behavior is specified in the LDSUPP component of the SOB-Policies. The default is FALSE. If the DSA supports only X.500 compliant shadowing the default value FALSE must be used. For synchronous shadowing agreements, this is the only component that can be specified. (See the sob create operation in the DirX Directory Administration Reference for details.)

UM={update_mode}

A structured component that defines when the replicated entries will be updated and whether the consumer or the supplier should initiate the updates. This component is required for LDIF-agreements and consumer-initiated updates. Specify update_mode in either of the following formats:

  • For supplier-initiated updates and LDIF-agreements, specify update_mode in the format:

    SI={ S={scheduling_parameters} | OC=on_change}

  • For consumer-initiated updates, specify update_mode in the format:

    CI={scheduling_parameters}

For supplier-initiated, consumer-initiated updates and LDIF-agreements, the components
SI={ S={*scheduling_parameters}* | OC=*on_change}* and CI={*scheduling_parameters}* establish the update schedule. Use the SI subcomponent to set up a schedule for supplier-initiated updates and LDIF-agreements or the CI parameter to set up a schedule for consumer-initiated updates. When you specify scheduling parameters, all time units are in seconds.

where:

OC=on_change

on_change_ is a boolean value. The value TRUE means that replicated entries are updated immediately when the master entries are modified or created. The value FALSE means that updates will not be performed automatically. For supplier-initiated updates, the default mode is SI={OC=TRUE}.

scheduling_parameters

Specify scheduling_parameters in the following format:

PS={periodic_strategy}

periodic_strategy is designed to allow shadowing to take place at regular intervals. Specify periodic_strategy in the following format:

WS=window_size,
UI=update_interval
[,BT=begin_time]

where:

WS=window_size

Is an integer that defines the time period in seconds during which the shadow consumer will accept updates from the shadow supplier. A shadow window allows updates to occur at anytime within the window time. It is useful if for some reason the updates are unable to start at the exactly scheduled moment or for a retry if some update failure occurs.

UI=update_interval

Is an integer that specifies in seconds the interval in seconds between the opening of the update windows. For example, if UI is set to 1800 (30 minutes) and WS to 300 (5 minutes), the update cycle is 35 minutes. Updates of up to five minutes in duration can occur every 30 minutes.

BT=begin_time

Is the start-time of the first update window in Generalized Time format. When this start time is after the validity of the shadowing agreement the update cycle begins at this time. (See -validity option of lob and sob create operation in the DirX Directory Administration Reference for details.) Once started the update cycle begins until the shadow agreement is terminated. (See Simple Attribute Syntax for a description of this format.) The default for this subcomponent is the time the shadowing agreement was activated.

MAS=master_access_point

An optional structured component that defines the access point of the master DSA for the naming context. (Note that if secondary shadowing is used the master DSA cannot be the shadow supplier, because a shadow consumer acts also as the shadow supplier for the same information.). The value is optional when the shadowing is primary shadowing (i.e. the supplier is also the master of the information).

Specify master_access_point as an Access-Point attribute. (See Access-Point for details.)

SEC=secondary_shadows

A Boolean value that specifies whether the consumer in this agreement can act as a secondary shadow to the shadow supplier. Secondary shadow consumers can shadow the shadowed information on to other DSAs. The value is represented using BOOLEAN attribute syntax. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.). The default is FALSE (secondary shadows are not allowed).

Description

Information pertaining to a shadow agreement between supplier and consumer DSA or an LDIF agreement is represented with the Shadowing-Agreement-Info component syntax. This syntax is only used for specifying the value of the -agreement parameter in the dirxadm lob and sob create command and for displaying components of the Cooperating DSA table. It describes a shadowing agreement, which basically defines:

  • What is being replicated, known as the “unit of replication”. (The SS subcomponent attribute.)

  • When updates of the replicated entries should take place and who initiates the update process. (The UM subcomponent attribute.)

  • The access point of the master DSA, if necessary. (The MAS subcomponent attribute.)

  • Whether secondary shadows are allowed. (The SEC subcomponent attribute.)

Example

{SS={AREA={CP={/O=My-Company},
           RA={DEF=TRUE}
          },
     ATT={DEF=TRUE}
    },
 UM={SI={S={PS={WS=3600,
             UI=86400,
             BT=19970101230000Z
               }
            }
        }
    }
}

{SS={AREA={CP={/O=My-Company},
           RA={BAS={/O=sales},
     EXCL={CHB={/OU=ABC/OU=DEF}};
     MAX=10,
     SF={ITEM=PER}
     }
   },
 KNO={EK=TRUE,KT=MASTER},
 ATT={DEF=TRUE}
 }
}

{SS={AREA={CP={/O=My-Company},
           RA={BAS={/O=sales},
     EXCL={CHB={/OU=ABC/OU=DEF}};{CHA={/OU=XYZ}},
     MAX=10,
     }
   },
 KNO={EK=TRUE,KT=MASTER},
 ATT={DEF=TRUE}
 }
}

{SS={AREA={CP={/O=My-Company},
           RA={BAS={/OU=Sales}}
          },
     KNO={EK=TRUE,KT=MASTER},
     ATT={CA={INCL=CRN}};		includes operational attribute
                            		Creator´s Name
         {CA={EXCL=O;L;DSC}};		excludes attributes Organization,
                         		Locality, and Description
         {ATSCL=ORP,CA={ALL=TRUE}}	includes all attributes of object
                                 	class Organizational Person
                                	(inclusive O, L, and DSC of ORP)
                               	and implicitly includes all user
                               	attributes that are not
                               	explicitly excluded here
    }
}

{SS={AREA={CP={/O=Air.com},RA={DEF=TRUE}},
                        ATT={DEF=TRUE}},
                 UM={SI={OC=TRUE}}}

SOB-Policies

A syntax for specifying policies for shadowing operational bindings like shadowing or LDIF agreements. This attribute syntax is used in the dirxadm lob and sob create command for the -pol option.

Synopsis

SOBPolicies={DEF=TRUE} |
    {[MAS=sob_master_policies]
    [,INI=sob_initiator_policies]
    [,SUPP=sob_supplier_policies]
    [,CONS=sob_consumer_policies]
    [,LDSUPP=sob_ldif_supplier_policies]}

Components

DEF=TRUE

Specifies that default policies should be used. See the other components for a description of the default policies.

MAS=sob_master_policies

Specifies the policies used for master shadowing agreements. Specify sob_master_policies in the following format:

{[MAXJSZ=max_journal_size]
[,MAXJFIL=max_journal_files]}

where:

MAXJSZ=max_journal_size

Specifies the maximum amount of disk space in kilobytes used by shadowing operational binding journal files. The value of 0 (zero) indicates that an unlimited amount of disk space can be used. The default value is unlimited.

MAXJFIL=max_journal_files

Specifies the maximum number of journal files for the shadowing operational binding. The value of 0 (zero) indicates that an unlimited number of files can be used. The default value is unlimited.

INI=sob_initiator_policies

Specifies the policies used for initiator shadowing agreements. These components should only be administered if you want to manipulate the default values of the error recovery. If it is useful, an error recovery is performed automatically; that is, for example, when the server is temporarily shut down. Specify sob_initiator_policies in the following format:

{[RMR=recovery_max_retries]
    [,RTO=recovery_timeout]
    [,RI=recovery_interval]
    [,RD=recovery_divisor]
    [,ATU=automatic_total_update]}

where:

RMR=recovery_max_retries

Specifies the maximum number of retries of recovery for shadowing agreements with the DSA specified in the *DSA=*DN_string component of a DSAP attribute where the local DSA is the initiator. The default is 20 .

If the RTO=recovery_timeout and the *RMR=*recovery_max_retries components are equal to 0, recovery is configured as unlimited (that is, there is no limitation by timeout or by number of retries, and recovery never stops).

If either the *RTO=*recovery_timeout or the RMR=recovery_max_retries component is equal to 0 (and the other one is equal to a non-zero value), no recovery will be done.

If the RTO=recovery_timeout and the *RMR=*recovery_max_retries components are equal to a non-zero value, recovery will be attempted until both values have been exceeded.

RTO=recovery_timeout

Specifies the timeout in seconds of a recovery attempt for shadowing agreements with the DSA specified in the *DSA=*DN_string component of a DSAP attribute where the local DSA is the initiator.

The default is 1200 (that is, 20 minutes). The minimum value is 300 (that is, 5 minutes). If the specified value is less than this minimum value the minimum value is used automatically.

If the *RTO=*recovery_timeout and the *RMR=*recovery_max_retries components are equal to 0, recovery is configured as unlimited (that is there is no limitation by timeout or by number of retries, and recovery never stops).

If either the *RTO=*recovery_timeout or the *RMR=*recovery_max_retries component is equal to 0 (and the other one is equal to a non-zero value) no recovery will be done.

If the *RTO=*recovery_timeout and the *RMR=*recovery_max_retries components are equal to a non-zero value, recovery will be attempted until both values have been exceeded.

RI=recovery_interval

Specifies the time interval in seconds between the end of a recovery attempt and the start of the next attempt for shadowing agreements. This component is relevant only for the shadowing agreements with the DSA specified in the DSA=DN_string component of a DSAP attribute where the local DSA is the initiator and the UM={update_mode} component of the Shadowing-Agreement-Info is OC=TRUE (on_change). (See Shadowing-Agreement-Info for details.)

The default is 240 (that is, 4 minutes). The minimum value is 120 (that is, 2 minutes). If the specified value is less than this minimum value, the minimum value is used automatically.

RD=recovery_divisor

Specifies the time interval between two recovery attempts for shadowing agreements and is the window_size divided by the recovery_divisor. This component is relevant only for the shadowing agreements with the DSA specified in the DSA=DN_string component of a DSAP attribute where the local DSA is the initiator and the UM={update_mode} component of the Shadowing-Agreement-Info is periodic_strategy. (See Shadowing-Agreement-Info for details.) The default is 16.

ATU=automatic_total_update

A Boolean value that specifies whether the initiator DSA performs a total update automatically if it is required by the cooperating DSA (TRUE) or the administrator must trigger off the total update by performing a sob establish operation (FALSE). The default is FALSE. If the DSA supports only X.500-compliant shadowing, the default value FALSE must be used. (See the sob create operation in the DirX Directory Administration Reference for details.)

SUPP=sob_supplier_policies

Specifies the policies used for supplier shadowing agreements. Specify sob_supplier_policies in the following format:

{[US=supplier_update_strategy]
[,MAXLOC=max_local_memory]
[,MAXOSK=max_old_segments_kept]
[,MAXICON=max_incremental_confirmations]}

where:

US=supplier_update_strategy

Specifies the standard supplier update strategy that the shadow supplier intends to use for the updates. The first shadowing operation involves a total update and subsequent operations an incremental update of the unit of replication. Specify one of the following keywords:

  • TOTAL-INCR - the pure X.525 standard strategy. This strategy is recommended for interworking.

  • SEGM-TOTAL-INCR - a standard conformant DirX Directory extension that overcomes the resource limitations of the standard mechanism by segmenting the messages. This is the default strategy if no value for US is specified.

The supplier and the consumer must use the same update strategy for a shadowing operational binding.

+ The use of the following components is recommended to avoid bottlenecks when processing the data to update the unit of replication:

MAXLOC=max_local_memory

Specifies the maximum amount of memory in kilobytes to be used to create the data to update the unit of replication.

The value 0 (zero) indicates that an unlimited amount of memory can be used. (Keep in mind that the limits imposed by DIRX_CTX_LIMIT always apply. See DIRX_CTX_LIMIT in section DirX Directory Environment Variables in the DirX Directory Administration Reference for details.) The default value is 512.

MAXLOC should be big enough to take up the largest entry to transfer. The average size of an entry is about 2 KB. To create a replication unit with at least one entry the DSA consumes additional memory for protocol information. For a 2 KB entry the DSA consumes about 6 KB. If the specified value is not big enough to create a replication unit with at least one entry the DSA automatically allocates the necessary size of memory.

Specifying a low value for MAXLOC results in a low consumption of temporary memory for the outgoing shadowing operation.

If the update strategy is TOTAL-INCR, MAXLOC is effective only for incremental updates. For total updates, MAXLOC is ignored.

If the update strategy is SEGM-TOTAL-INCR, MAXLOC is effective for both, incremental and segmented-total updates.

MAXOSK=max_old_segments_kept

Specifies the maximum number of old shadowing operational binding update history segment files saved in case of incremental updates. A value lower or equal 1 indicates that 2 files are saved. The default is 2.

MAXICON=max_incremental_confirmations

Specifies the maximum number of incremental update refreshes sent in a sequence of segmented incrementals without starting a complete new update cycle. A complete new update cycle requires a new bind and coordination before the incremental update can be performed. This component is only used in case of incremental refreshes, the supplier_update_strategy is SEGM-TOTAL-INCR, and the update_mode (see Shadowing-Agreement-Info for details) is scheduled OC=TRUE (on_change).

This component is useful only for units of replication with a high update frequency. In this case, it can happen that after a single update is confirmed by the consumer, new updates may be ready for transmission on the supplier side.

A value less than or equal to 1 indicates that each transmission is confirmed. The default is 1.

CONS=sob_consumer_policies

Specifies the policies used for consumer shadowing agreements. Specify sob_consumer_policies in the following format:

{[US=consumer_update_strategy]
[,MAXLOC=max_local_memory]
[,REPLS=replace_supplier]}

where:

US=consumer_update_strategy

Specifies the standard consumer update strategy that the shadow consumer requests. The first shadowing operation involves a total update and subsequent operations an incremental update of the unit of replication. If the database becomes inconsistent, the consumer requests a total refresh of the unit of replication. Specify one of the following keywords:

  • TOTAL-INCR - the pure X.525 standard strategy. This strategy is recommended for interworking.

  • SEGM-TOTAL-INCR - a standard-conformant DirX Directory extension that overcomes resource limitations of the standard mechanism by segmenting the messages. This is the default consumer update strategy if no value for US is specified.

The supplier and the consumer must use the same update strategy for a shadowing operational binding.

The use of the following component is recommended to avoid bottlenecks when processing the data to update the unit of replication:

MAXLOC=max_local_memory

Specifies the maximum amount of memory in kilobytes to be used to create the data to update the unit of replication.

This policy has no effect on consumer DSAs.

REPLS=replace_supplier

A boolean value that specifies whether the consumer DSA can become the supplier of the shadowing agreement when performing a sob switch operation (TRUE) or a sob switch operation is always rejected (FALSE). The default is FALSE. If the DSA supports only X.500 compliant shadowing the default value FALSE must be used. (See the sob create operation in the DirX Directory Administration Reference for details.)

LDSUPP=sob_ldif_supplier_policies

Specifies the policies used for LDIF agreements. Specify sob_ldif_supplier_policies in the following format:

{[BAS64=base64_encoding]
[,CHANGEO=changes_only]
[,CS=codeset]
[,CRLF=cr_and_lf_separator]
[,ENTRYO=entry_only]
[,MAXROW=max_rows]
[,{DELAT=delete_attr_info | DELATLIST=attribute_list}]
[,{MODAT=modify_attr_info | MODATLIST=attribute_list}]
[,PROG=program_name]}

where:

BAS64=base64_encoding

Specifies a Boolean value that specifies whether Base-64 encoding is performed (TRUE) for attribute values and distinguished name strings containing values lower than 32 (SPACE character) or greater than 126 (∼) (not printable data) or Base-64 encoding is not performed (FALSE). The default is FALSE.

CHANGEO=changes_only

Specifies a Boolean value that specifies whether only updates are saved (TRUE) or a total content file is saved (FALSE). The default is FALSE.

CRLF=cr_and_lf_separator

Specifies a boolean value that specifies whether carriage-return and line-feed (TRUE) or only carriage-return (FALSE) is used as a separator. The default is FALSE.

CS=codeset

Specifies the character set for the encoding in which printable data are saved in the file. Specify one of the following keywords:

  • LATIN1 - The data are saved in Latin1 format as specified in ISO8859-1. If you specify Latin1 format you must ensure that your tools can process the files because Latin1 is a non-standard code set for LDIF files.

  • UTF8 - The data are saved in UTF-8 format.

The default is UTF8.

ENTRYO=entry_only

Specifies a Boolean value that specifies whether the entry is saved only with user attributes and the operational attributes Creation Time and Modification Time (TRUE) or all entry information (user attributes, all operational attributes, references and subentries) is saved (FALSE). The default is FALSE.

MAXROW=max_rows

Specifies the maximum number of characters per line. The default is 80.

DELAT=delete_attr_info

Specifies a Boolean value that specifies whether attribute types and values of a deleted entry or attribute are saved (TRUE) or not (FALSE). The default is FALSE.

DELATLIST=attribute_list

Specifies that only a part of attribute types and values of a deleted entry or attribute is to be saved. attribute_list specifies one or more abbreviations or OIDs (separated by a semicolon (;)) that correspond to the attribute types to be saved.

MODAT=modify_attr_info

Specifies a Boolean value that specifies whether attribute types and values of a modified entry or attribute are saved (TRUE) or not (FALSE). The attribute values represent the values before the modify operation. Attributes with a distinguished name part are not saved. The default is FALSE.

MODATLIST=attribute_list

Specifies that only a part of attribute types and values of a modified entry or attribute is to be saved. attribute_list specifies one or more abbreviations or OIDs (separated by a semicolon (;)) that correspond to the attribute types to be saved. The attribute values represent the values before the modify operation. Attributes with a distinguished name part are not saved.

PROG=program_name

Specifies an IA5 string that specifies a command string to be performed after the creation of the file in LDIF format has been completed. Note that the DSA uses umask 00 and does not change or restrict access rights automatically; that is the files created by procedure will have read and write permission for owner group and everyone unless the called procedure sets umask according to the particular requirements.

When this policy is omitted, see the lob create command in the DirX Directory Administration Reference for information on how to export the file.

This policy can be used as follows:

  • Simple use (only on Linux systems):
    The string specifies the name of an executable, for example /usr/bin/mail, that is invoked after the creation of the LDIF file has completed. The string must not contain the character %. The LDIF file is directed to standard input of the executable. After the executable has completed, the LDIF file is removed and the exit code is evaluated. An exit code of 0 indicates success. An exit code of 1 indicates a temporary error; in this case, the LDIF agreement is scheduled for error recovery. Another exit code indicates a permanent error; in this case, the LDIF agreement is disabled.

  • Advanced use:
    The string specifies the name of an executable to be invoked after the creation of the LDIF file has completed. The string can contain macros (starting with the character %) to be replaced before the executable is invoked. You can specify one or more of the following macros:

    %F - is replaced by the LDIF file name. This macro is required on Windows systems. When this macro is omitted on Linux systems, the LDIF file is directed to standard input of the executable as described above.

    %U - is replaced by the current update time. The update time is specified in Generalized Time syntax as specified in RFC 2252. (See section Generalized Time Syntax details.)

    %L - is replaced by the last update time. The last update time is specified in Generalized Time syntax as specified in RFC 2252. (See section Generalized Time Syntax details.) A value of NONE indicates that this agreement is processed the first time after establishing the LDIF agreement. (See the lob establish command in the DirX Directory Administration Reference for details.)

    %S - indicates the kind of content that was or will be created. This macro is replaced by one of the following keywords:

    CONTENT-FILE - indicates an LDIF content file (the total content was saved).
    CHANGE-LOG - indicates a change log file (only updates were saved).
    NO-CHANGE - indicates an empty change log file (no updates occurred).

    %A - is replaced by the agreement identifier (without the version number) in numerical string format.

    %% - is replaced by %.

    %*any - is replaced by any where any is a character other than the macros described above, the macro *%P (see coordinated advanced use below for details), and the macro %V (see recommendations for troubleshooting below for details).

    Other parameters are given to the executable as specified.

    After the command has completed, the LDIF file is removed and the exit code is evaluated. An exit code of 0 indicates success. An exit code of 1 indicates a temporary error; in this case, the LDIF agreement is scheduled for error recovery. Another exit code indicates a permanent error; in this case, the LDIF agreement is disabled.

  • Coordinated advanced use:
    When the macro %P (indicating the processing state) and at least the macro %U or %L (see advanced use for details) are specified, the executable is invoked before the LDIF agreement is processed. In this case, the %P macro is replaced by the keyword COORDINATE. The %F macro is replaced by the keyword NO-FILE and / or no redirection of standard input is performed. The executable may check the last update time, upgrade from a change log file format to a content file format, or discard LDIF files and restart recording of history. After the executable has completed, the exit code is evaluated:

    An exit code of 0 indicates success; in this case, an LDIF file is created and the executable is invoked a second time. (The macro %P is replaced by the keyword UPDATE.)

    An exit code of 1 indicates a temporary error; in this case, the LDIF agreement is scheduled for error recovery.

    An exit code of 5 indicates that the current (total) content file or change log file should be discarded, but the update history should be recorded and a change log file should be created when processing the LDIF agreement next time. In this case, the executable is invoked a second time without creating an LDIF file. (The macro %P is replaced by the keyword UPDATE, %S is replaced by the keyword DISCARDED, and %F is replaced by the keyword NO-FILE.)

    An exit code of 2 indicates that a (total) content file is required, an exit code of 3 indicates that a previous LDIF file is missing, an exit code of 4 indicates that the corresponding LDIF file has already been received. In these cases, the executable is invoked a second time without creating an LDIF file. (The macro %P is replaced by the keyword COORDINATE.) After the executable completes, the exit code is evaluated. Only exit code of 0 ((total) content file is created) or 5 (content/change file is discarded) are accepted. The executable is invoked again. (The macro %P is replaced by the keyword UPDATE.)

    Any other exit code indicates a permanent error; in this case, the LDIF agreement is disabled.

  • Recommendations for troubleshooting:
    The command string prog_name may contain the name of an existing program (e.g. /usr/bin/mail on Linux systems), a Linux shell script, or a self-written application. These executables should not use the exit codes -1, -2, and -3 because they are used internally with the following meanings:

    -1: On Windows systems, create process failed. On Linux systems, fork failed.
    -2: On Windows systems, macro %F is missing. On Linux systems, exec failed.
    -3: The DSA was stopped (for example, by performing the dirxadm operation
    sys stop) or the LDIF agreement was terminated (for example, by performing the
    dirxadm operation lob terminate).

    On Windows systems, system information (for example, function return codes of system operations) is saved in the USR log file.

    Use the macro %V to get additional diagnostic and system information on Linux systems. Using %V causes stderr to be directed to a file with the LDIF file name to which an e has been appended. (See the dirxadm lob create operation in the DirX Directory Administration Reference for details on the LDIF filename.) Diagnostic, error and system messages are written to this file. The Linux shell option -x can be used to trace the processing of shell scripts into this file. On Windows systems, the macro %V is ignored.

The following figure illustrates the general processing while the prog_name policy is performed.

General processing of the <em>prog_name</em> policy

Description

Information pertaining to policies for a shadow agreement between supplier and consumer DSA or an LDIF agreement is represented with the SOB-Policies attribute syntax. This syntax is only used for specifying the value of the -pol parameter in the dirxadm lob and sob create command and for displaying components of the Cooperating DSA table. It describes the following policies:

  • Master-SOB-Policies (the MAS component), which defines the use of system resources such as disk space limitations (the MAXJSZ subcomponent) and file limitations (the MAXJFIL subcomponent).

  • Initiator-SOB-Policies (the INI component), which defines the error recovery for initiator shadowing agreements.

  • Supplier-SOB-Policies (the SUP component), which defines the update strategy in use (the US subcomponent) and the use of system resources.

  • Consumer-SOB-Policies, which defines the update strategy in use (the US subcomponent) and the memory limitation (the MAXLOC subcomponent).

  • LDIF-Supplier-SOB-Policies (the LDSUPP component) which basically defines the LDIF file format.

The following restrictions apply for specifying the value of the -pol parameter in the dirxadm lob and sob create command:

  • Specify either a Supplier-SOB-Policy or a Consumer-SOB-Policy or an LDIF-Supplier-SOB-Policy according to the agreement created by the dirxadm lob and sob create command.

  • Master-SOB-Policies can only be specified for primary shadowing operational bindings.

  • Initiator-SOB-Policies can only be specified for initiator agreements. (The updates are supplier-initiated or consumer-initiated. See also UM component of Shadowing-Agreement-Info attribute syntax for details.)

  • Supplier-SOB-Policies are usually specified for non-LDIF agreements. When specified for LDIF agreements only the MAXLOC subcomponent is evaluated. All other subcomponents are ignored.

  • Consumer-SOB-Policies can only be specified for non-LDIF agreements.

  • LDIF-Supplier-SOB-Policies can only be specified for LDIF agreements.

When entries greater than 512 KB should be saved in an LDIF file a Supplier-SOB-Policy must be specified. The MAXLOC subcomponent must be specified accordingly.

If no policy is specified, useful default policies are performed. When specifying the value of the
-pol parameter in the dirxadm lob and sob create command, the policies are performed only for the agreement created by this dirxadm lob and sob create command.

The LDSUPP LIDF agreement policy subcomponents DELAT, DELATLIST, MODAT, and MODATLIST add additional non-standard information to generated LDIF files that standard LDIF file parsers cannot process. Use these components only in LDIF synchronization environments that provide customized LDIF parsing tools to handle these policies.

Example

{INI={RMR=20,RTO=1200,RI=240,RD=16,ATU=TRUE}}

{SUPP={US=TOTAL-INCR,MAXLOC=1024}}

{CONS={US=TOTAL-INCR,MAXLOC=2048,REPLS=TRUE}}

{LDSUPP={CRLF=TRUE,MAXROW=132}}

{LDSUPP={CRLF=TRUE,MAXROW=132,DELAT=TRUE,MODAT=TRUE}}

{LDSUPP={CRLF=TRUE,MAXROW=132,DELATLIST=L;UID;RMB,MODATLIST=UID}}

{MAS={MAXJSZ=1000,MAXJFIL=20},
 LDSUPP={CRLF=TRUE,MAXROW=132}}

{LDSUPP={CRLF=TRUE,MAXROW=132,
         PROG=/usr/bin/mail John.Smith@my-company.net}}
		On Linux systems, after the creation of the file in LDIF
 		format has completed successfully the file is sent by
 		e-mail to John Smith.

{LDSUPP={CRLF=TRUE,MAXROW=132,
         PROG=ldif-process p1 p2 %A %S %F p6 p7}}
		After the creation of the file in LDIF format has
 		completed successfully the macros %A, %S, and %F are
 		replaced and then the executable ldif-process is
 		performed. Note that p1, p2, p6, and p7 are also input
 		parameters of ldif-process and are given to the process
 		as specified.
 		Commandline:
 		  ldif-process p1 p2 1001 CHANGE-LOG 0009.04789p p6 p7
 		  where 1001 is the LDIF agreement identifier and
 		  0009.04789p is the temporary LDIF file name

{LDSUPP={CRLF=TRUE,MAXROW=132,
         PROG=ldif-process p1 %P %A %S %F %U}}
		Before starting the creation of the file in LDIF format
 		the macros (starting with a %) are replaced and the
 		the executable ldif-process is invoked. Depending on
 		the exit code of ldif-process, the LDIF file is created
 		or not and then the ldif-process is invoked a second
 		time.
 		Commandline (1. call before processing the LDIF
 		agreement):
 		  ldif-process p1 COORDINATE 1001 CHANGE-LOG NO-FILE
 		       19990105060000Z
		  where 1001 is the LDIF agreement identifier and
 		  19990105060000Z is the current update time.
 		Exit code of ldif-process is 0:
 		  The LDIF agreement is processed and an LDIF change log
 		  file is created.
 		Commandline (2. call after the creation of the LDIF file
 		has been finished):
		  ldif-process p1 UPDATE 1001 CHANGE-LOG 0009.04789p
 		       19990105060000Z
		  where 1001 is the LDIF agreement identifier,
 		  0009.04789p is the temporary LDIF file name
 		  19990105060000Z is the current update time.

{LDSUPP={ENTRYO=TRUE,
PROG=/"C:///Multimedia Files///tmp///trigger.bat/" %F %U %L %S }}
		On Windows systems, after the creation of the file in
 		LDIF format has completed successfully the file is
 		processed by the application trigger.bat.

Update-Status

An attribute syntax for attributes that hold the update status about the administered operational bindings with partner DSAs or LDIF agreements. The Update-Status attribute syntax is only used for display purposes of the dirxadm lob and sob show command; it cannot be used for input.

Synopsis

US={[D=disabled]
    US=update_status_info}

Components

D=disabled

A boolean value that indicates whether the agreement is disabled (TRUE), e.g. because errors occurred and the administrator´s intervention is necessary before the agreement can be enabled again, or enabled (FALSE). The default value is FALSE.

US=update_status_info

A structured component that specifies the status of the supplier or consumer update. update_status_info is displayed in the following format:

{[SUS=supplier_update_status] | [,CUS=consumer_update_status]}

where:

SUS=supplier_update_status

Specifies the status of supplier updates. supplier_update_status is in the following format:
{AC=area_changes,OU=old_updates,FU=last_failed_update,NUT=next_update_time,AU=actual_update}

The AC=area_changes component is one of the following keywords:

  • NO-CHANGES - indicates that area changes were not made since last replication was performed.

  • CHANGED - indicates that changes inside the replicated area were made since last replication was performed or during performing replication, which were not yet successfully shadowed to the consumer DSA.

  • TOUCHED - indicates that changes inside the replicated area since last replication was performed were made and the replication of this changes is in progress.

The OU=old_updates component contains the updates successfully sent by the supplier. old_updates is displayed in the following format:

{SID=segment_id,UT=update_time,OPMSN=operation_msn AC=area_changes}[;{...}]

The SID=segment_id component is an integer value identifying a time segment. It indicates which changes were shadowed within this update. For instance, SID=3 means that all changes done until the end of the time segment 3 were transmitted within this update.

The UT=update_time component is a time string in Generalized-Time format. It is the time at which the update was performed.

The OPMSN=operation_msn component is an integer value identifying the modification sequence number (MSN) of the last confirmed operation. This component is relevant only for synchronous shadowing agreements (the –consumerkind option is set to SYNCHRON in the dirxadm sob create operation).

The AC=area_changes component is a boolean value. A value of TRUE indicates that the update contained area changes. The value FALSE is only possible with a scheduled update strategy, and indicates that this update was an incremental update with no changes.

The FU=last_failed_update component contains the update last recently failed. The failing update information is displayed whenever the DSA failed to send a shadowing PDU to the consumer DSA. The supplier DSA performs an error recovery procedure and re-tries to send the same request after the time interval specified in the Retry-Interval component of the SOB initiator policy or after 4 minutes by default. The FU component is cleaned up after a successful recovery. last_failed_update is displayed in the following format:

{SID=segment_id,UT=update_time,AC=area_changes,FR=error_code}

The SID=segment_id component is an integer value identifying a time segment. It indicates which changes were shadowed within this update. For instance, SID=3 means that all changes done until the end of the time segment 3 were transmitted within this update.

The UT=update_time component is a time string in Generalized-Time format. It is the time at which the update was performed.

The AC=area_changes component is a boolean value. A value of TRUE indicates that the update contained area changes. The value FALSE is only possible with a scheduled update strategy, and indicates that this update was an incremental update with no changes.

The FR=error_code component is an integer value indicating the reason for the un-successful attempt to sent this update.

The NUT=next_update_time component is a time string in Generalized-Time format. It is the time at which the next update is performed. This update is the next scheduled update or if the FU component is displayed the next attempt to sent this update last recently failed.

The AU=actual_update component contains information about the ongoing shadowing update the supplier DSA is sending to the consumer. actual_update is displayed in the following format:

{WS=waiting_state,SID=segment_id,UT=update_time,AC=area_changes,OS=offset,MC=modification_count,LUE=last_updated_entry}

The WS=waiting_state component contains information about the state of the shadowing protocol handler with respect to the ongoing shadowing request. The value is one of the following keywords:

  • INVOKED - indicates that the supplier has started to send a bind request or an update request to the consumer DSA.

  • WAIT_BIND_RESPONSE - indicates that the supplier DSA is waiting for a response of the consumer DSA to the bind request. After a successful bind the supplier DSA starts to send update requests.

  • WAIT_COORD_RESPONSE - indicates that the supplier DSA is waiting for a response of the consumer DSA that it is ready to receive the next update request.

  • SENT_UPDATE - indicates that the supplier DSA has sent one of several update messages and is collecting the next update message from its local database.

  • WAIT_UPDATE_RESPONSE - indicates that the supplier DSA is waiting for the response of the consumer DSA to the last recently sent update request. The next update request to send is ready at that time. After a successful update the supplier DSA sends the next update request.

If the current update is an incremental one the following components are present:

The SID=segment_id component is an integer value identifying a time segment. It indicates which changes were shadowed within this update. For instance, SID=3 means that all changes done until the end of the time segment 3 were transmitted within this update.

The UT=update_time component is a time string in Generalized-Time format. It is the time at which the update was performed.

The AC=**area_changes component is a Boolean value. A value of *TRUE indicates that the update contained area changes. The value FALSE is only possible with a scheduled update strategy, and indicates that this update was an incremental update with no changes.

The OS=offset component is an integer value providing the offset in the journal file to the update request the supplier DSA is sending.

The MC=modification_count component is an integer value providing the number of update requests that the supplier DSA has sent so far for the ongoing shadowing update.

The LUE=last_updated_entry component is the distinguished name of the last recently updated entry.

CUS=consumer_update_status

Specifies the status of consumer updates. consumer_update_status in the following format:

{LU=last_update,CUS=cons_upd_stat}

The last_update parameter is a time string in Generalized Time format that specifies the time of the last update to the DIB. (See the DirX Directory String Representation chapter for a description of Generalized Time syntax.)

The cons_upd_stat parameter is one of the following keywords:

  • TOTAL-UPDATE - indicates that the databases are not synchronized (e.g. replication was not yet started or errors occurred during the last replication process, for example the DSA was stopped).

  • INCREMENTAL-UPDATE - indicates that the databases are synchronized (replication was started and the updates were transferred successfully).

  • TOTAL-RUNNING - indicates that a total update is in progress.

  • INCREMENTAL-RUNNING - indicates that an incremental update is in progress.

Description

The Update-Status is maintained by the DSA. It displays the current and planned updates of operational bindings between the present DSA and other DSAs or of LDIF agreements. DirX Directory supports only shadowing operational bindings (SOB). The Update-Status attribute syntax is only used for display purposes of the dirxadm lob and sob show command; it cannot be used for input.

Examples

US={D=FALSE,US={SUS={AC=CHANGED}}}

User-Policies

An attribute syntax used solely for the User Policy (USP), the attribute of the root DSE that specifies policies for DAP users, discriminating between them by name.

Synopsis

UserPolicies = {USN={DN_string}
    [,OPT=user_policy_options]
    [,AP={USER_authentication_policy}]
    [,SL=size_limit]
    [,PRSL=paged_result_size_limit]
    [,SPL=single_page_limit]
    [,ALS=attribute_limit:size] }

Attribute Type

UserPolicies

The abbreviation or OID that corresponds to a structured attribute with the User-Policies (USR_POLICIES) syntax. For example, the USP (User Policy) is such an attribute. The USP attribute is a DSA-specific operational attribute of the root DSE, and is accessible with dirxadm only.

Components

USN=DN_string

The distinguished name of a user, or the name of a group or a subtree name. The group can either be a groupOfNames (with member attributes) object including nested group support (auxiliary object class dirxImportGroup), or a groupOfUniqueNames (with uniqueMember attributes) object, or a dynamic group group object (object class dirxGroupOfUrls, attribute dirxMemberUrl).

Concerning the precedence of User Policy attributes, it is the specificity of the username that controls which value is relevant. During the bind operation, the DSA checks the User Policy (USP) attributes in the following order:

  • If the user’s distinguished name is found in the USN component of a User Policy, this user policy is the relevant one.

  • If there is a User Policy for a group of which the user is a member, this user policy is the relevant one. If the user is a member of more than one group occurring in USPs, the relevant user policy is constructed from the most restrictive policy settings of all user policies for groups of which the user is a member.

  • If there is a User Policy for a subtree under which the user’s entry is located, the lowest name defines the applicable user policy. Specify DN_String as a forward slash (/) to apply the user policies to all otherwise unspecified users.

OPT=user_policy_options

Policy options that specify whether the user can access the services of a DSA that can chain the user’s operations, if necessary, and perform modify operations or search operations resulting in a sequential scan of the database.

Specify user_policy_options as one or more keywords or the value 0 (zero). Separate multiple keywords with the + (plus sign). The keywords are:

  • CHAINING - Permits the DSA to generate chained operations on behalf of the user

  • MODIFY - Permits the DSA to carry out local modify operations on behalf of the user

  • SEQSEARCH - Permits the DSA to carry out subtree and one-level search operations that result in a sequential scan of the database on behalf of the user. The DSA performs a sequential scan if there is no index present for the matching rule specified and the attribute type used. For NOT filter items the ANY and the INITIAL/FINAL index are required to avoid a sequential scan. Regardless of the value of this option the sequential search is permitted if there are less than 128 entries located below the search base.

    A contains filter searching for a single character contained in an attribute value, for example cn=*a*, is always - independent from the presence of a CONTAINS index - performed as a sequential scan. It is rejected if the user policy denies sequential searches.

The default behavior of the DSA is to permit all options.

Supplying the value of 0 for user_policy_options means that the DSA will not perform chaining, modify operations, and sequential search operations on behalf of the user.

AP=user_authentication_policy

Authentication policy for the user. Specify user_authentication_policy in the following format:

[AMB={auth_methods}]
[,OPWD=any_octet_string]
[,CV=credentials_validity]

where:

AMB={auth_methods}

Specifies the authentication methods allowed for the user. Currently only the following authentication methods are allowed. Specify auth_methods in the following format:

AM=authentication_methods

The authentication_methods parameter is a sequence of the following keywords separated by semicolons:

  • NONE - No authentication is performed. (Corresponds to an authentication level of NONE for access control.)

  • SIMPLE - Simple authentication is performed, but no password is supplied. (Corresponds to an authentication level of NONE for access control.)

  • SIMPLE-WITH-PWD - Simple authentication with a password is performed. The user’s DN and password are passed in the clear. (Corresponds to an authentication level of SIMPLE for access control.)

  • SIMPLE-PROTECTED - Simple authentication is performed with a secure token. A DN, password, a random number, and a timestamp are passed after being protected with hashing encoding function. (Corresponds to an authentication level of SIMPLE for access control.) The LDAP protocol does not support this method.

  • STRONG - Strong authentication is based on public key cryptography. This is the case for ldap sasl bind operations with mechanism EXTERNAL.

The default is NONE;SIMPLE;SIMPLE-WITH-PWD;SIMPLE-PROTECTED;STRONG.

OPWD=any_octet_string

Specifies the password returned to the user by the DSA (if necessary) to validate the DSA. (Used only for SIMPLE-PROTECTED authentication.)

CV=credentials_validity

Specifies the time period in seconds which is added to the expiration time of an incoming credential in order to check the credential’s validity. (Used only with SIMPLE-PROTECTED authentication.)
The default is 30.

SL=size_limit

Specifies the maximum number of entries of a search result for a search operation without paging. A smaller value of size_limit overrules the size limit specified in the search request of the client. If the number of entries to be returned exceeds the size_limit value the DSA returns size_limit entries and a SIZE LIMIT EXCEEDED return code. The LDAP client, for example dirxcp, receives size_limit SearchResultEntry messages and a SearchResultDone message containing sizeLimitExceeded resultCode. (See also Managing Huge Search Results in chapter Managing Miscellaneous Scenarios in the Administration Guide.)

A value of -1 is unlimited. The default value for size_limit is 2048.

PRSL=paged_result_size_limit

Specifies the maximum number of entries of a search result for a paged search operation. The size limit PRSL is applied to the entire search result regardless of how many pages the result consists. A smaller value of paged_result_size_limit overrules the size limit specified in the search request of the client. If the number of entries to be returned exceeds the paged_size_limit value the DSA returns paged_result_size_limit entries, no search query reference (cookie for paging) and a SIZE LIMIT EXCEEDED return code. The LDAP client receives paged_result_size_limit SearchResultEntry messages, a SearchResultDone message containing a sizeLimitExceeded resultCode and a pagedResultsControl with a cookie set to an empty value. The empty cookie indicates that there are no more entries returned in the paged search sequence. (See also Managing Huge Search Results in chapter Managing Miscellaneous Scenarios in the Administration Guide.)

The default value for paged_result_size_limit is 16384.

The maximum single page size limit is specified in the SPL component.

SPL=single_page_limit

Specifies the maximum number of entries per page of a search result for a search operation with paging. The size limit SPL is applied to each single result page. A smaller value of single_page_limit overrules the size limit specified in the search request of the client. If the number of entries to be returned exceeds the single_page_limit value the DSA returns single_page_limit entries per page, a search query reference (cookie for paging) and a SIZE LIMIT EXCEEDED return code. The LDAP client receives single_page_limit SearchResultEntry messages, a SearchResultDone message containing a sizeLimitExceeded resultCode and a paged resultsControl with a cookie set to a non-empty value. The non-empty cookie indicates that there are more entries that the server returns for subsequent requests of the paged search sequence. (See also Managing Huge Search Results in chapter Managing Miscellaneous Scenarios in the Administration Guide.) The client can continue to retrieve pages of searches by presenting the returned query reference.

The default value for single_page_limit is 2048.

The maximum number of entries returned on all result pages is specified in the PRSL component.

ALS=attribute_limit_size

Specifies the maximum size of an attribute in an entry of a retrieval result. A value of –1 is unlimited.

If an attribute exceeds the limit all of its values are omitted from the returned entry and “incompleteEntry” is set in the returned entry information. The limit is imprecise.

Description

The User-Policies syntax is for attributes that control a DSA’s methods of interaction with users. The syntax is used for the multivalued USP attribute. The USP attribute specifies the policies for several individual users or group of users. These policies control:

  • The authentication method required from the users

  • Whether the users can access the chaining and modify services of the DSA

  • The maximum number of entries of a retrieval result

  • The maximum length of attribute values returned in a retrieval result.

Example

USP={USN={/ },
     OPT=0,
     AP={AMB={AM=NONE}}
     };

USP={USN={/O=my-company/OU=asw},
     OPT=CHAINING+MODIFY,
     AP={AMB={AM=SIMPLE;SIMPLE-WITH-PWD},
         OPWD=my-pwd,
         CV=300}};
    {USN={/O=my-company/OU=com},
     OPT=CHAINING,
     AP={AMB={AM=SIMPLE},
         OPWD=pwd}}
}
USP={{USN={/O=my-company/ou=asw },
     SL=1000,PRSL=5000,SPL=100};
     {USN={/O=my-company2/ou=mds },
     SL=2000,PRSL=20000,SPL=1000}}

Continuation-Reference

A component syntax used for information returned by DSAs when the referral method of interaction is used for an operation. This syntax is described here for output purposes only; it cannot be used for input. This syntax is used by the dirxcp command to define the format and contents of displayed information.

Synopsis

DSAR={TO=target-object
    [,ARDNS=aliased-rdns]
    ,OP=operation-progress
    [,RRDNS=resolved-rdns]
    ,RT=reference-type
    ,API=access-point_info;access-point_info;…​
    ,EO=entry-only
    ,RTDUA=return-to-DUA
    ,NROM=name-resolve-on-master }

Components

TO=target-object

A string that identifies the distinguished name of the object that should be used in continuing the operation on the referred-to DSA (for example, /O=my-company).

ARDNS=aliased-rdns

An integer that identifies the number of aliases dereferenced to obtain the distinguished name of the target.

OP=operation-progress

The state of the referral operation. operation-progress is in the format:
{NRP=name-resolution-phase
[,NRDN=next-rdn-to-be-resolved]}

where:

NRP=name-resolution-phase

One of the following keywords:

  • NOT-STARTED

  • PROCEEDING

  • COMPLETED

NRDN=next-rdn-to-be-resolved

An integer that indicates to the DSA which of the RDNs in the target object is the next to be resolved.

RRDNS=resolved-rdns

An integer that identifies how many RDNs have currently been resolved using internal references only.

RT=reference-type

The type referral. reference-type is one of the following keywords:

  • SUPERIOR

  • SUBORDINATE

  • CROSS

  • NON-SPECIFIC-SUBORDINATE

  • SUPPLIER

  • MASTER

  • IMMEDIATE-SUPERIOR

  • SELF

API=access-point_info

The access points for the master DSA and/or the shadow DSA in order to achieve the continuation. access-point_info is in the following format:
{AP=MasterAndShadowAccPoints [,AAP=MasterAndShadowAccPoints]}

See Master-And-Shadow-Access-Points for a description of MasterAndShadowAccPoints syntax. The AAP component specifies additional access points.

EO=entry-only

A Boolean value that specifies whether the DSA should resolve only the named entry if alias names are encountered. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.) A value of TRUE indicates that name resolution should be performed only on the named entry.

RTDUA=return-to-DUA

A Boolean value that specifies whether the requested information is available from the DUA. This component is used when for security reasons the DSA cannot return information from an intermediate DSA. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.) A value of TRUE indicates that the information must be obtained from the DUA.

NROM=name-resolve-on-master

A Boolean value that specifies whether name resolution must be performed by the master DSA. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.) A value of TRUE indicates that name resolution must be performed by the master.

Description

Continuation references passed during the referral method of interaction are represented with Continuation-Reference component syntax. The component contains the continuation reference for the referral

Examples

DSAR={TO={/O=my-company/OU=asw/CN=dsa/CN=dsa20},
      OP={NRP=PROCEEDING,NRDN=5},
      RRDNS=4,
      RT=SUBORDINATE,
      API={MOS={MSAP={AE={/O=my-company/OU=asw/CN=dsa/CN=dsa20},
           PSAP={TS=Server20,
                 NA=TCP/IP!internet=139.23.81.32+port=102}},
           CAT=MASTER}},
      EO=FALSE,
      RTDUA=FALSE,
      NROM=FALSE
     }

Facsimile-Telephone-Number

An attribute syntax for attributes that specify Facsimile (FAX) numbers.

Synopsis

FacsimileTelephoneNumber ={PN=phone_number
[,PAR=G3_FAX_NonBasicParameter]}

Attribute Type

FacsimileTelephoneNumber

The abbreviation or OID that corresponds to a structured attribute with the Facsimile-Telephone-Number (FAX_TELEPHONE_NO) syntax. For example, FTN (Fax-Telephone-Number) is such an attribute.

Components

PN=phone_number

The fax number in Printable string format (up to 32 characters in length).

PAR=G3_FAX_NonBasicParameter

The settings for the G3 Fax parameters. Note that setting G3 parameters is hardly ever required. Specify G3_FAX_NonBasicParameter in the following format:

{[A3W=TRUE | FALSE]
[,B4L= TRUE | FALSE]
[,B4W= TRUE | FALSE]
[,FR= TRUE | FALSE]
[,TD= TRUE | FALSE]
[,UC= TRUE | FALSE]
[,UL= TRUE | FALSE]}

Specify TRUE to turn the parameter on or FALSE to turn it off.

Description

FAX numbers are represented with the Facsimile-Telephone-Number attribute syntax. The number consists of the country code and number in Printable string format. You can also set G3 non-basic parameters.

Example

FTN={PN=12345}

Name-And-Optional-UID

An attribute syntax for attributes that identify objects by a distinguished name and an optional identifier that can remove ambiguity from names that have been re-used.

Synopsis

NameAndOptionalUID = {DN={distinguished name}
[,UID=BIT_string]}

Attribute Type

NameAndOptionalUID

The abbreviation or OID that corresponds to a structured attribute with the Name-And-Optional-UID syntax. For example, UM (Unique-Member) is such an attribute. The UM attribute can be used in objects which represent lists of names.

Components

DN=distinguished name

The distinguished name of the object. (See section Distinguished Name above in this chapter for details.)

UID=BIT_string

A bit string that uniquely identifies the object. The bit string can be used when an object is removed from the Directory, and another object is subsequently given the same Directory name. The bit string must be chosen for uniqueness, such as a time-stamp (for example). (See section Bit String Syntax above in this chapter for details.)

Description

The identity of objects can be represented with the Name-And-Optional-UID attribute syntax. The attribute consists of the object distinguished name and an optional bit string that distinguishes between objects with the same distinguished name. The association between a user of the Directory and a name when the UID is present can be established by strong authentication using Version 2 (or later) certificates.

Examples

UM={DN={/O=my-company/OU=engineering/CN=Hughes H},
    UID=0010100101001011110};
   {DN={/O=my-company/OU=engineering/CN=Smith J}
   }

Partial-Outcome-Qualifier

A component syntax for information returned when DSA operations (search, list) cannot be completed. This syntax is only used for output purposes; it cannot be used for input. This syntax is used by the dirxcp command to define the format and contents of displayed information.

Synopsis

POQF={LP=limit_problem
[,UDSA=continuation_reference[; ...],
UCE=unavailable-critical-extension}

Components

LP=limit_problem

One of the following keywords that indicate that a limit has been exceeded:

  • TIME LIMIT EXCEEDED

  • SIZE LIMIT EXCEEDED

  • ADMINISTRATIVE LIMIT EXCEEDED

UDSA=continuation-reference

The DSA continuation reference for unexplored DSAs. See Continuation-Reference for the complete syntax of continuation-reference.

UCE=unavailable-critical-extension

A Boolean value that specifies whether or not mandatory protocol extensions are supported by the DSA involved the execution of this operation. (See Simple Attribute Syntax for a description of BOOLEAN syntax representation.)

Description

Information returned for partially completed operations is represented with the Partial-Outcome-Qualifier component syntax. The information includes a description of the limit that was exceeded, the continuation reference, and an indication of whether the DSA involved in the operation supports mandatory protocol extensions.

Examples

POQF={LP=SIZE LIMIT EXCEEDED,
      UDSA={TO={/O=my-company/OU=asw/CN=dsa},
            ARDNS=0,
            OP={NRP=COMPLETED},
            RT=SUBORDINATE,
            API={MOS={MSAP={AE={/O=my-company/OU=asw/CN=dsa
                                /CN=dsa20},
                            PSAP={TS=Server20,
                                  NA=’TCP/IP!internet=139.23.81.32+
                                     port=102’}},
                      CAT=MASTER}},
                  EO=FALSE,
                  RTDUA=FALSE,
                  NROM=FALSE};
            {TO={/O=my-company/OU=asw/CN=dsa},
             ARDNS=0,
             OP={NRP=COMPLETED},
             RT=SUBORDINATE,
             API={MOS={MSAP={AE={/O=my-company/OU=asw/CN=dsa
                                 /CN=dsa18},
                             PSAP={TS=Server18,
                                   NA=’TCP/IP!internet=139.23.81.32+
                                      port=102’}},
                       CAT=MASTER}},
                  EO=FALSE,
                  RTDUA=FALSE,
                  NROM=FALSE}}
     }

Postal-Address

A structured attribute syntax for postal addresses.

Synopsis

PostalAddress = {PA1=postal-address-string
    [,PA2=postal-address-string]
    [,PA3=postal-address-string]
    [,PA4=postal-address-string]
    [,PA5=postal-address-string]
    [,PA6=postal-address-string]}

Attribute Type

PostalAddress

The abbreviation that corresponds to a structured attribute with the Postal-Address (POSTAL_ADDR) syntax. For example, PA (Postal-Address) is such an attribute.

Components

PAn=postal-address-string

A string (of up to 30 characters long) in DirectoryString format that provides a line of a postal address.

Description

Postal addresses are represented with the Postal-Address attribute syntax. The attribute consists of up to 6 address lines in directory string format. Each address line is limited to 30 characters in (in accordance with ITU-T recommendation F.401). One address line is required; the remaining 5 are optional.

Example

In the following example backslashes are used to escape the comma, which is otherwise interpreted as a component-separation character. 
PA={PA1=Tom Miller,
    PA2=525\, Hacienda Ave.\,
    PA3=Reading\, Massachusetts\, 01867
   }

Presentation-Address

An attribute syntax for attributes that specify presentation addresses.

Synopsis

PSA={[PS=P_Selector,]
    [SS=S_Selector,]
    TS=T_Selector,
    NA=network_address[;_network_address; …,]
    [DNS=_DNS_String]}

Attribute Type

PSA

The abbreviation or OID that corresponds to a structured attribute with the Presentation-Address (PRESENTATION_ADDR) syntax. For example, PSA (Presentation-Address) is such an attribute. The PSA attribute is used in entries that represent application entities or subclasses of application entities (such as DSAs).

Components

PS=P_Selector

The presentation selector address in Octet string format.

SS=S_Selector

The session selector address in Octet string format.

TS=T_Selector

The transport selector address in Octet string format of maximum 10 characters.

NA=network_address

The network address in Octet string format. The use of NSAP macros as shown in the example is strongly recommended for entering network addresses. The following NSAP macros are available:

  • IDM stack:
    TCP/IP_IDM!internet=*IP_address+port=*port_number

  • OSI stack:
    TCP/IP!internet=*IP_address+port=*port_number

where IP_address is the IP address in dotted notation and port_number is the port number.

NA is a mandatory component and thus must be specified even if the DNS_String component is used for addressing.
DNS=DNS_String

A Printable String with the network address and additional information that supports the following features related to addressing:

  • Network Address Translation (NAT)

  • Secure X.500 protocols over the IDM stack

  • IP version used by the IDM stack

This component is only supported for the IDM stack. If present, the DNS_String is used for addressing and the network address specified in the NA component is ignored.

The DNS_String is a printable string with the following internal format:

DNS=
’(HOST=name,
PLAINPORT=number
[,SSLPORT=number,]
[MODE=mode,]
[IPVERSION= ip_version])’

DNS_String_ Subcomponents
HOST=name

The name of the application entity’s host. DirX Directory uses the DNS Service to resolve the IP addresses of the application entity. DirX Directory always uses the first IP address that the name service returns.

Using a name service is recommended to support network address translation (NAT) as provided, for example, in some firewall products. Using a name service is also recommended when communicating with DSAs over IPv6 protocol.

PLAINPORT=number

The port number on which the application entity is listening for plain X.500 protocols The resolved IP address and the plain port number are used to perform the DAP, DSP or DISP bind over plain IDM.

SSLPORT=number

The port number the application on which the entity is listening for secure X.500 protocol.

In the context of an own address; that is, as the value of the DIRX_OWN_PSAP environment or as the value of the SELF entry in the dirxcl.cfg or dirxldap.cfg files, the SSLPORT subcomponent indicates whether the IDMS stack is to be initialized: If the address contains an SSLPORT with a value greater than zero, the IDMS stack is initialized. In the DSA process, IDMS starts a communication listener on the port specified by SSLPORT.

For outgoing connections, the resolved IP address and the SSL port number of the communication peer’s PSAP are used to perform the DAP, DSP or DISP bind over IDM protected by SSL/TLS (IDMS). Suitable key material must be installed in order to be able to perform the X.500 protocols over SSL/TLS. See the chapter Files in the DirX Directory Administration Reference for details on IDMS configuration and key material.

MODE=mode

The security mode for IDM. Specify one of the following values for mode:

  • PLAIN - X.500 protocols are performed over plain IDM (default).

  • SSL - X.500 protocols are performed over IDM protected by SSL/TLS (IDMS).

The mode value determines whether an outgoing connection to the application entity is performed to the plain port via plain IDM or to the SSL port via secure IDMS.

IPVERSION=ip_version

The IP stack version. Specify one of the following values for ip_version:

  • 4 - IPv4 address (default).

  • 6 - IPv6 address.

The ip_version specifies whether the IPv6 or IPv4 stack should be used for outgoing communication to the corresponding DSA. Keep in mind that you must administer the name service correctly before you can use this component.

older versions of DirX Directory support the DNS String format DNS=host*+*port[*:*ipversion]. The latest version of DirX Directory also supports this older format, but using it prevents any benefit from the new IDMS feature.

Description

Presentation address is represented with the Presentation-Address attribute syntax. Presentation addresses are always associated with application entity entries. The PSAP macro utility handles presentation address attributes.

With respect to the IP version, DirX Directory is able to handle networks with DSAs of different versions running different protocol stacks. It is prohibited to run a mixed OSI- / IDM-stack network. The OSI stack always uses IPv4 protocol. However running an IDM stack you can mix communication over IPv4 and IPv6 protocol. The network can consist of

  • DSAs not understanding the DNS component:

    These DSAs always communicate over IPv4 protocol. They use the IPv4 address specified in the NA component.

  • DSAs understanding the DNS component but not the *:*ip_version subcomponent:

    These DSAs always communicate over IPv4 protocol. They use the DNS_name to resolve the IP address from a name service. If the name service does not return a correct IPv4 address the DSA uses the IPv4 address specified in the NA component.

  • DSAs understanding the DNS component and the *:*ip_version subcomponent:

    These DSAs can communicate over IPv4 and IPv6 protocol simultaneously if they are running on a dual-stack machine. They use the DNS_name and the ip_version to resolve the IP address from a name service. If the name service does not return the correct IPv4 address the DSA uses the IPv4 address specified in the NA component. If the name service does not return a correct IPv6 address establishing the connection fails.

With respect to secure X.500 protocols, DirX Directory is able to handle heterogeneous connections; that is, to use plain IDM to connect to set of communication peers while using IDMS to another set of communication peers.

Examples

  1. The following example shows a presentation address with:

    • T-Selector (the TS component), an octet-string with octet values, set to the string “server,” using ISO8824 encoding:

    • Network address (the NA component) set to correspond to an IPv4 address of 123.45.67.89, with a port number of 31111:

      PSA={TS=server,NA='TCP/IP_IDM!internet=123.45.67.89+port=31111'}

  2. The following example shows a presentation address with a DNS component:

    PSA={TS=DSA3,NA='TCP/IP_IDM!internet=139.25.13.11+port=23333',DNS=’(HOST=DirXDSA3.my-company.de,PLAINPORT=23333)’}

    Let us assume that a DSA finds this PSAP address in the subordinate reference when chaining an update request to DSA3. It first reads the IPv4 address of DirX-DSA3.my-company.de from the name service and then performs the DSP bind to DSA3 with this IP address and the port number 23333.

  3. The following example shows a presentation address with a DNS component for a DSA that communicates over IPv6 protocol:

    {TS=DSA4,NA='TCP/IP_IDM!internet=111.22.33.55+port=24444',DNS=’(HOST=BOSDSA4,PLAINPORT=24444,IPVERSION=6)’}4

    Keep in mind that for IPv6:

    • You must use a machine that is able to handle IPv6 protocol. To be able to communicate also with DSAs communicating over IPv4 protocol, you must use a dual-stack machine.

    • You must administer the name service correctly.

    • For incoming communication, you must specify the environment variable DIRX_IP_STACK.

  4. The following example shows the presentation address of a consumer DSA with a DNS component that specifies that communication to this DSA must be performed via secure IDM:

    {TS=DSA3,NA='TCP/IP_IDM!internet=111.22.33.44+port=23333',DNS=’(HOST=DURDSA3,PLAINPORT=21100,SSLPORT=21201,MODE=SSL)’}

    Let us assume that the supplier DSA finds this PSAP address in the Consumer Knowledge of the shadow consumer DSA when replicating an update via DISP to DSA3. It first resolves the IPv4 address of DURDSA3 from the name service. If its own PSAP contains an SSL PORT greater than 0, it performs the DISP bind to DSA3 to the port number 21201 over secure IDM.

Protocol-Information

An attribute syntax for attributes that specify protocol information in the form of profiles (identified by object identifier) that are associated with particular network addresses.

Synopsis

ProtocolInformation ={NA=NSAP-Address,
    OID=object_identifier[;_object_identifier…_]}

Attribute Type

ProtocolInformation

The abbreviation or OID that corresponds to a structured attribute with the Protocol-Information syntax. For example, PI (Protocol-Information) is such an attribute. The PI attribute is restricted to entries (e.g., those of object class application-entity or subclasses of application-entity), which themselves contain presentation-address attributes.

Components

NA=NSAP-Address

The NSAP network address of the communications object to be described. The NSAP address must be one of the NSAP addresses in the presentation address of the object being described.

OID=object_identifier

The OID or an abbreviation for the OID that corresponds to a profile (e.g., as defined by OIW or EWOS) that is supported by the communications object. Note that these OIDs represent low-level communications characteristics (e.g., those associated with the network layer or below).

Description

Protocol-Information attribute syntax represents lower-layer communications characteristics of communications objects. This information consists of the NSAP address to which the profile applies and one or more object IDs that represent the profiles to which the object conforms.

Examples

PI={NA='TCP/IP!internet=123.45.67.89+port=102',
     OID=1.3.14.65.237;1.3.14.65.239}

Subtree-Specification

An attribute syntax for attributes or for attribute components that specify subtrees. This attribute is used in the subtree-specification attribute of subentries to represent the target of policies held by the subentries. Note that this syntax is also used as part of the Shadowing-Agreement-Info attribute syntax and the ACI-Item syntax.

Synopsis

SubtreeSpecification = {[DEF=boolean_value]
    [,BAS=base_object_of_subtree]
    [,EXCL=specific_exclusions]
    [,MIN=minimum_base_distance]
    [,MAX=maximum_base_distance]
    [,SF=specification_filter]}

Attribute Type

SubtreeSpecification

The abbreviation or OID that corresponds to a structured attribute with the SubtreeSpecification (SUBTREE_SPEC) syntax. For example SS (Subtree-Specification) is such an attribute. SS is a mandatory attribute of a subentry.

Components

DEF=boolean_value

A Boolean value that specifies whether the subtree consists of the entire administrative area. If DEF=TRUE (the subtree consists of entire administrative area), you should not specify the BAS and SF components. If the BAS and / or SF components are specified a DEF=TRUE is ignored.

BAS=base_object_of_subtree

The base of the subtree, specified in a context-dependent way:

  • In subentries - Relative to the administrative point

  • In Shadowing-Agreement-Info - Relative to the context prefix

  • In ACI-Item (UC component) - Absolute (relative to the root of the DIT)

In all cases, however, the Distinguished Name format is used (starts with a /). If this component is omitted, but the SF component is supplied, the SF component (below) is used as a filter for the entire administrative area. To specify the whole subtree (inclusive the base object of the subtree), use the notation BAS={/}.

EXCL=specific_exclusions

This component defines a list of exclusions. It has the following format:

{CHB={chop_before}} | {CHA={chop_after}} [; {CHB={chop_before}} | {CHA={chop_after}} …​ ]

The CHB=chop_before form defines a limit point that is to be excluded along with its subordinates from the subtree or subtree refinement. The limit point is an entry identified by a distinguished name relative to the base object of subtree.

The CHA=chop_after form defines a limit point whose subordinates are to be excluded from the subtree or subtree refinement. The limit point is an entry identified by a distinguished name relative to the base object of subtree.

MIN=minimum_base_distance

An integer value that excludes all entries superior to entries that are minimum_base_distance RDN arcs below the base. The default value of zero corresponds to the base object of subtree.

This component is ignored when specified in a Shadowing-Agreement-Info.

_MAX=_maximum_base_distance

An integer value that excludes all entries subordinate to entries that are maximum_base_distance RDN arcs below the base. An absent of the component indicates that no lower limit should be imposed on the subtree or subtree refinement.

SF=specification_filter

The specification_filter is used to select entries in the subtree subordinate to the base defined by the BAS component or the entire administrative area. Specify specification_filter in the following format:

{ITEM=object_class} |
{AND=specification_filter[;_specification_filter_ … ]} |
{OR=specification_filter[;_specification_filter_ … ]} |
{NOT=specification_filter} |
{FILTER=ldap_search_filter}

object_class is either the OID of an object class or an object class abbreviation. The SF component selects entries that match the specification_filter within their object class attributes.

ldap_search_filter is the string representation of a LDAP search filter as specified in RFC 4515. If FILTER is specified the SF component selects entries that match the LDAP search filter as specified. The FILTER component may be used exclusively within the specification_filter. That is FILTER must not occur in any combination with the other components of specification_filter. The FILTER component is not supported in subtree specifications of shadow agreements respectively LDIF agreements. Creating such an agreement results in an erroneous operation. Some restrictions may apply to the used attribute types and filter expressions. Please refer to the actual DirX Directory Release Notes of your deployed DirX Directoy server.

Description

Specifications of subtrees used by subentries or in ACI items to define target entries for policies, are represented with the Subtree-Specification (SUBTREE_SPEC) syntax.

Examples

SS={DEF=TRUE}

SS={BAS={/OU=Research/OU=Metallurgy Department}}

SS={BAS={/OU=Research/OU=Metallurgy Department },SF={ITEM=ORP}}

SS={BAS={/O=sni},
    EXCL={CHB={/OU=Research/OU=Metallurgy}};
    MIN=0,MAX=10
    SF={ITEM=PER}}

SS={BAS={/O=sni},
    EXCL={CHB={/OU=Research/OU=Metallurgy}};{CHA={/OU=Sales}},
    MIN=0,MAX=10}

SS={SF={ITEM=2.5.6.7}}

SS={BAS={/OU=Sales},
    SF={AND={ITEM=ORP};{ITEM=IPER}}}
 		Selects all organizational persons of the organizational
 		unit Sales that are also inet organizational persons.
 		That are all entries under the base object /OU=Sales
 		with the object class values ORP and IPER.

SS={BAS={/OU=Sales},
    SF={AND={ITEM=ORP};{NOT={ITEM=IPER}}}}
		Selects all organizational persons of the organizational
 		unit Sales that are not inet organizational persons.
 		That are all entries under the base object /OU=Sales
 		with the object class value ORP and not IPER.

SS={BAS={/OU=Sales},
    SF={OR={ITEM=ORP};{ITEM=OU}}}
		Selects all organizational persons and all organizational
 		units of the organizational unit Sales.
 		That are all entries under the base object /OU=Sales
 		with the object class values ORP or OU.

SS={BAS={/},
    SF={Filter=(&(title=Manager*)(!(employeetype=contract)))}}
		Selects all entries where attribute title begins
 		with Manager and attribute employeetype is not contract.

Teletex-Terminal-Identifier

An attribute syntax for attributes that specify a Teletex terminal.

Synopsis

TeletexTerminalIdentifier = {TT=teletex-terminal
[,PAR=teletex-non-basic-parameters] }

Attribute Type

TeletexTerminalIdentifier

The abbreviation or OID that corresponds to a structured attribute with the Teletex-Terminal-Identifier syntax. For example, TTI (TTX-Terminal-Identifier) is such an attribute.

Components

TT=teletex-terminal

A string (up to 1024 characters long) that identifies the terminal. Specify the teletex-terminal parameter using the Printable String syntax. See Simple Attribute Syntax for a description of Printable String Syntax representation.

PAR=teletex-non-basic-parameters

A component that sets non-basic parameters for various teletex options. Specify teletex-non-basic-parameters in the following format:

{[CCS=control_character_sets]
    [,GCS=graphic_character_sets]
    [,MC=miscellaneous_capabilities]
    [,PF=page_formats]
    [,PU=private_use]}

where:

CCS=control_character_sets

A T61 string that defines the control character sets to use.

GCS=graphic_character_sets

A T61 string that defines the graphic character sets to use.

MC=miscellaneous_capabilities

A T61 string that defines miscellaneous capabilities to use.

PF=page_formats

An OCTET string that defines the page formats to use.

PU=private_use

An OCTET string that defines user-defined Teletex parameters.

Description

Teletex terminals and their parameters are represented by the Teletex-Terminal-Identifier attribute syntax. The information consists of a printable string that identifies the terminal and optional non-basic, advanced parameters that control terminal parameters such as character sets, page formats and other capabilities.

Examples

{TTI={TT= My Company Teletex center}}

Telex-Number

An attribute syntax for attributes that specify Telex numbers.

Synopsis

TelexNumber = {TN=telex_number
    [,CC=country_code]
    [,AB=answer_back]}

Attribute Type

TelexNumber

The abbreviation or OID that corresponds to a structured attribute with the Telex-Number (TELEX_NO) syntax. For example, TXN (Telex-Number) is such an attribute.

Components

TN=telex_number

The telex number in Printable string format (of up to 14 characters long).

CC=country_code

The country code in Printable string format (of up to 4 characters long).

AB=answer_back

The short textual string (of up to 8 characters long), in Printable string format, with which the telex station responds when required to indicate its identity. (For example, when the telex station is connected to.)

Description

Telex numbers are represented with the Telex-Number attribute syntax. The number consists of the country code, Telex number, and answer-back code.

Example

{TXN={TN=24344,
     CC=046,
     AB=GAMEX B }}

DirX Directory-Member-Url

An attribute syntax for attribute DRXMURL (in LDAP dirxMemberUrl).

Synopsis

DRXMURL = ldap:///BASE-DN??SEARCH-SCOPE?(SEARCH-FILTER)

Attribute Type

DRXMURL

The abbreviation or OID that corresponds to an attribute that requires a DirX Directory-Member-Url syntax. Per the schema definition, the syntax of the attribute is DirectoryString but DirX Directory DSA expects the values in the format describedhere. DRXMURL (DirX Directory-Member-Url) is an example of this type of attribute.

Components

BASE-DN

Specifies the distinguished name (DN) in LDAP syntax of the search base or the point from which the search is performed. This component is required.

Example: ou=Accounting,o=My-Company

SEARCH-SCOPE

Specifies the scope of the search. The following keywords are permitted:

  • base retrieves information only about the DN specified in BASE-DN.

  • one retrieves information about entries one level below the DN specified in BASE-DN.

  • sub retrieves information about entries at all levels below the DN specified in BASE-DN.

This component is required.

Example: sub

SEARCH-FILTER

Specifies a search filter in LDAP syntax as described in RFC4515 that applies to entries within the specified scope of the search. This component is required and must be specified within parenthesis.

Example: (&(l=munich)(title=senior*))

Description

This attribute syntax specifies a simplified LDAP URL syntax based on RFC2255. This syntax is identical for DAP and LDAPbinds. It is used to describe an LDAP search expression for managing dynamic groups. Some restrictions may apply to the search filter. Please refer to the DirX Directory Release Notes to see which restrictions apply in your deployed DirX Directory Service.

Example

{DRXMURL=ldap:///o=My-Company??sub?(&(l=munich)(title=senior*))}