Member since
03-15-2016
5
Posts
4
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2374 | 03-23-2016 06:13 PM |
03-24-2016
06:18 PM
Paul, Looks like the Ambari 2.2.1 LDAP selection logic is fouled up as you noted. I was able to pull in the group memberships from Windows AD using these ambari.properties file values (only relevant properties shown): authentication.ldap.baseDn=ou=myorgunit,ou=mydomain,ou=com {masked to protect security} authentication.ldap.dnAttribute=distinguishedName authentication.ldap.groupMembershipAttr=member authentication.ldap.groupNamingAttr=cn {Note that for Windows AD/Server 2008 R2, group attributes: cn, name and sAMAccountName all contain the same value which is the group name so either of these three values should work} authentication.ldap.groupObjectClass=group {also can be top} authentication.ldap.userObjectClass=user {also can be top;person;organizationalPerson} authentication.ldap.usernameAttribute=sAMAccountName While the membership information now pulls in from Windows AD to Ambari 2.2.1 using "ambari-server sync-ldap --all" with the groupNamingAttr=cn and groupMembershipAttr=member, Ambari is now pulling in ALL AD users who are members of the AD group. Because my baseDn=ou=myorgunit,ou=mydomain,ou=com, I should only be pulling the subset of AD group members who are actually contained in the "myorgunit" organizational unit (OU), not ALL AD group members in the host domain. (Changed the groupNamingAttr=cn from =sAMAccountName for Ambari 2.1.1 and it works as expected i.e. doesn't bring in any additional users, but maintains group membership as before. )
... View more
03-23-2016
06:13 PM
2 Kudos
Hi Paul, The value for the authentication.ldap.groupMembershipAttr property for Windows AD is, I believe, "member" rather than "cn". I did try various casing permutations on the value "member" along with "cn." Here's our full ambari.properties file that worked with Ambari 2.1.1 with all private information masked using a "myobject" naming convention: [This handy tool (AD Explorer) lets you browse Windows AD by pointing to your domain controller which is how I verified that the AD LDAP attribute names were correct: https://technet.microsoft.com/en-us/sysinternals/adexplorer ] NOTE: Our configuration uses both SSL https://myambariserver:8443 and non-anonymous ldap binding with secure ldap (ldaps) authentication to our Windows domain controllers, all of which worked with HDP 2.3/Ambari 2.1.1. # Copyright 2011 The Apache Software Foundation
#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership. The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License. #
#Thu Mar 17 11:32:56 EDT 2016
agent.package.install.task.timeout=1800
agent.task.timeout=900
agent.threadpool.size.max=25
ambari-server.user=root
ambari.ldap.isConfigured=true
ambari.python.wrap=ambari-python-wrap
api.authenticate=true
api.ssl=true
authentication.ldap.baseDn=ou=myambariusersandgroupsorganizationalunit,dc=mydomain,dc=com
authentication.ldap.bindAnonymously=false
authentication.ldap.dnAttribute=distinguishedName
authentication.ldap.groupMembershipAttr=member
authentication.ldap.groupNamingAttr=sAMAccountName
authentication.ldap.groupObjectClass=group
authentication.ldap.managerDn=myldapmanageruser
authentication.ldap.managerPassword=/etc/ambari-server/conf/ldap-password.dat
authentication.ldap.primaryUrl=mydomaincontroller-dc1.mydomain.com:636
authentication.ldap.referral=ignore
authentication.ldap.secondaryUrl=mydomaincontroller-dc2.mydomain.com:636
authentication.ldap.useSSL=true
authentication.ldap.userObjectClass=user
authentication.ldap.usernameAttribute=sAMAccountName
bootstrap.dir=/var/run/ambari-server/bootstrap
bootstrap.script=/usr/lib/python2.6/site-packages/ambari_server/bootstrap.py
bootstrap.setup_agent.script=/usr/lib/python2.6/site-packages/ambari_server/setupAgent.py
client.api.ssl.cert_name=https.crt
client.api.ssl.key_name=https.key
client.api.ssl.port=8443
client.security=ldap
client.threadpool.size.max=25
common.services.path=/var/lib/ambari-server/resources/common-services
custom.action.definitions=/var/lib/ambari-server/resources/custom_action_definitions
java.home=/usr/jdk64/jdk1.8.0_40
java.releases=jdk1.8,jdk1.7
jce.download.supported=true
jce.name=jce_policy-8.zip
jdk.download.supported=true
jdk.name=jdk-8u40-linux-x64.tar.gz
jdk1.7.desc=Oracle JDK 1.7 + Java Cryptography Extension (JCE) Policy Files 7
jdk1.7.dest-file=jdk-7u67-linux-x64.tar.gz
jdk1.7.home=/usr/jdk64/
jdk1.7.jcpol-file=UnlimitedJCEPolicyJDK7.zip
jdk1.7.jcpol-url=http://public-repo-1.hortonworks.com/ARTIFACTS/UnlimitedJCEPolicyJDK7.zip
jdk1.7.re=(jdk.*)/jre
jdk1.7.url=http://public-repo-1.hortonworks.com/ARTIFACTS/jdk-7u67-linux-x64.tar.gz
jdk1.8.desc=Oracle JDK 1.8 + Java Cryptography Extension (JCE) Policy Files 8
jdk1.8.dest-file=jdk-8u40-linux-x64.tar.gz
jdk1.8.home=/usr/jdk64/
jdk1.8.jcpol-file=jce_policy-8.zip
jdk1.8.jcpol-url=http://public-repo-1.hortonworks.com/ARTIFACTS/jce_policy-8.zip
jdk1.8.re=(jdk.*)/jre
jdk1.8.url=http://public-repo-1.hortonworks.com/ARTIFACTS/jdk-8u40-linux-x64.tar.gz
kerberos.keytab.cache.dir=/var/lib/ambari-server/data/cache
metadata.path=/var/lib/ambari-server/resources/stacks
recommendations.dir=/var/run/ambari-server/stack-recommendations
resources.dir=/var/lib/ambari-server/resources
rolling.upgrade.max.stack=
rolling.upgrade.min.stack=HDP-2.2
security.server.keys_dir=/var/lib/ambari-server/keys
server.connection.max.idle.millis=900000
server.execution.scheduler.isClustered=false
server.execution.scheduler.maxDbConnections=5
server.execution.scheduler.maxThreads=5
server.execution.scheduler.misfire.toleration.minutes=480
server.fqdn.service.url=http://169.254.169.254/latest/meta-data/public-hostname
server.http.session.inactive_timeout=1800
server.jdbc.database=postgres
server.jdbc.database_name=ambari
server.jdbc.postgres.schema=ambari
server.jdbc.user.name=ambari
server.jdbc.user.passwd=/etc/ambari-server/conf/password.dat
server.os_family=redhat6
server.os_type=centos6
server.persistence.type=local
server.stages.parallel=true
server.tmp.dir=/var/lib/ambari-server/data/tmp
server.version.file=/var/lib/ambari-server/resources/version
shared.resources.dir=/usr/lib/ambari-server/lib/ambari_commons/resources
skip.service.checks=false
ssl.trustStore.password=mypassword
ssl.trustStore.path=/etc/ambari-server/keys/myldapmanageruser-keystore.jks
ssl.trustStore.type=jks
stackadvisor.script=/var/lib/ambari-server/resources/scripts/stack_advisor.py
ulimit.open.files=10000
views.request.connect.timeout.millis=5000
views.request.read.timeout.millis=10000
webapp.dir=/usr/lib/ambari-server/web
... View more
03-17-2016
04:47 PM
Windows Active Directory (AD) Server 2008 R2 with all patches. I have a running Ambari 2.1.1 (HDP 2.3 stack) cluster where the "ambari-server ldap-sync --all" command is working fine. I was creating a sandbox with the latest 2.4 stack and Ambari 2.2.1 and the memberships don't get added in the summary listing after executing "ambari-server ldap-sync --all" (both users and groups are imported, but not group membership). After blowing away HDP 2.4 and reinstalling HDP 2.3 with Ambari 2.1.1 in the sandbox using the identical configuration as the production cluster, the memberships are again synced correctly. In both cases, AD users can successfully sign-in to Ambari. However, the newer Ambari version will not place the AD users in their proper AD group.
... View more
03-17-2016
03:58 PM
1 Kudo
AD users and groups successfully sync to Ambari, but the group membership link is no longer being replicated. This code works in Ambari 2.1.1, but seems to have broken in newer versions of Ambari. Synchronized AD users are no longer members of the appropriate AD group in Ambari.
... View more
Labels:
- Labels:
-
Apache Ambari