Port 3269 – MSFT-GC-SSL (Microsoft Global Catalog)

Port 3269 is the default port for the Active Directory Global Catalog over SSL (MSFT-GC-SSL) — the encrypted, forest-wide LDAP index of every object in an Active Directory forest. The Global Catalog is a partial, read-only replica that every Global Catalog domain controller keeps of every domain in the forest, so a single query on 3269 reaches across domain boundaries that the ordinary domain LDAP ports never cross. It’s the implicit-TLS sibling of the cleartext Global Catalog on port 3268 — exactly the way LDAPS on port 636 is the encrypted counterpart of LDAP on port 389: TLS is negotiated from the first byte, before any directory data crosses the wire. Where 3269 answers, you aren’t looking at one domain controller — you’re looking at a read-only map of the whole forest, encrypted on the wire but wide open to anyone who can bind.

Why It’s Open

The Global Catalog is not optional plumbing — Active Directory 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. Microsoft exposes the SSL Global Catalog on 3269 automatically the moment a valid certificate lands on a domain controller that holds the Global Catalog role. Where port 3269 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. Note the split: 389/636 are single-domain LDAP/LDAPS, while the forest-wide Global Catalog runs on 3268 (LDAP, cleartext) and 3269 (LDAP over SSL). The GC also only carries a partial attribute set — a subset of each object’s attributes flagged for replication to the catalog — and it’s read-only, so writes still go to the object’s home domain controller 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 3269 valuable to an attacker. One authenticated 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. TLS encrypts the channel, so a WAF or IDS on the wire never sees the queries.
• Anonymous / null bind still leaks over TLS. Encryption is not authorization. If the directory permits an unauthenticated bind, an attacker who trusts the certificate dumps the forest-wide catalog over 3269 — the padlock just hides it from the network.
• Cross-domain and cross-trust reconnaissance. Because the GC spans the forest, an attacker who has a foothold in one domain uses 3269 to map universal groups, foreign security principals, and admin relationships in sibling domains without ever touching those domains’ own controllers — the fastest way to plan a cross-domain escalation.
• NTLM relay and the channel-binding question. The GC 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). LDAPS/GC-SSL with channel binding (EPA) defeats the relay — which is why the fix leans on the encrypted listener rather than the cleartext one.
• Certificate and TLS weaknesses on the listener. Self-signed, expired, or weak-key certs on 3269 let a client that skips validation be man-in-the-middled — the session is “encrypted” to an attacker’s certificate. SSLv3/TLS 1.0, RC4, or export ciphers invite downgrade attacks, and an unpatched OpenSSL behind the GC-SSL port is exposed to TLS-layer bugs like Heartbleed.

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 3269 <target>

nmap labels 3269 as the SSL Global Catalog (globalcatLDAPssl / msft-gc-ssl) and, with -sV, confirms TLS is wrapping a directory. Seeing 3268 and 3269 open alongside 389/636 confirms the host is a Global Catalog domain controller.

Inspect the certificate and TLS configuration

nmap -p 3269 --script ssl-cert,ssl-enum-ciphers <target>

openssl s_client -connect <target>:3269 -showcerts

sslscan <target>:3269

ssl-cert dumps the certificate subject, issuer, and validity; ssl-enum-ciphers grades every protocol and cipher the GC-SSL listener accepts, exposing self-signed/expired certs and weak SSLv3/TLS 1.0/RC4 support.

Query the Global Catalog forest-wide over 3269

# RootDSE over implicit TLS; LDAPTLS_REQCERT=never ignores an untrusted cert
LDAPTLS_REQCERT=never ldapsearch -H ldaps://<target>:3269 -x -s base namingContexts

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

# Cross-domain group membership — universal groups resolve here
LDAPTLS_REQCERT=never ldapsearch -H ldaps://<target>:3269 -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 3269 — pivot to LDAPS on 636 (or LDAP on 389) against the object’s home domain controller for the full record.

Authenticated enumeration with windapsearch and NetExec

# Point NetExec's LDAP module at the SSL Global Catalog port
nxc ldap <target> --port 3269 -u user -p 'Password123' --users --groups

# windapsearch over the secure channel for forest-wide user/group dumps
windapsearch.py --dc-ip <target> --secure -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.

Log every anonymous bind, weak certificate, 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

The Global Catalog is served by the same LDAP and TLS stack as ordinary domain LDAP, so it inherits the LDAP-service and TLS-listener CVEs rather than having “port 3269” bugs of its own. The two below are the ones that most directly apply to a GC-SSL listener; for the full LDAP CVE history 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 — 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. This is the flaw that makes GC-SSL with channel binding the mitigation rather than the target — affects Windows 7 SP1 through Server 2016.
• CVE-2014-0160 — “Heartbleed” in OpenSSL 1.0.1 before 1.0.1g (CVSS 7.5). A crafted TLS heartbeat triggers a buffer over-read that leaks process memory — private keys, session data, credentials — from any TLS listener running the vulnerable OpenSSL, including a Global Catalog over SSL service on 3269. It’s a flaw in the TLS layer, not in LDAP or the GC itself, which is why it only bites a DC that terminates TLS with unpatched OpenSSL rather than the Windows SChannel stack. Proof-of-concept archived on Exploit-DB 32745.

Mitigation

• Require LDAP signing and channel binding; disable unsigned LDAP. On domain controllers, enforce signing and set channel binding to required (ADV190023) so NTLM relay to the GC’s LDAP service fails and clients are pushed to sealed LDAP or GC-SSL. This is the single most important AD hardening around 389/636/3268/3269.
• Disable anonymous and null binds. Encryption doesn’t stop an unauthenticated forest-wide dump; require authentication for every directory read, including on the Global Catalog.
• 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.
• Use valid, CA-issued certificates and validate them. Never rely on self-signed or expired certs on 3269, and configure clients to validate the certificate — disabling validation in production hands an attacker a MITM.
• Enforce TLS 1.2+ with strong ciphers. Disable SSLv3, TLS 1.0/1.1, RC4, and export ciphers on the GC-SSL listener; confirm with ssl-enum-ciphers or testssl.sh.
• Monitor for mass LDAP/GC enumeration and patch DCs. Alert on BloodHound-style bulk directory reads against the Global Catalog, and keep Windows and any TLS-terminating component current to close relay- and Heartbleed-class exposure.

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 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 3269, 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, and the foreign security principals that reveal which accounts in other domains hold rights in this one. From that one encrypted query they build a cross-domain attack path — spot a service account in the root domain that’s Kerberoastable, or an admin group whose membership crosses a trust — without ever scanning or authenticating to the other domains’ controllers, and with the queries hidden inside TLS where a network sensor can’t read them. The lesson is that the Global Catalog’s forest-wide reach is a feature to the enterprise and a gift to an attacker: turning on 3269 encrypts the channel, but the exposure is the data, so it has to be paired with disabled anonymous binds, enforced signing and channel binding, and firewalling the GC to trusted ranges.

FAQ

What is port 3269 used for?

Port 3269 carries the Active Directory Global Catalog over SSL (MSFT-GC-SSL) — encrypted, forest-wide LDAP lookups. A Global Catalog domain controller answers queries about objects in every domain of the forest, and 3269 is the variant wrapped in TLS from the first byte. It’s the secure counterpart of the cleartext Global Catalog on port 3268.

What is the difference between port 3268 and 3269?

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

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 3269 TCP or UDP?

TCP. The Global Catalog over SSL binds, searches, and directory operations all run over TCP 3269. There’s no UDP equivalent for the SSL Global Catalog.

Is port 3269 secure, and can it be exploited?

3269 is the secure variant — it encrypts the channel — but the port itself is not a guarantee. It’s only as strong as its certificate and cipher configuration: a self-signed cert clients don’t validate can be man-in-the-middled, and weak protocols invite downgrade attacks. Encryption also doesn’t stop an anonymous bind or authenticated forest-wide enumeration — those run fine over 3269, just hidden inside TLS. Treat a reachable 3269 as a forest-wide directory to enumerate and a TLS listener to test.

TL;DR

• Service: Active Directory Global Catalog over SSL (MSFT-GC-SSL) — encrypted, forest-wide LDAP index over implicit TLS
• Default port: 3269 TCP (cleartext GC variant: 3268; single-domain LDAP 389 / LDAPS 636)
• Biggest risk: forest-wide enumeration of every domain’s users, groups, and cross-domain memberships from one bind — anonymous or authenticated, hidden inside TLS
• Mitigation: disable anonymous binds, enforce LDAP signing + channel binding, restrict 3268/3269 to management ranges, deploy valid CA-issued certs with client validation, require TLS 1.2+, and monitor for mass GC enumeration