Respect to the problem of keeping in sync amb_ranger_admin password between Ranger and Ambari, via the Web UI you can change these values as follows: Ambari Server: into the Ambari Server UI at the Ranger -> Config -> Advanced -> Admin Settings section as stated in the manuals and as you said you had already done. Ranger: into the Ranger Admin UI into Settings -> User/Groups section and searching "User Name: amb_ranger_admin". However if you have already tested and succeeded logging in to the Ranger Admin with this user and the password you have already setup in Ambari this may no be the problem. To go to the source and check the real passwords in the Ambari and Ranger configuration you have to go to the info in the corresponding databases. In Ambari the information is saved into a JSON text entry in the field "ranger_admin_password" from the table "clusterconfig". This table keeps all versions for each configuration type so you will have to search for the last entry on the type "type_name='ranger-env'" and select the field "config_data". A SELECT like following will be useful: SELECT version,create_timestamp,type_name,config_data FROM ambari.clusterconfig WHERE type_name LIKE 'ranger-env' ORDER BY version DESC LIMIT 1 In Ranger you have to check the x_portal_user table and search the password field for the user with the login_id=amb_ranger_env with a select like this: SELECT login_id, password, status from x_portal_user In this case the password field is a hash combining the password and the user name; so you will have to use the following to compare with the previous value: echo -n 'yourpassword{amb_ranger_admin}' | md5sum If the previous passwords are differents and you have done the steps from the beginning in each UI then you have to check why Ambari (most certainly) is not updating your configuration. On the other side if the passwords match, then probably you have another problem with Ambari configuration. ... View more

I keep asking myself because so many people feels the necessity to respond something even when then don't know how to response the original question raised by the user with the problem. When someone post a question here it's supposed they have checked the (sometimes very) basic instructions in the manual, and even more if there is a clear description about that, and about the problem persisting after doing the basic steps as in this case. So, it is a matter of personal pride or winning some points with this forum or even Hortonworks company for the number of useless responses you submit? Not a single response here address the real problem the user is asking about, and most of them are treating the one asking as a total dummy. Please filter yourself, read carefully the submitting question and think I you really are contributing something valuable or asking some feedback important for the "real" problem, before responding as a reflex act, to avoid lowering the quality of this forum and making people lose time reading again and again the very same "quotes" from the (many times incomplete) manuals. ... View more

This article is really very useful but has a silly but confusing (specially for HDP newbies) error where all occurrences of "Ranger user id" and "Ranger Admin Server" must be replaced by "Atlas User ID" and "Atlas Admin Server" respectively. ... View more

At least for version 2.6.3 and above the section "Running import script on kerberized cluster" is wrong. You don't need to provide any of the options (properties) indicated (except maybe the debug one If you want to have debug output) because they are automatically detected and included in the script. Also at least in 2.6.5 a direct execution of the script in a Kerberized cluster will fail because of the CLASSPATH generated into the script. I had to edit this replacing many single JAR files by a glob inside their parent folder in order for the command to run without error. If you have this problem see answer o "Atlas can't see Hive tables" question. ... View more

I have experienced this problem after changing Ambari Server to run as a non privileged user "ambari-server". In my case I can see in the logs (/var/log/ambari-server/ambari-server.log) the following: 12 Sep 2018 22:06:57,515 ERROR [ambari-client-thread-6396] BaseManagementHandler:61 - Caught a system exception while attempting to create a resource: Error occured during stack advisor command invocation: Cannot create /var/run/ambari-server/stack-recommendations This error happens because in CentOS/RedHat /var/run is really a symlink to /run which is a tmpfs filesystem mounted at boot time from RAM. So if I manually create the folder with the required privileges it won't survive a reboot and because the unprivileged user running Ambari Server is unable to create the required directory the error occurs. I was able to partially fix this using systemd-tmpfiles feature by creating a file /etc/tmpfiles.d/ambari-server.conf with following content: d /run/ambari-server 0775 ambari-server hadoop - d /run/ambari-server/stack-recommendations 0775 ambari-server hadoop - With this file in place running "systemd-tmpfiles --create" will create the folders with the required privileges. According to the following RedHat documentation this should be automagically run at boot time to setup everything: https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-systemd-tmpfiles-on-rhel7/ However sometimes this doesn't happens (I don't know why) and I have to run the previous command manually to fix this error. ... View more

In a cluster managed by Ambari, the Atlas admin password for the File Authentication mode must be changed from inside Ambari Server or it will be rewritten after a service restart. This value may be found in section Configs-> Advanced -> Advanced atlas-env -> Admin password as shown in the image bellow ... View more

Yes, you will have to use basically the same configuration done when using a combination of OpenLDAP and MIT KDC for authentication. The only difference is you will be using AD as your LDAP server instead of OpenLDAP, and of course you will have to consider the different schemas for users/groups (samAccountName vs uid, etc). ... View more

If the AD is not providing Kerberos service to the hosts in the cluster (as stated in the question) then there is not chance of the user requesting any TGT from the AD KDC. In that case AD may only be used as an LDAP users identity provider. ... View more

This article is very illustrative but as most of the references in this topic doesn't addresses the problem of Linux users authentication against AD with the previous hosts and kerberos client configurations. For SSSD to work with AD you will have to setup your host's default krb5.keytabs to point to the AD principals (obtained when joining the host to the AD domain) and this is conflicting with the configuration described in the article where the host is supposed to be associated to the MIT KDC realm and default domain. How do we resolve this conflict? ... View more