LDAP Kerberos authentication in JDisc Discovery

Introduction

Access to your directory is an important part of network discovery. How a discovery tool authenticates deserves the same attention as the information it collects.

JDisc Discovery now supports Kerberos user authentication for LDAP connections. Previously, Simple Bind was the only authentication option available for these connections. With Kerberos, you can now choose an alternative that uses tickets to establish identity and brings LDAP authentication into your existing Kerberos trust infrastructure.

For teams reviewing directory security, this provides a practical new option: move away from password-based LDAP binds while keeping directory access part of your discovery workflow.

What changes for LDAP connections?

The new feature adds Kerberos alongside Simple Bind. It expands your choice of authentication methods, allowing you to select the approach that fits your directory environment and security requirements.

This development follows JDisc’s earlier introduction of Kerberos authentication for WMI, SMB, and Windows remote login. The new feature specifically addresses LDAP user authentication. Settings and prerequisites for one protocol should not be assumed to apply unchanged to another.

For an administrator, the central question becomes: should this LDAP connection authenticate through Simple Bind, or use Kerberos tickets?

How Simple Bind and Kerberos differ

With a password-based LDAP Simple Bind, the client sends an identity and password to the directory server. The bind itself does not protect those credentials. TLS must provide confidentiality, for example through LDAPS or StartTLS. Properly configured TLS also verifies the server through its certificate, so an existing Simple Bind connection protected by TLS should not be confused with an unencrypted connection. The LDAP authentication specification explains these separate security mechanisms.

Kerberos takes a different approach. A trusted Key Distribution Center, or KDC, issues tickets that let a client prove its identity to a service. In Active Directory, domain controllers provide the KDC role.

At a high level, the process has three stages:

1. The client authenticates to the KDC and obtains a ticket-granting ticket.
2. It uses that ticket to request a service ticket for the intended LDAP service.
3. It presents the service ticket and cryptographic proof to the LDAP server.

The LDAP authentication exchange therefore uses a ticket rather than carrying the user’s password as a Simple Bind credential. Microsoft’s Kerberos authentication overview describes this trust relationship and ticket exchange.

Where improved security and trust come from

The most direct benefit is the change in how the LDAP client proves its identity. Kerberos avoids sending a reusable password in the LDAP bind and uses credentials issued for a particular service.

Kerberos also supports mutual authentication: the client can verify the service’s identity as well as the service verifying the client. This capability helps establish trust in the intended endpoint when mutual authentication is negotiated. It should not be interpreted as a guarantee that every application enables every Kerberos security option. Microsoft explains the mechanism in its documentation on mutual authentication using Kerberos.

For your operations team, the new LDAP option makes it possible to align discovery authentication more closely with an established Kerberos environment. If your security policy calls for moving away from Simple Bind, JDisc Discovery now offers an authentication alternative to evaluate.

Kerberos still depends on protecting credentials and the systems that use them. Tickets have validity periods, but a stolen usable ticket is sensitive too. The Kerberos protocol specification describes both the protection mechanisms and the assumptions behind them.

Authentication and connection protection work together

Selecting Kerberos answers the question of how the client authenticates. Protecting directory queries and responses is a separate consideration.

TLS provides transport encryption. LDAP SASL mechanisms can also negotiate security layers, depending on the mechanism and configuration. Selecting Kerberos alone does not establish which protection is active for all subsequent LDAP traffic. Review authentication and connection protection together against your directory’s requirements. The distinction is covered in the LDAP security specification.

This is especially useful during a migration: document the protection your existing connection provides before changing its authentication method, then verify the resulting connection against the same requirements.

Prepare your environment before switching

Kerberos relies on more than a valid account password. A few infrastructure checks can save considerable troubleshooting time:

• DNS and server names: Verify that the directory server’s hostname resolves correctly. Kerberos service identities depend on names; an IP address or an unexpected alias can lead to a different result.
• Service principal names: Ensure that the intended LDAP service has the appropriate SPN and that duplicate registrations do not create ambiguity.
• Time synchronization: Keep the discovery server and domain infrastructure synchronized. Kerberos uses timestamps when validating authentication exchanges.
• KDC connectivity: Confirm that the discovery server can reach the required Kerberos infrastructure as well as the LDAP endpoint.

These are common Kerberos dependencies, rather than additional discovery privileges. Microsoft’s Kerberos troubleshooting guidance provides a useful starting point if authentication fails. JDisc’s discovery scenarios also show where Active Directory access credentials fit into a broader discovery configuration.

Begin with one LDAP connection and an account that has the required directory read permissions. Validate authentication, then check that the expected directory information can actually be read. A successful login and sufficient access are two separate checks: Kerberos establishes identity, while directory permissions determine what that identity may access. If connectivity is part of the problem, the JDisc FAQ on discovery requirements and troubleshooting provides a useful reference for protocols, ports, and common access issues.

A practical next step for your directory security

With Kerberos support, Simple Bind is no longer the only way for JDisc Discovery to authenticate users to LDAP. You now have a ticket-based option that can support your organization’s directory security goals and use its established Kerberos trust infrastructure.

Start by reviewing one existing LDAP connection with your directory administrators. Agree on the authentication method, connection protection, and required permissions, then validate the configuration before applying it more broadly.