Ambari AD Sync On Groups No Longer Working In Ambari Versions > 2.1.1

[#1]

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.

[#2]

Which directory server are you using?

[#3]

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.

[#4]

We've recently found an issue where a case insensitive match is not occurring with the groupMembershipAttr. So if you had groupMembershipAttr=CN, it won't match any objects in the directory due to the wrong LDAP search filter being applied. Can you check that and set groupMembershipAttr=cn instead?

[#5 · Accepted solution]

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

[#6]

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. )