[
https://issues.apache.org/jira/browse/AMBARI-22667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301744#comment-16301744
]
Sandor Molnar commented on AMBARI-22667:
----------------------------------------
[~rlevas]
Regarding obsoletePropertyName: I'm not sure how the migration process works
but should not we be prepared for the following scenario: the user already
configured LDAP in 2.6.X (or even an earlier version). When migrating to 3.0.0
do we read ambari.properties in 2.6.X and we save that configuration in the DB?
If so, how do we know what to set in the new fields if we did not not their
previous name?
If this is not the case - the user will re-configure LDAP in 3.0.0 manually -
then the only thing we gain is documentation (maybe useful for support cases,
but I'm not sure).
Please let me know your thoughts.
> Use internal LDAP configuration values rather than ambari.properties values
> when accessing the configured LDAP server
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: AMBARI-22667
> URL: https://issues.apache.org/jira/browse/AMBARI-22667
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Affects Versions: 3.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Labels: ldap
> Fix For: 3.0.0
>
>
> Use internal LDAP configuration values rather than ambari.properties values
> when accessing the configured LDAP server for LDAP sync and authentication.
> * Deprecate {{setup-ldap}} from the {{ambari-server}} script.
> ** Rather then perform any operations, alert user to configure LDAP
> integration from the Ambari UI
> * Lookup LDAP-specific properties from the Ambari configuration data under
> the "ldap-configuration" category.
> * Remove relevant properties from
> {{org.apache.ambari.server.configuration.Configuration}}
> ** ambari.ldap.isConfigured
> ** authentication.ldap.useSSL
> ** authentication.ldap.primaryUrl
> ** authentication.ldap.secondaryUrl
> ** authentication.ldap.baseDn
> ** authentication.ldap.bindAnonymously
> ** authentication.ldap.managerDn
> ** authentication.ldap.managerPassword
> ** authentication.ldap.dnAttribute
> ** authentication.ldap.usernameAttribute
> ** authentication.ldap.username.forceLowercase
> ** authentication.ldap.userBase
> ** authentication.ldap.userObjectClass
> ** authentication.ldap.groupBase
> ** authentication.ldap.groupObjectClass
> ** authentication.ldap.groupNamingAttr
> ** authentication.ldap.groupMembershipAttr
> ** authorization.ldap.adminGroupMappingRules
> ** authentication.ldap.userSearchFilter
> ** authentication.ldap.alternateUserSearchEnabled
> ** authentication.ldap.alternateUserSearchFilter
> ** authorization.ldap.groupSearchFilter
> ** authentication.ldap.referral
> ** authentication.ldap.pagination.enabled
> ** authentication.ldap.sync.userMemberReplacePattern
> ** authentication.ldap.sync.groupMemberReplacePattern
> ** authentication.ldap.sync.userMemberFilter
> ** authentication.ldap.sync.groupMemberFilter
> ** ldap.sync.username.collision.behavior
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)