When analyzing the packet capture, we observe an unusual sequence during the LDAPS connection attempt:

1. [SYN] from client (1.1.1.1)
2. [SYN, ACK] from server (1.2.3.4)  
3. [ACK] from client completes handshake
4. [PSH, ACK] from client with 194 bytes payload
5. [RST] from server terminates connection

The [PSH, ACK] packet (packet #4) is actually critical - it's the client attempting to initiate the TLS handshake immediately after TCP establishment. The PSH flag indicates the receiving TCP stack should immediately push this data to the application layer (in this case, the GC service).

Common reasons for immediate RST after PSH+ACK:

• Server-side TLS policy rejection (certificate requirements, protocol version)
• Port blocking despite TCP handshake completing
• Service-specific ACLs on the Global Catalog

Instead of telnet, use these diagnostic tools:

# Test basic connectivity
openssl s_client -connect gcfoo.exampleAD.local:3269 -showcerts

# Full packet capture with decryption (if possible)
tcpdump -i eth0 -w ldaps.pcap 'host 1.2.3.4 and port 3269'

# Verify certificate chain
openssl s_client -connect gcfoo.exampleAD.local:3269 -CAfile /path/to/rootCA.pem

On the Global Catalog server, verify:

# PowerShell: Check LDAPS listener status
Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" | 
  Where-Object {$_.Name -match "SSL"}

# Check certificate binding
netsh http show sslcert

Here's a Python script to replicate and diagnose the issue:

import socket
import ssl

def test_ldaps_connection(host, port):
    try:
        sock = socket.create_connection((host, port))
        context = ssl.create_default_context()
        secure_sock = context.wrap_socket(sock, server_hostname=host)
        print("Connection successful! Server certificate:")
        print(secure_sock.getpeercert())
        secure_sock.close()
    except ssl.SSLError as e:
        print(f"SSL Error: {e}")
    except ConnectionResetError:
        print("Server sent RST immediately after handshake")
    except Exception as e:
        print(f"General error: {e}")

test_ldaps_connection("gcfoo.exampleAD.local", 3269)

If you confirm the server rejects connections at the TLS layer:

1. Verify the client presents a valid certificate chain
2. Check for TLS version mismatch (Windows often requires TLS 1.2+)
3. Inspect Windows Event Logs on the GC server for Schannel errors

Example certificate verification command:

openssl verify -CAfile /etc/ssl/certs/AD-CA.pem /path/to/client_cert.pem

When examining your packet capture, let's break down what's happening at the protocol level:

1. [SYN] → Client initiates connection
2. [SYN,ACK] ← Server acknowledges
3. [ACK] → Client completes handshake
4. [PSH,ACK] → Client sends application data
5. [RST] ← Server forcefully closes

The [PSH,ACK] in packet #4 combines two TCP flags:

• PSH (Push): Instructs the receiving system to immediately deliver this data to the application layer
• ACK: Continues the normal acknowledgment process

In your case, the 194-byte payload likely contains the initial LDAPS handshake (TLS ClientHello). Here's what a typical SSL/TLS handshake looks like in hex:

16 03 01 00 c1 01 00 00 bd 03 03 5a 4f 72 59 ...

The immediate [RST] suggests several possible issues:

# Common verification commands
openssl s_client -connect gcfoo.exampleAD.local:3269 -showcerts
ldapsearch -x -H ldaps://gcfoo.exampleAD.local:3269 -b "" -s base

Here's a Python script to test the connection:

import socket
import ssl

def test_ldaps_connection(host, port):
    try:
        sock = socket.create_connection((host, port))
        ssl_sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_NONE)
        print(f"Connected to {host}:{port}")
        print(ssl_sock.version())
        ssl_sock.close()
    except Exception as e:
        print(f"Connection failed: {str(e)}")

test_ldaps_connection("gcfoo.exampleAD.local", 3269)

Check these common culprits:

• Firewall rules blocking port 3269
• Certificate validation failures
• Server-side connection limits
• Protocol version mismatches