Naming contexts and Global Catalog: Where is each piece of information located?

1. Core mechanism

This lesson looks at the LDAP directory through logical naming contexts (NCs), not the physical database file. RFC 4512 §5/§5.1 covers NCs and root DSE. [MS-ADTS] §3.1.1.1.8 defines the logical GC view; Microsoft's Active Directory Replication Concepts describes the full and partial replicas physically hosted by a GC-role DC. Microsoft Application Directory Partition documentation explains that application NCs are not automatically replicated to the GC. PAS membership comes from Microsoft's GC documentation; ports 389/636 and 3268/3269 from its port table. KCC topology and Ntds.dit internals are outside this lesson.

Interfaces and specifications

• Domain NC: section of a domain that holds user, computer, and group objects; only it replicates exactly between the DCs of domain.
• Configuration NC: holds site, subnet, service and replication topology objects; common to all forest.
• Schema NC: holds the definitions attributeSchema and classSchema; It is unique and common throughout forest.
• Application NC: a separate partition for application data such as DNS, replicated to selected DCs; in AD DS it cannot contain security principals and is not automatically replicated to the GC.
• Root DSE: Server-specific entry that publishes the list of NCs (namingContexts) and the schema entry (subschemaSubentry), not belonging to any NCs.
• The GC endpoint (3268/3269) exposes a forest-wide read-only logical view. Physical replica writeability follows DC type, not the GC role: a writable GC has full replicas of its domain/schema/config NCs; an RODC GC has read-only replicas. Attributes in the RODC filtered attribute set may not be replicated at all. Application NCs are not automatically part of the GC.
• isMemberOfPartialAttributeSet=TRUE selects configurable PAS membership. FLAG_ATTR_REQ_PARTIAL_SET_MEMBER in systemFlags forces membership independently. RODC FAS exclusion and read rights remain separate limits.

Partition is not a storage detail, it is a boundary

A naming context is an entire subtree mastered by a single server (RFC 4512 §5). AD DS has domain, configuration, schema, and optional application NCs. A domain NC replicates among DCs of its domain; configuration and schema NCs are forest-wide. Application NCs have a separate replication scope defined by the selected DC replicas. These differences define replication and authorization boundaries.

So 'Searching on AD' is not a single question. If the object you are looking for is the user account of a domain, the corresponding domain to NC; if the site/subnet definition is configuration NC; If you are looking for the attribute definition itself you should look at schema NC. Searching the wrong NC produces results that appear to be 'no data' but are actually 'you looked in the wrong section'.

Exploring partitions with root DSE

Instead of guessing which NCs a server hosts, you can read from the root DSE. The root DSE is a special entry whose DN is zero RDN (empty string) and is queried with the filter baseObject with scope (objectClass=*) (RFC 4512 §5.1). The namingContexts operational attribute here lists the context prefixes of the NCs held by the server; subschemaSubentry returns the schema entry DN (RFC 4512 §4.4).

Since root DSE attributes are operational, they are returned only by their names, like other operational attributes (RFC 4512 §5.1). So a query that says 'fetch everything' will not show these. This is the first instantiation of the 'requested attribute list' behavior that we will see in the next lesson.

Global Catalog: a wide but shallow copy

Separate the GC role from DC type. A writable GC stores its own domain and Schema/Configuration NCs as full/writable replicas, and objects in other domain NCs with a partial/read-only PAS attribute subset. A GC on an RODC has no writable replica and may lack filtered-attribute-set values. The logical read-only view exposed on the GC port is a separate concept; Application NCs are not automatically included.

An attribute appears in the GC view when its attributeSchema object's isMemberOfPartialAttributeSet value is TRUE (Microsoft, Attributes Included in the Global Catalog). PAS contains attributes useful for forest-wide search or identifying an object. This view lets clients search without knowing the object's domain. Regular LDAP endpoints use 389/636; GC endpoints use 3268/3269 (Microsoft, AD port requirements).

Finding it and reading it completely are different steps.

PAS attributes can be read through the GC view; access is still subject to ACLs and any confidential-attribute extended access check. When a non-PAS attribute is needed, the typical flow is to get the object's distinguished name from the GC, then connect to a DC (389/636) holding the object's full replica and read it there (Microsoft, Attributes Included in the Global Catalog).

An attribute missing from a GC result does not reveal why: it may be outside PAS, its value may be unset on the object, or an ACL/confidential access check may hide it from this bind context. A query to the full replica can verify it only if the requester has permission. Conversely, visibility in GC does not make it public; access checks still apply. On an RODC GC, FAS exclusion can also mean the value was never replicated. Following up at a full replica of the object’s domain guarantees neither the requester’s read permission nor the value’s presence.

State and data flow

1. The client looks for an attribute of an object, but does not know the object's DN or which domain it is in.
2. The client sends a LDAP search wholeSubtree to the GC port (3268) to search across forest.
3. The GC returns DNs and requested PAS attributes for matching objects in its view, subject to access checks.
4. If an attribute is outside PAS or fails an access check for the requester, the GC result alone cannot verify its value.
5. Using DN, the client connects to DC (389/636) of domain, which holds the exact replica of the object.
6. The client reads the missing attributes from the full replica, as access controls allow.

2. Exploitation

Broken trust assumption

The assumption being broken is that because Global Catalog provides reads across forest, the data seen at GC is a discovery surface that is both fully authoritative and unrestrictedly accessible.

Technical prerequisites

• Network access to a DC in the GC role and the ability to reach port 3268/3269.
• A bind context that can read the directory; In most environments, Authenticated Users can read many attributes; anonymous access is generally disabled.
• For an attribute to be available in the GC view, it must be in PAS; non-PAS attributes are not included in the GC search response.
• A confidential attribute requires CONTROL_ACCESS in addition to READ_PROPERTY; results depend on the requester's ACL and extended-access-check context.
• wholeSubtree scope and appropriate filter; otherwise scanning across forest cannot be done.

Exploitation mechanism

A single GC query (port 3268, wholeSubtree) can search objects, DNs, and PAS attributes across the forest's domain NCs and the configuration/schema NCs in the GC view. This gives a broad discovery map without finding and querying each domain separately. Application NC data is not automatically included in the GC. The view exposes only PAS attributes; requesting a non-PAS attribute does not make it appear, and ACL/confidential extended access checks limit reads. 'Not in GC' is not the same as 'not on the object'.

Breadth gives discovery, not authority.

Sorting objects across GC through forest gives the attacker a map: which domains are there, which privileged group names are there, which service accounts. This is a read (recon) advantage. But being readable does not mean the right to write or control over that object; We deepen this in the next lesson with the distinction between 'readable directory data and writable control rights'.

An assessment should not treat 'I saw X in GC' as a conclusion by itself. Record which NC and PAS attribute appeared in the GC view, the requester's bind context, and applicable ACL/extended access checks separately.

Mistaking partial data for complete data

If an attribute is missing from the GC view, it may be outside PAS, unset on the object, or withheld by an access check. A confidential attribute requires an additional CONTROL_ACCESS right; a requester without it may not receive the value. It is therefore wrong to read a missing field as proof that an account is harmless.

Therefore, an inference based on GC should not be considered definitive without verification from the exact replica. In the attack model, this includes incorrect target selection; In the defense model, it results in incomplete risk assessment.

3. Defense & Detection

Telemetry scope

• Routine LDAP/GC readings are not checked in the Security log by default; Read control requires object SACL and Audit Directory Service Access subcategory (4662).
• 4662 is generated only if the corresponding object contains the appropriate SACL and the operation structure matches this SACL; 4662 is output separately for each transaction type.
• 4662 is a security audit event, but it does not indicate which replica (GC 3268 or full replica 389) responded to the read; This distinction is observed at the network/port level.
• Since GC's scope is general forest, large SACL's on GC produce a high volume of events; The read control must be applied selectively.

Events and relevant fields

• For 4662, Provider is Microsoft-Windows-Security-Auditing, channel is Security and Version 0 (Microsoft, 4662 document).
• EventData publishes SubjectUserSid, SubjectUserName, SubjectDomainName, ObjectServer (DS), ObjectType (object class), ObjectName (the accessed object's distinguished name), OperationType, AccessMask, and Properties. ObjectType and Properties can contain GUIDs identifying class/property information.
• ObjectType and Properties GUID indicate which class/attribute is being accessed; so 4662 can be collapsed at the attribute level with SACL.
• 4662 does not save the base/scope/filter form of query LDAP; It only records access to the object.

Observation point: not the event, most of the time the network

Most of the AD read traffic is not visible in the default inspection. The 4662 is powerful, but only works on objects in the SACL container and at high volume due to the nature of the work. So 'Was there widespread discovery over GC?' The answer to the question is often sought not in the security issue, but in the 3268/3269 traffic at the network level.

Practical defense uses a combination of placing targeted SACL on critical objects and limiting GC/LDAP access to the network. Relying on a single event type leaves performed discovery through unchecked attributes invisible.

Detection logic · XPath

*[System[(EventID=4662)]] and *[EventData[Data[@Name='ObjectServer']='DS']]

Query assumptions

• This filter selects only EventID=4662 and ObjectServer=DS. It does not distinguish reads, writes or other directory access. Establishing the operation requires applicable SACL coverage and separate validation of actual AccessMask/Properties fields.
• If SACL is not present, the read produces no 4662; Absence of event does not prove absence of reading.
• The query does not distinguish between GC and full replica reading; This distinction requires the network port (3268/3269 to 389/636).
• The query was not run on the actual Windows system or SIEM; There is no dataset, volume threshold and baseline.

False positives

• Legitimate directory applications, management tools, and replication processes regularly read objects and produce 4662 inspected objects.
• Large SACLs produce large volume under normal workload; The single 4662 is not evidence of abuse.
• Without resolving ObjectType/Properties GUIDs into readable names, context can be misleading.
• A broad exploration of structure via GC may leave no trace if it touches unchecked attributes.

Hardening

• Where schema and platform constraints allow, consider marking eligible sensitive attributes confidential; this requires CONTROL_ACCESS in addition to READ_PROPERTY. Do not assume base-schema attributes can be marked; validate the effect in a lab/pilot.
• Inventory attributes added to PAS: PAS changes replicate to GC servers and add the attribute to the forest-wide logical GC view. Returned values remain subject to ACL and confidential access checks.
• Review anonymous LDAP access and unnecessarily broad read rights; dsHeuristics and align default permissions with corporate policy.
• Apply read control only to high value objects and related attributes with SACL; Use targeted control instead of the broad forest SACL.
• Narrow the discovery surface by determining which DCs the GC role is on and limiting 3268/3269 access by network segmentation.

Read the examples

30 81 9d 02 01 02 64 81 97 04 30 43 4e 3d 4b 61
79 72 61 2c 4f 55 3d 4b 75 6c 6c 61 6e 69 63 69
6c 61 72 2c 44 43 3d 6f 75 74 72 65 61 73 6f 6e
2c 44 43 3d 65 78 61 6d 70 6c 65 30 63 30 19 04
0e 73 41 4d 41 63 63 6f 75 6e 74 4e 61 6d 65 31
07 04 05 6b 61 79 72 61 30 16 04 0b 64 69 73 70
6c 61 79 4e 61 6d 65 31 07 04 05 4b 61 79 72 61
30 2e 04 11 75 73 65 72 50 72 69 6e 63 69 70 61
6c 4e 61 6d 65 31 19 04 17 6b 61 79 72 61 40 6f
75 74 72 65 61 73 6f 6e 2e 65 78 61 6d 70 6c 65

Two reality checks

Assumption: Since Global Catalog holds everything in forest, I can read all the information about an object from GC.

In fact: The GC view exposes all objects in the domain, configuration, and schema NCs with only PAS-member attributes. Application NCs are not automatically included. For a non-PAS field, get the DN from the GC, then read from a domain DC holding a full replica if your access rights allow it.

Assumption: If an attribute does not appear in GC, that attribute does not exist in that object.

In fact: Absence from GC may mean the attribute is outside PAS, its value is unset, or ACL/confidential extended access checks withheld it from the requester. Reading the full replica can confirm the value only when the necessary permissions are present.

Sources

• RFC 4512 · LDAP: Directory Information Models
  §5 naming context/context prefix definition; §5.1 root DSE and the namingContexts operational attribute; §4.4 subschemaSubentry.
• [MS-ADTS] · GC
  §3.1.1.1.8: GC logical view includes domain/config/schema NCs, all included objects, PAS attributes only, read-only.
• Microsoft · Active Directory replication concepts
  Global catalog server: full writable Schema/Configuration and hosted Domain replicas; partial read-only replicas of other domains.
• Microsoft · Including Attributes in the Global Catalog (Win32 AD)
  Replication to the GC when isMemberOfPartialAttributeSet=TRUE; obtaining the DN for a non-PAS attribute, binding to the full replica, and reading it there.
• Microsoft · About Application Directory Partitions
  Application NC excludes security principals in AD DS; is not replicated to GC; a GC DC can separately hold a full application NC replica.
• Microsoft · Configure firewall for AD domains and trusts
  Port table: 389 LDAP, 636 LDAP SSL, 3268 LDAP GC, 3269 LDAP GC SSL.
• Microsoft · 4662(S, F) An operation was performed on an object
  Audit Directory Service Access; the SACL requirement; Event XML; ObjectServer, ObjectType, and Properties fields; Version 0.
• [MS-ADTS] · Search Flags
  §2.2.9: CF (fCONFIDENTIAL, 0x80) and required extended access check.
• [MS-ADTS] · Extended Access Checks
  §3.1.1.4.4: confidential attributes require RIGHT_DS_READ_PROPERTY and RIGHT_DS_CONTROL_ACCESS; unauthorized values are treated as absent in returned attributes/filter.
• ADTS attribute availability and PAS membership
  PAS TRUE or required-partial-set systemFlags; RODC attribute restrictions
• Read-only DCs and the AD schema
  Filtered attributes not replicated to RODCs; DC type differs from GC role