LDAP Cross-Domain Authentication: Required Firewall Ports for SSSD to Active Directory


2 views

When configuring SSSD (System Security Services Daemon) on Linux to authenticate against a remote Active Directory domain through a firewall, you need to consider several network requirements beyond just basic LDAP ports. The standard LDAP port 389 is necessary but not always sufficient.

The minimum required ports between your NJ domain and NY domain's Active Directory controllers are:

389/tcp  - LDAP (unencrypted)
636/tcp  - LDAPS (SSL encrypted)
88/tcp   - Kerberos authentication
88/udp   - Kerberos authentication
53/tcp   - DNS resolution
53/udp   - DNS resolution

For complete AD integration and to avoid authentication failures, you should also consider opening:

445/tcp  - SMB (for GPO processing)
464/tcp  - Kerberos password change
464/udp  - Kerberos password change
3268/tcp - Global Catalog (for multi-domain forests)
3269/tcp - Global Catalog over SSL

Here's a sample SSSD configuration for cross-domain authentication:

[sssd]
domains = ny.example.com
services = nss, pam

[domain/ny.example.com]
id_provider = ldap
auth_provider = krb5
access_provider = ldap
chpass_provider = krb5

ldap_uri = ldap://ad-dc1.ny.example.com,ldap://ad-dc2.ny.example.com
ldap_search_base = dc=ny,dc=example,dc=com
krb5_server = ad-dc1.ny.example.com,ad-dc2.ny.example.com
krb5_realm = NY.EXAMPLE.COM

Before configuring SSSD, verify basic connectivity using these commands:

# Test LDAP connectivity
ldapsearch -x -H ldap://ad-dc.ny.example.com -b "" -s base

# Test Kerberos connectivity
kinit username@NY.EXAMPLE.COM

# Test DNS resolution
dig SRV _ldap._tcp.ny.example.com

When implementing firewall rules:

  • Allow bidirectional traffic for established connections
  • Consider using persistent connections to minimize port usage
  • Monitor logs for blocked authentication attempts

When authenticating from a Linux domain (NJ) using SSSD against an Active Directory (NY) behind a firewall, the port requirements depend on your authentication method and whether you're using secure LDAP. Here's the complete breakdown:

  • Standard LDAP: TCP 389 (unencrypted)
  • LDAPS (LDAP over SSL): TCP 636
  • Global Catalog: TCP 3268 (unencrypted) or 3269 (SSL)
  • Kerberos: UDP 88 (required for ticket-based auth)
  • DNS: TCP/UDP 53 (for domain controller location)

Here's a sample SSSD configuration for cross-domain authentication:

[domain/NY.example.com]
id_provider = ldap
auth_provider = krb5
ldap_uri = ldap://ny-dc1.example.com,ldap://ny-dc2.example.com
ldap_search_base = dc=example,dc=com
krb5_server = ny-dc1.example.com,ny-dc2.example.com
krb5_realm = EXAMPLE.COM
cache_credentials = True

For a complete solution, you'll need firewall rules allowing:

# Allow LDAP traffic
iptables -A OUTPUT -p tcp --dport 389 -d ny-dc1.example.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 636 -d ny-dc1.example.com -j ACCEPT

# Allow Kerberos
iptables -A OUTPUT -p udp --dport 88 -d ny-dc1.example.com -j ACCEPT

# Allow DNS lookups
iptables -A OUTPUT -p udp --dport 53 -d ny-dns.example.com -j ACCEPT

Test basic connectivity before configuring SSSD:

# Test LDAP (389)
ldapsearch -x -H ldap://ny-dc1.example.com -b "" -s base

# Test LDAPS (636)
ldapsearch -x -H ldaps://ny-dc1.example.com -b "" -s base

# Test Kerberos
kinit username@EXAMPLE.COM