Active Directory port requirements are essential for secure, reliable authentication and service communication in Windows environments. Understanding which ports are used and how they behave helps teams design resilient directory services and troubleshoot connectivity issues effectively.
When Active Directory components, replication links, and dependent protocols traverse firewalls, precise port planning reduces outages and security exposure. This article covers the most important ports, protocols, and operational guidance for real-world deployments.
| Port | Protocol | Service | Usage Notes |
|---|---|---|---|
| 389 | TCP/UDP | LDAP | Client authentication and directory queries, optionally encrypted via LDAPS on 636. |
| 636 | TCP | LDAPS | LDAP over SSL/TLS for encrypted client and server communication. |
| 88 | TCP/UDP | Kerberos | Authentication tickets and ticket validation across the domain. |
| 53 | TCP/UDP | DNS | Service location and SRV records for domain controller discovery. |
| 445 | TCP | SMB Direct | Modern authentication and file share access, used heavily for replication and DFS. |
Understanding Core Active Directory Port Usage
Active Directory relies on several standardized ports to handle identity traffic, replication, and service discovery. LDAP on 389 and 636 supports user logon and policy evaluation, while Kerberos on 88 provides ticket-based authentication. DNS on 53 enables domain controller location through SRV records, and SMB on 445 allows secure direct access to resources.
Because these services are tightly coupled, blocking or misrouting a single port can cause widespread authentication failure or replication breakdown. Teams must align firewall rules, network segmentation, and application whitelisting with the documented Active Directory port set to maintain seamless operations across sites and hybrid environments.
Monitoring connection attempts and protocol-specific errors offers visibility into blocked traffic and misconfigured clients. By correlating logs from domain controllers, perimeter devices, and endpoint agents, administrators can quickly identify where Active Directory port access is denied or abused.
Securing LDAP and LDAPS Traffic
LDAP port 389 handles a large portion of directory operations, including searches, authentication binds, and group membership checks. In mixed or high-security environments, it is best practice to restrict clear text LDAP to trusted subnets and use LDAPS on port 636 for encryption.
Deploying certificate-based authentication and mutual TLS strengthens identity assurance when using LDAPS. Proper certificate lifecycle management, including renewal and revocation checks, prevents unexpected service outages caused by expired or untrusted LDAP SSL certificates.
When legacy applications require LDAP, consider tunneling the traffic over IPsec or using LDAPS to reduce exposure of credentials and policy data on the network. This approach balances compatibility with modern security expectations for directory services.
Kerberos Authentication and Port 88
Kerberos authentication depends on port 88 for both initial ticket granting and ticket renewal operations. This protocol underpins single sign-on experiences for domain-joined workloads and interactive user sessions.
Time synchronization across domain controllers and clients is critical, because Kerberos tickets include strict validity windows. Clock drift can lead to repeated authentication failures that appear as port or service issues, even when network paths are healthy.
Firewalls between clients and domain controllers must allow bidirectional TCP and UDP 88 to support full Kerberos flows. In larger environments, fine-grained password policies and constrained delegation configurations should be verified alongside port rules to ensure seamless access.
DNS, SMB, and Replication Ports
DNS port 53 is indispensable for Active Directory, since domain controllers register and query SRV records that enable service discovery. Both TCP and UDP must be allowed, and DNS Security extensions help prevent cache poisoning attacks targeting directory lookups.
SMB port 445 is the backbone of replication, DFS referrals, and direct access to sysvol and NETLOGON shares. Replication links use this port extensively, and blocking it can silently break domain controller synchronization while leaving initial authentication seemingly intact.
For remote management and administrative tools, additional ports may be required, but they should be narrowly scoped to management hosts and monitored for misuse. Consistent segmentation and application allowlisting reduce the attack surface while keeping day-to-day operations smooth.
Operational Best Practices for Active Directory Ports
- Map required Active Directory ports across all network segments, including remote offices and branch locations.
- Enforce TLS for LDAP by using LDAPS on 636 and retiring clear text LDAP where possible.
- Monitor Kerberos failures and correlate with DNS and time sync health indicators.
- Restrict SMB and replication traffic to authorized management stations and domain controllers.
- Document exceptions, publish firewall policies, and review them regularly as applications and infrastructure evolve.
FAQ
Reader questions
Which ports must be open for Active Directory to function correctly across subnets?
Allow TCP and UDP 389 for LDAP, TCP 636 for LDAPS, TCP and UDP 88 for Kerberos, TCP and UDP 53 for DNS, and TCP 445 for SMB replication and file access between domain controllers and clients.
Can I disable LDAP port 389 entirely and rely only on LDAPS?
You can restrict clear text LDAP to trusted administration networks and prioritize LDAPS on 636 for user traffic, but some legacy integrations and tooling still expect LDAP on 389, so evaluate compatibility before fully disabling it.
What happens if UDP 88 is blocked between domain controllers?
Kerberos authentication may fail for certain ticket exchanges and renewal operations, leading to logon errors and application access issues, even when TCP 88 and other directory ports are fully open.
How do DNS and port 53 relate to Active Directory service discovery?
DNS SRV records published by domain controllers allow clients to locate services such as LDAP and Kerberos; without responsive DNS on port 53, clients struggle to identify available controllers and may default to outdated or incorrect endpoints.