"Why port 389?"
A customer recently emailed me asking a few questions about the Unix agent communication security with Active Directory
- "Why does the Centrify Unix agent (adclient) communicate with Active Directory over port 389?
- How is this communucation secured?
- What are the implications to Active Directory? Specifically, how do we protect Active Directory against unsigned/unencrypted LDAP requests?"
Typically, this question tends to come from Security/Compliance and Unix teams. From their vantage, interacting with LDAP over 389 raises a flag, where traditionally communications over this port tend to be unencrypted. If the question comes from the Active Directory team, they are usually looking for confirmation and assurance that our interactions with Active Directory align with best practices and their secrity expecations.
1) Why port 389: The short answer is that the Centrify Unix agent's approach/design is consistent with how Windows computers and services securely communicate with AD and other kerberos principals. Explained below…
2) Secure Active Directory communication: The Centrify Unix agent authenticates and encrypts all communications with Active Directory using Kerberos (GSSAPI). This is referred to as a "signed and sealed" connection. The agent encrypts its payload using a kerberos session-key before sending over the wire to Active Directory. We do not use LDAP over SSL/TLS. This approach depends on certificates (along with the certificate management headaches that come with).
3) Rejecting unsigned/unencrypted LDAP requests: Microsoft advises we configure servers to reject Simple Authentication and Security Layer (SASL) binds that do not request signing or reject LDAP simple binds that are performed in the clear. This AD group policy configuration ensures that “non-kerberized” LDAP client requests communicate with AD over SSL/TLS (e.g. Port 636). The following Microsoft article explains further.