LDAP Connector: DC discovery with preference for replication consistency

[JayVDZ]

Summary

Add domain controller discovery and pinning to the LDAP connector to avoid replication lag issues when the administrator configures a domain name rather than a specific DC hostname.

Background

Currently, JIM uses whatever hostname/IP the administrator configures in the Host setting. If they configure the domain name (e.g., domain.local), DNS could return different DCs on each connection (round-robin), leading to potential replication inconsistencies between operations.

For example:

1. Export creates objects on DC1
2. Confirming import queries DC2 (replication not complete)
3. Objects appear "unconfirmed" until replication catches up

Proposed Solution

Add a "Preferred Domain Controller" setting to the LDAP connector:

• If a specific DC hostname is provided, use it (current behaviour)
• If left blank or set to "Auto-discover":
  • On first connection, perform DC discovery for the domain
  • Resolve and store the actual DC hostname in persisted connector data
  • Use that DC for all subsequent operations until:
    • Connection fails (then discover a new DC)
    • Administrator manually changes the setting

Benefits

• Ensures all operations hit the same DC, avoiding replication lag issues
• Reduces administrator burden of knowing which DC to specify
• Provides automatic failover if the pinned DC becomes unavailable
• Aligns with how other ILM systems handle DC selection

Alternatives Considered

1. Document best practice only - Recommend specific DC hostname (current approach, relies on user knowledge)
2. DC pinning per-session - Pin only for duration of run profile (less persistent)
3. DC pinning persistent - Store resolved DC permanently (proposed approach)

References

• Related to partition/container auto-selection feature where replication lag could affect hierarchy refresh after export