Follow these steps to create keytabs and principals:

For Ranger Admin:

For Ranger Lookup:

For Ranger Usersync:

For Ranger Tagsync

For Ranger KMS:

If the Kerberos server and admin are on different hosts, copy the keytab on the admin host, assign permission to user ranger, and change the permissions.

scp the <rangeradmin_keytab_file> to <new_path>
chown ranger <rangeradmin_keytab_path>
chmod 400 <rangeradmin_keytab_path>

Use kdestroy to delete the Keberos credentials cache file.

Set the following properties and values in the /etc/hadoop/conf/core-site.xml file:

The following is an example of a core-site.xml file with the properties set for Kerberos:

<configuration>

    <property>
      <name>fs.defaultFS</name>
      <value>hdfs://ranger-upgrade-0707-2.openstacklocal:8020</value>
      <final>true</final>
    </property>

    <property>
      <name>hadoop.security.authentication</name>
      <value>kerberos</value>
    </property>

   <property>
      <name>hadoop.security.authorization</name>
      <value>true</value>
   </property>

<property>
      <name>hadoop.security.auth_to_local</name>
      <value>RULE:[1:$1@$0](ambari-qa-cluster1@EXAMPLE.COM)s/.*/ambari-qa/
RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//
RULE:[2:$1@$0](dn@EXAMPLE.COM)s/.*/hdfs/
RULE:[2:$1@$0](nn@EXAMPLE.COM)s/.*/hdfs/
RULE:[2:$1@$0](rangeradmin@EXAMPLE.COM)s/.*/ranger/
RULE:[2:$1@$0](rangerusersync@EXAMPLE.COM)s/.*/rangerusersync/
DEFAULT</value>
    </property>

</configuration>

Stop the ranger-admin service.

Add the following properties and values to the ranger-admin install.properties file:

Execute the setup.sh script.

Start the ranger-admin service.

Stop the ranger-usersync service.

Add the following properties and values to the ranger-sync install.properties file:

Execute the setup.sh script.

Start the ranger-sync service.

Stop the ranger-tagsync service.

Add the following properties and values to the ranger-tagsync install.properties file:

Execute the setup.sh script.

Start the ranger-tagsync service.

Stop the ranger-kms service.

Add the following properties and values to the ranger-kms install.properties file:

Edit the relevant lines in the install.properties file:

POLICY_MGR_URL=http://<FQDN of ranger admin host>:6080
REPOSITORY_NAME=hadoopdev
Audit info (Solr/HDFS options available)

Enter the following commands to enable the HDFS plugin:

export JAVA_HOME=<JAVA Path>
./enable-hdfs-plugin.sh

Start and stop the namenode:

su hdfs -c "/usr/hdp/current/hadoop-client/sbin/hadoop-daemon.sh stop namenode"
su hdfs -c "/usr/hdp/current/hadoop-client/sbin/hadoop-daemon.sh start namenode"

In the custom repo configurationfile, add the component user, for example, hdfs, as a value for each of the following properties:

Verify that the plugin communicates with Ranger admin using the Audit → plugins tab.

Set the following properties in the hdfs-site.xml file:

The following is an example of a hdfs-site.xml file with the properties set for Kerberos:

<property> 
     <name>dfs.permissions</name> 
     <value>true</value> 
     <description> If "true", enable permission checking in
     HDFS. If "false", permission checking is turned
     off, but all other behavior is
     unchanged. Switching from one parameter value to the other does
     not change the mode, owner or group of files or
     directories. </description> 
</property> 
 
<property> 
     <name>dfs.permissions.supergroup</name> 
     <value>hdfs</value> 
     <description>The name of the group of
     super-users.</description> 
</property> 
 
<property> 
     <name>dfs.namenode.handler.count</name> 
     <value>100</value> 
     <description>Added to grow Queue size so that more
     client connections are allowed</description> 
</property> 
 
<property> 
     <name>ipc.server.max.response.size</name> 
     <value>5242880</value> 
</property> 
 
<property> 
     <name>dfs.block.access.token.enable</name> 
     <value>true</value> 
     <description> If "true", access tokens are used as capabilities
     for accessing datanodes. If "false", no access tokens are checked on
     accessing datanodes. </description> 
</property> 
 
<property> 
     <name>dfs.namenode.kerberos.principal</name> 
     <value>nn/_HOST@EXAMPLE.COM</value> 
     <description> Kerberos principal name for the
     NameNode </description> 
</property> 
 
<property> 
     <name>dfs.secondary.namenode.kerberos.principal</name> 
     <value>nn/_HOST@EXAMPLE.COM</value> 
     <description>Kerberos principal name for the secondary NameNode. 
     </description> 
</property> 
 
<property> 
     <!--cluster variant --> 
     <name>dfs.secondary.http.address</name> 
     <value>ip-10-72-235-178.ec2.internal:50090</value> 
     <description>Address of secondary namenode web server</description> 
</property> 
 
<property> 
     <name>dfs.secondary.https.port</name> 
     <value>50490</value> 
     <description>The https port where secondary-namenode
     binds</description> 
</property> 
 
<property> 
     <name>dfs.web.authentication.kerberos.principal</name> 
     <value>HTTP/_HOST@EXAMPLE.COM</value> 
     <description> The HTTP Kerberos principal used by Hadoop-Auth in the HTTP endpoint.
     The HTTP Kerberos principal MUST start with 'HTTP/' per Kerberos HTTP
     SPNEGO specification. 
     </description> 
</property> 
 
<property> 
     <name>dfs.web.authentication.kerberos.keytab</name> 
     <value>/etc/security/keytabs/spnego.service.keytab</value> 
     <description>The Kerberos keytab file with the credentials for the HTTP
     Kerberos principal used by Hadoop-Auth in the HTTP endpoint. 
     </description> 
</property> 
 
<property> 
     <name>dfs.datanode.kerberos.principal</name> 
     <value>dn/_HOST@EXAMPLE.COM</value> 
     <description> 
     The Kerberos principal that the DataNode runs as. "_HOST" is replaced by the real
     host name. 
     </description> 
</property> 
 
<property> 
     <name>dfs.namenode.keytab.file</name> 
     <value>/etc/security/keytabs/nn.service.keytab</value> 
     <description> 
     Combined keytab file containing the namenode service and host
     principals. 
     </description> 
</property> 
 
<property> 
     <name>dfs.secondary.namenode.keytab.file</name> 
     <value>/etc/security/keytabs/nn.service.keytab</value> 
     <description> 
     Combined keytab file containing the namenode service and host
     principals. 
     </description> 
</property> 
 
<property> 
     <name>dfs.datanode.keytab.file</name> 
     <value>/etc/security/keytabs/dn.service.keytab</value> 
     <description> 
     The filename of the keytab file for the DataNode. 
     </description> 
</property> 
 
<property> 
     <name>dfs.https.port</name> 
     <value>50470</value> 
     <description>The https port where namenode
     binds</description> 
</property> 
 
<property> 
     <name>dfs.https.address</name> 
     <value>ip-10-111-59-170.ec2.internal:50470</value> 
     <description>The https address where namenode binds</description> 
</property> 
 
<property> 
     <name>dfs.datanode.data.dir.perm</name> 
     <value>750</value> 
     <description>The permissions that should be there on
     dfs.data.dir directories. The datanode will not come up if the
     permissions are different on existing dfs.data.dir directories. If
     the directories don't exist, they will be created with this
     permission.</description> 
</property> 
 
<property> 
     <name>dfs.access.time.precision</name> 
     <value>0</value> 
     <description>The access time for HDFS file is precise upto this
     value.The default value is 1 hour. Setting a value of 0
     disables access times for HDFS. 
     </description> 
</property> 
 
<property> 
     <name>dfs.cluster.administrators</name> 
     <value> hdfs</value> 
     <description>ACL for who all can view the default
     servlets in the HDFS</description> 
</property> 
 
<property> 
     <name>ipc.server.read.threadpool.size</name> 
     <value>5</value> 
     <description></description> 
</property> 
 
<property> 
     <name>dfs.namenode.kerberos.internal.spnego.principal</name> 
     <value>${dfs.web.authentication.kerberos.principal}</value> 
</property> 
 
<property> 
     <name>dfs.secondary.namenode.kerberos.internal.spnego.principal</name> 
     <value>${dfs.web.authentication.kerberos.principal}</value> 
</property>

For Download Policy to be successful, use the Ranger UI to update the service configuration with the following custom properties for each supported component:

policy.download.auth.users=<Component service user>
tag.download.auth.users=<Component service user>(if tag download)

For Grant/Revoke for Hive and Hbase to be successful, use the Ranger UI to update the service configuration with the following custom property:

policy.grantrevoke.auth.users = <Component service user>

For Test Connection and Resource Lookup to be successful, use the Ranger UI to add lookup user in the permission list of the policies.