[
https://issues.apache.org/jira/browse/AMBARI-24045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120135#comment-18120135
]
Manish M Pillai commented on AMBARI-24045:
------------------------------------------
Picking this up. The request still stands on trunk, so here is a brief note on
what has changed since it was filed in 2018 against 2.6.0, followed by the
design.
h3. What changed since this was filed
* *Cron workaround was broken on 3.0.0:* {{sync-ldap}} failed outright under
Python 3 because REST request bodies were not encoded to bytes, and LDAP login
failed on Java 9+ because the module system blocks Spring LDAP's reflective
access to {{{}com.sun.jndi.ldap.LdapCtxFactory{}}}. Fixed in AMBARI-26620.
Until recently, there was no working cron workaround on current Ambari.
* *LDAP config location shifted:* LDAP connectivity configuration moved out of
{{ambari.properties}} into the DB-backed {{ambari-configuration}} table under
the {{ldap-configuration}} category ({{{}ambari.ldap.*{}}}), managed via
{{setup-ldap}} and the REST API. Sync itself, however, remains CLI-only.
* *Windows support removed:* Windows server support was removed, so
{{conf/windows/ambari.properties}} no longer exists and only the Unix
properties file requires the new settings.
* *In-process service pattern established:* Ambari-server now runs six
{{@AmbariService}} instances ({{{}AmbariServerAlertService{}}},
{{{}AlertNoticeDispatchService{}}}, {{{}CachedAlertFlushService{}}},
{{{}MetricsRetrievalService{}}}, {{{}RetryUpgradeActionService{}}},
{{{}LogSearchDataRetrievalService{}}}), each configured via
{{{}ambari.properties{}}}. Periodic LDAP sync aligns directly with this design
pattern.
h3. Why in-process rather than a documented cron recipe
The core issue is credential security. {{sync_ldap()}} in {{setupSecurity.py}}
authenticates to Ambari's REST API with HTTP Basic using an Ambari *admin*
account. Non-interactively, this requires passing
{{-{-}ldap-sync-admin-name{-}}} and {{{}-ldap-sync-admin-password{}}}, exposing
credentials in a crontab, wrapper script, or process list ({{{}ps{}}}).
Running in-process calls
{{AmbariManagementController.synchronizeLdapUsersAndGroups()}} directly. This
completely eliminates credentials, HTTP hops, and local TLS trust setup.
Additionally, the service lifecycle ties directly to the server, fixed-delay
scheduling prevents overlapping runs, and execution logs output cleanly to
{{{}ambari-server.log{}}}.
h3. Implementation
Created {{{}LdapSyncScheduler{}}}, extending Guava's
{{AbstractScheduledService}} and annotated with {{{}@AmbariService{}}}.
{{ControllerModule}} classpath-scans for the annotation and registers it with
Guava's {{{}ServiceManager{}}}, so *{*}no changes to {{AmbariServer.java}} or
{{ControllerModule}} are required{*}*.
Each tick re-reads the enabled flag, constructs users/groups
{{LdapSyncRequest}} objects, and invokes {{synchronizeLdapUsersAndGroups()}} —
the same method backing the REST endpoint and CLI. The method is already
{{{}synchronized{}}}, ensuring scheduled and manual syncs serialize safely.
New properties (disabled by default):
{code:java|title=ambari.properties}
ldap.sync.auto.enabled=false
ldap.sync.auto.interval.minutes=60
ldap.sync.auto.type=existing # existing | all
ldap.sync.auto.initial.delay.minutes=5
ldap.sync.auto.post.process.existing.users=false
{code}
Robustness & Unattended Handling:
* Dynamic re-reads: Enabled flag, sync type, and post-process options are
evaluated per tick and take effect without restarting. Interval and initial
delay require a restart.
* Fallbacks: Invalid sync types fall back to {{existing}} with a warning log.
Non-numeric or non-positive minute intervals fall back to defaults (avoiding
startup failures or zero-interval tight loops).
* Error isolation: LDAP connection failures are logged and retried next tick
rather than escaping and terminating {{AbstractScheduledService}} permanently.
h3. Compatibility
Disabled by default — zero behavior changes until explicitly enabled. The
{{sync-ldap}} CLI and REST endpoints remain unchanged. Upgraded installations
automatically fall back to hardcoded defaults in {{Configuration.java}} if
properties are missing from {{{}ambari.properties{}}}. No database schema
changes or upgrade catalog modifications are included.
h3. Open design question for reviewers
Properties were placed in {{ambari.properties}} because every other
{{@AmbariService}} interval lives there today (e.g.,
{{{}alerts.cache.flush.interval{}}}). An alternative would be placing them in
the DB-backed {{ldap-configuration}} table to allow UI configuration, but that
would require schema updates and upgrade catalog entries.
Quartz (via {{{}ExecutionScheduler{}}}) was intentionally avoided as it
persists dynamic user schedules to the database, whereas this is a static
internal server task.
h3. Testing
* {{LdapSyncSchedulerTest}} (7 unit tests): Covers iteration execution, type
fallback handling, exception isolation, and option pass-through.
* {{ConfigurationTest}} (+3 unit tests): Validates fallback parsing for bad
intervals/delays and property defaults.
Assigning to myself; PR attached.
https://github.com/apache/ambari/pull/4225
> Ambari schedule LDAP user/group sync to occur periodically instead of
> requiring manual CLI command with admin creds
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AMBARI-24045
> URL: https://issues.apache.org/jira/browse/AMBARI-24045
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server, security
> Affects Versions: 2.6.0
> Environment: HDP 2.6
> Reporter: Hari Sekhon
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Request to add LDAP user/group sync scheduling to occur automatically
> periodically (eg. hourly) rather than requiring a manual external CLI ambari
> sync-ldap command which prompts for admin creds which is less safe to
> schedule (as it would require embedding admin creds somewhere and in secure
> audited environments without the generic 'admin' account this would mean some
> admin's personal credentials).
> Right now Ambari is a sticking point in environments where everything is AD
> integrated as it is the only thing that doesn't pick up the new user in a
> group - it waits until one can find somebody with the right admin creds to
> grant a new admin access they should automatically inherit to Ambari via
> group memberships.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
