Skip to content

Conversation

danielashare
Copy link
Contributor

We recently added the locating of LDAP servers through DNS SRV records. A customer requested that this same functionality be added for discovering KDC servers.

This PR adds optional configuration:

 locate_kdc_server:
    enabled: true
    site: "my-site" # optional
    port: 88 # optional, overrides DNS port

When enabled, Teleport will get the address of a KDC server from the AD domain when a user connects to a desktop.

changelog: Added auto discovery of KDC servers through SRV records

Copy link

github-actions bot commented Oct 14, 2025

Amplify deployment status

Branch Commit Job ID Status Preview Updated (UTC)
danielashare/locate-kdc HEAD 1 ✅SUCCEED danielashare-locate-kdc 2025-10-14 16:16:45

Copy link
Contributor

@ptgott ptgott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're planning to release backports of the new fields in a minor version, we should indicate the minor version this will be available in the docs.

Copy link
Contributor

@boxofrad boxofrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! 👏🏻

Not a blocker, but I notice we didn't update any tests for the actual DNS resolution. Do we have tests for that part?

@danielashare
Copy link
Contributor Author

danielashare commented Oct 15, 2025

If we're planning to release backports of the new fields in a minor version, we should indicate the minor version this will be available in the docs.

@ptgott Thanks for this, good idea. I've slightly changed how this will look from a configuration point of view to the user. Instead of having a separate locate_kdc_server field added, the functionality will be combined with the existing locate_server field. Should I add a note saying "as of version v18.2.8 [this field also does x]"?

Comment on lines +1353 to +1379
dialer := net.Dialer{}
dial := func(dialCtx context.Context, network, address string) (net.Conn, error) {
return dialer.DialContext(dialCtx, network, address)
}

// In development environments, the system's default resolver is unlikely to be
// able to resolve the Active Directory SRV records needed for server location,
// so we allow overriding the resolver.
if resolverAddr := os.Getenv("TELEPORT_KDC_RESOLVER"); resolverAddr != "" {
s.cfg.Logger.DebugContext(ctx, "Using custom DNS resolver address", "address", resolverAddr)
// Check if resolver address has a port
host, port, err := net.SplitHostPort(resolverAddr)
if err != nil {
host = resolverAddr
port = "53"
}

customResolverAddr := net.JoinHostPort(host, port)
dial = func(ctx context.Context, network, address string) (net.Conn, error) {
return dialer.DialContext(ctx, network, customResolverAddr)
}
}

resolver := &net.Resolver{
PreferGo: true,
Dial: dial,
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could all of this be abstracted behind some kind of "resolver" interface? One that we could initialize and pass to WindowsService during construction?

It seems like picking a resolver strategy is a separate concern from actually using it to resolve the KDC address, and the logic for each may evolve differently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants