Compartir a través de

3.1.1.3.1.2.4 Alternative Forms of DNs

  • Artículo

In addition to the form of the DN defined in [RFC2253], Active Directory supports several alternative forms of DNs that can be used to specify objects in requests sent to the DC, for example, as the baseObject in a SearchRequest or as an AttributeValue in a ModifyRequest.

The first alternative form is in the format

 <GUID=object_guid>

where object_guid is a GUID that corresponds to the value of the objectGUID attribute of the object being specified. All DCs support object_guid expressed as the hexadecimal representation of the binary form of a GUID ([MS-DTYP] section 2.3.4). Windows Server 2003 operating system and later DCs also support the dashed-string form of a GUID ([RFC4122] section 3).

The second alternative form is in the format

 <SID=sid>

where sid is the security identifier (SID) that corresponds to the value of the objectSid attribute of the object being specified. The sid is expressed as either the hexadecimal representation of a binary SID structure ([MS-DTYP] section 2.4.2.2) in little-endian byte order, or as a SID string ([MS-DTYP] section 2.4.2.1). Windows 2000 operating system DCs support only the hexadecimal representation.

The third alternative form is in the format

 <WKGUID=guid, object_DN>

where guid is a GUID expressed as the hexadecimal representation of the binary form of the GUID. A DN of this form is resolved to an object O by applying the following algorithm.

 MapWellKnownGuidToDN(GUID guid, DN object_DN)

This algorithm resolves a well-known GUID, expressed as a GUID, guid, and an object, object_DN, into the DN of the object O that is identified by that well-known GUID.

  • If object_DN does not name an object in the directory, reject the DN.

  • Otherwise, let C be the object named by object_DN.

  • If there exists a value V in C!wellKnownObjects such that the binary portion of V contains the same GUID as guid, then the DN of O is the DN portion of V.

  • Otherwise, if there exists a value V' in C!otherWellKnownObjects such that the binary portion of V' contains the same GUID as guid, then the DN of O is the DN portion of V'.

  • Otherwise, reject the DN.

The fourth alternative form is referred to as a TTL-DN.

Note The TTL-DN form is not supported by Windows 2000, Windows Server 2003, Windows Server 2003 R2 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, or Windows Server 2012 R2 operating system. Additionally, this form is only valid under the following conditions.

The TTL-DN form is in the format

 <TTL=seconds,<dn>>

where seconds is the number of seconds, expressed as an integer in ASCII text, until the expiry time for the link valued attribute value, and dn is any valid form of DN, including alternative forms of DNs except for this fourth alternative form. DCs MUST treat the literal "TTL" in a case-insensitive manner. This protocol does not specify the character case to use when a DC creates a TTL-DN.

When a client adds a new value or modifies an existing value for a link valued attribute, and provides a TTL-DN where seconds is 0, any existing expiry time associated with the link value is removed and the link no longer has an expiry time.

When a client provides any DN form other than a TTL-DN, the server MUST treat that as a value without an expiry time; that is, in the same manner as a TTL-DN where seconds is 0.

Normally, Active Directory will return DNs in the [RFC2253] format. However, clients can request that Active Directory return DNs in the "extended DN" format. This format combines an RFC 2253-style DN with a representation of the object's objectGUID and objectSid attributes. This form is documented in the LDAP section 3.1.1.3.4.1.5, which defines the LDAP_SERVER_EXTENDED_DN_OID control that is used by the client to request that the DC use the "extended DN" form when returning DNs. The "extended DN" form is not accepted as a means of specifying DNs in requests sent to the DC. The "extended DN" form is only used in LDAP responses from the DC, and only when the LDAP_SERVER_EXTENDED_DN_OID control is used to request such a form.

Additionally, clients can request that Active Directory return DNs for link valued attributes in the TTL-DN form. This form is documented in the LDAP section 3.1.1.3.4.1.36, which defines the LDAP_SERVER_LINK_TTL_OID control that is used by the client to request that the DC use the TTL-DN form when returning DNs. 

When returning a TTL-DN, seconds is the remaining number of seconds until the expiry time associated with the link value.

A DC MUST NOT return a TTL-DN for a link value with no associated expiry time, even if LDAP_SERVER_LINK_TTL_OID has been specified. Another DN format MUST be used.

Note that a request for a TTL-DN can be combined with a request for an extended DN. In this case, the DN portion of the TTL-DN is an extended DN.