Port 3268 – Global Catalog (LDAP)

Port 3268 is the default port for the Active Directory Global Catalog over LDAP (msft-gc, globalcatLDAP) — the cleartext, forest-wide directory index that every Global Catalog domain controller holds. Where ordinary LDAP on port 389 answers only for the domain a controller belongs to, the Global Catalog keeps a partial, read-only replica of every object in every domain of the forest. A single query on 3268 therefore reaches across domain boundaries that 389 never crosses — one bind, one filter, and you get users, groups, and computers from the root domain and every child at once. It’s the plaintext sibling of the Global Catalog over SSL on port 3269: 3268 = cleartext GC LDAP, 3269 = the same catalog wrapped in TLS. For a pentester, an open 3268 is the fastest forest-wide reconnaissance surface in Active Directory — and because it’s cleartext, everything crossing it is sniffable on the wire.

Why It’s Open

The Global Catalog is not optional plumbing — a multi-domain Active Directory forest can’t function without it. Interactive logons resolve universal group membership through the GC, user@forest.suffix UPN logons are resolved against it, Exchange address-book lookups hit it, and any application that needs a forest-wide search (rather than a single-domain one) points at 3268/3269 instead of 389/636. Windows exposes port 3268 automatically the moment a domain controller is promoted to hold the Global Catalog role, which — in most forests — is every DC. Where port 3268 answers, the rest of the domain controller is one scan away: check for Kerberos on port 88, cleartext LDAP on port 389, LDAPS on port 636, and SMB on port 445. Keep the split straight: 389/636 are single-domain LDAP/LDAPS carrying the full attribute set of one domain, while the forest-wide Global Catalog runs on 3268 (cleartext) and 3269 (over TLS) and carries only a partial attribute set — the subset of each object’s attributes flagged for replication into the catalog — and it’s read-only, so writes still go to the object’s home DC on 389/636.

Common Risks

• Forest-wide enumeration from a single bind. This is the whole point of the Global Catalog, and it’s exactly what makes 3268 valuable to an attacker. One query returns every user, group, and computer in every domain in the forest — sAMAccountNames, UPNs, descriptions, and cross-domain (universal) group memberships — not just the DC’s own domain. It’s the single richest recon query in an AD assessment.
• Anonymous / null bind leaks the whole forest. If the directory permits an unauthenticated bind — as many do — an attacker dumps the forest-wide catalog on 3268 with no credentials at all, the same anonymous-bind exposure as port 389 but scoped to the entire forest instead of one domain.
• Cleartext on the wire. Unlike 3269, traffic on 3268 is unencrypted. Bind DNs, simple-bind passwords, and every query result cross the network in the clear, so anyone on the path can sniff a full login and the directory data with Wireshark.
• SPN and Kerberoasting target discovery. Service accounts with servicePrincipalName set are visible forest-wide over the GC, so one 3268 query enumerates every Kerberoastable account across all domains — the target list you then feed to Kerberoasting via Kerberos on port 88.
• Cross-domain and cross-trust reconnaissance. Because the GC spans the forest, an attacker with a foothold in one domain uses 3268 to map universal groups, foreign security principals, trusts, and admin relationships in sibling domains without ever touching those domains’ own controllers — the fastest way to plan a cross-domain escalation.
• NTLM relay to the LDAP/GC service. The Global Catalog is served by the same LDAP stack as 389/636, so when LDAP signing and channel binding aren’t enforced, an attacker who relays coerced NTLM authentication to a DC’s LDAP/GC service acts as the victim (CVE-2017-8563).

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service

nmap -sV -p 3268 <target>

nmap labels 3268 as the Global Catalog LDAP service (globalcatLDAP / msft-gc). Seeing 3268 open alongside 389 (and their SSL siblings 3269/636) confirms the host is a Global Catalog domain controller.

Grab the RootDSE and naming contexts

# RootDSE over the GC — lists the naming contexts the catalog spans
ldapsearch -H ldap://<target>:3268 -x -b "" -s base namingContexts

# NSE equivalents, pointed at the GC port
nmap -p 3268 --script "ldap-rootdse,ldap-search" <target>

ldap-rootdse dumps the naming contexts, forest/domain functional level, and DC hostname anonymously; ldap-search pulls directory entries. Run them against 3268 (not just the default 389) to confirm you’re talking to the forest-wide catalog.

Forest-wide enumeration over 3268

# Forest-wide user enumeration from the empty base — the GC searches every
# domain partition in the forest, not just this DC's own domain
ldapsearch -H ldap://<target>:3268 -x \
  -D 'DOMAIN\user' -w 'Password123' -b "" -s sub \
  "(objectClass=user)" sAMAccountName userPrincipalName

# Every Kerberoastable service account across all domains in one query
ldapsearch -H ldap://<target>:3268 -x \
  -D 'DOMAIN\user' -w 'Password123' -b "" -s sub \
  "(&(objectClass=user)(servicePrincipalName=*))" sAMAccountName servicePrincipalName

# Cross-domain group membership — universal groups resolve here
ldapsearch -H ldap://<target>:3268 -x \
  -D 'DOMAIN\user' -w 'Password123' -b "" -s sub \
  "(objectClass=group)" cn member

Because the Global Catalog stores only the partial attribute set, some attributes come back empty over 3268 — pivot to LDAP on 389 (or LDAPS on 636) against the object’s home domain controller for the full record.

Authenticated enumeration with NetExec and windapsearch

# Point NetExec's LDAP module at the Global Catalog port for a forest-wide dump
nxc ldap <target> --port 3268 -u user -p 'Password123' --users --groups

# Test an anonymous / null bind against the GC
nxc ldap <target> --port 3268 -u '' -p ''

# windapsearch user/group enumeration against the directory
windapsearch.py --dc-ip <target> -u 'DOMAIN\user' -p 'Password123' -U

Collect for BloodHound across the forest

# BloodHound resolves cross-domain and forest-wide relationships through the GC
bloodhound-python -d domain.local -u user -p 'Password123' -c all -gc <target> -ns <target>

The Global Catalog is how BloodHound stitches together foreign-security-principals and universal group memberships that a single-domain collection would miss.

Metasploit modules (set RPORT to the GC port)

msfconsole -q
use auxiliary/gather/ldap_query          # run arbitrary LDAP queries
set RHOSTS <target>
set RPORT 3268
run

use auxiliary/gather/ldap_hashdump       # anonymous-bind dump of userPassword and friends
set RPORT 3268

Log every anonymous bind, cleartext credential, and forest-wide enumeration result you confirm so it lands in the final pentest report instead of a scratch file.

What to Look For

Known CVEs and Exploits

There is no “port 3268” vulnerability, and the honest headline is that the Global Catalog’s real risk is recon and misconfiguration — anonymous binds, cleartext exposure, and forest-wide enumeration — not a GC-specific memory-corruption bug. The Global Catalog is served by the same LDAP stack as ordinary domain LDAP, so it inherits the LDAP-service CVEs rather than having flaws of its own. The two that most directly apply to a GC/LDAP listener both concern the NTLM-relay-to-LDAP class; for the full LDAP CVE history (OpenLDAP, 389-DS, and Windows DoS/injection bugs) see the port 389 and port 636 pages.

• CVE-2017-8563 — Windows LDAP elevation of privilege (CVSS 8.1). When Kerberos falls back to NTLM and LDAP signing isn’t enforced, an attacker who relays that NTLM authentication to a domain controller’s LDAP service — including the Global Catalog service on 3268 — acts with the victim’s privileges, the canonical “NTLM relay to LDAP” path toward domain admin. Microsoft’s fix added the LdapEnforceChannelBinding setting, and the 2020 hardening (ADV190023) moved to enforce LDAP signing and channel binding by default. Affects Windows 7 SP1 through Server 2016.
• CVE-2019-1040 — NTLM MIC bypass, “drop-the-MIC” (CVSS 5.9). A man-in-the-middle strips the Message Integrity Check from an NTLM exchange without invalidating the message, re-opening relay to services — LDAP and the Global Catalog among them — that would otherwise reject tampered authentication. Chained with ntlmrelayx.py it revives NTLM-relay-to-LDAP even where some protections were assumed. Affects Windows 7 through Server 2019.

No CVEs were carried over from a prior version of this page (it is newly written), so none needed removing; every CVE above was verified against its NVD record and scoped to the actual LDAP/GC service before inclusion.

Mitigation

• Disable anonymous and null binds. A forest-wide directory should never answer an unauthenticated query — require authentication for every read on the Global Catalog, and audit what an anonymous bind can still see.
• Require LDAP signing and channel binding. On domain controllers, enforce signing and set channel binding to required (ADV190023) so NTLM relay to the GC’s LDAP service fails. This is the single most important AD hardening around 389/636/3268/3269.
• Prefer the encrypted GC on 3269. Traffic on 3268 is cleartext; push clients to the TLS-wrapped Global Catalog so bind credentials and query results aren’t sniffable, and disable cleartext simple binds where you can.
• Restrict who can reach 3268/3269. A Global Catalog exposes the whole forest, so it should never answer from the internet or arbitrary user subnets — firewall the GC ports to trusted management ranges and DC-to-DC traffic, and segment domain controllers.
• Purge secrets from directory attributes. Never store passwords in description, info, or userPassword; an attacker pulls them forest-wide in one GC query.
• Monitor for mass LDAP/GC enumeration and patch DCs. Alert on BloodHound-style bulk directory reads against the Global Catalog, and keep Windows current to close the relay-class exposure. Track every anonymous bind, cleartext exposure, and forest-wide enumeration finding in the pentest report so remediation is verifiable on the retest.

Real-World Example

A tester lands a single low-privileged foothold in a child domain of a large multi-domain forest — the kind of account a help desk hands out by the thousand. Against that child domain’s own controller on 389/636 they can only see one domain’s objects. But the same credentials bind to the Global Catalog on 3268, and now the view is the entire forest: every user and group in the root domain and every sibling, the membership of forest-wide Enterprise Admins and Schema Admins, every service account with an SPN across all domains, and the foreign security principals that reveal which accounts in other domains hold rights in this one. Feeding bloodhound-python -c all -gc <dc> off that one bind draws the cross-domain attack path automatically — a Kerberoastable service account in the root domain, or an admin group whose membership crosses a trust — without ever scanning or authenticating to the other domains’ controllers. And because 3268 is cleartext, a sensor on the wire that misses the relationships still catches the bind password in the clear. The lesson is that the Global Catalog’s forest-wide reach is a feature to the enterprise and a gift to an attacker: the exposure is the data, so it has to be paired with disabled anonymous binds, enforced signing and channel binding, a move to the encrypted 3269 sibling, and firewalling the GC to trusted ranges.

FAQ

What is port 3268 used for?

Port 3268 carries the Active Directory Global Catalog over LDAP — cleartext, forest-wide directory lookups. A Global Catalog domain controller answers queries about objects in every domain of the forest, not just its own, so 3268 is the port applications and clients use for a forest-wide search. It’s the plaintext counterpart of the Global Catalog over SSL on port 3269.

What is the difference between port 3268 and 3269?

Both serve the Global Catalog — the forest-wide, partial-attribute, read-only index of every object in the Active Directory forest. Port 3268 is plain LDAP (cleartext), so bind credentials and query results can be sniffed on the wire; port 3269 is the same catalog over implicit TLS, encrypted from the first byte. Use 3269 when the search needs to stay off the wire in the clear; both reach the whole forest.

What is the difference between the Global Catalog (3268/3269) and LDAP (389/636)?

Ports 389 and 636 answer for a single domain and hold the full attribute set of that domain’s objects. The Global Catalog on 3268/3269 answers forest-wide but carries only a partial attribute set and is read-only. In short: 389/636 for one domain in full, 3268/3269 for the whole forest in summary.

Is port 3268 TCP or UDP?

TCP. The Global Catalog’s binds, searches, and directory operations all run over TCP 3268. There’s no UDP Global Catalog.

Can port 3268 be exploited?

The port itself isn’t a vulnerability, but a normally configured Global Catalog exposes a great deal: anonymous-bind enumeration of the entire forest, cleartext credential and data exposure on the wire, forest-wide discovery of SPNs and Kerberoasting targets, and NTLM relay to the LDAP/GC service where signing isn’t enforced (CVE-2017-8563). The main value to an attacker is recon and misconfiguration, not a GC-specific bug — treat any reachable 3268 as a high-value forest-wide directory to enumerate and lock down.

How do I secure or close port 3268?

You can’t close it on a Global Catalog domain controller — a multi-domain forest needs it — so reduce what an attacker can do: disable anonymous and null binds, enforce LDAP signing and channel binding, push clients to the encrypted 3269, strip secrets out of directory attributes, patch the DC, and firewall 3268/3269 to trusted management ranges. On any DC that doesn’t need to be a Global Catalog, remove the GC role and confirm the port is closed with a rescan.

TL;DR

• Service: Active Directory Global Catalog over LDAP (msft-gc / globalcatLDAP) — cleartext, forest-wide directory index
• Default port: 3268 TCP (encrypted GC variant: 3269; single-domain LDAP 389 / LDAPS 636)
• Biggest risk: forest-wide enumeration of every domain’s users, groups, SPNs, and cross-domain memberships from one bind — anonymous or authenticated, in the clear
• Mitigation: disable anonymous binds, enforce LDAP signing + channel binding, prefer encrypted 3269, restrict 3268/3269 to management ranges, purge secrets from attributes, patch, and monitor for mass GC enumeration