@dsun Most, if not all of the MIT KDC related properties are editable and viewable in the Kerberos Service configuration page. However some of the Active Directory related properties are not. I keep meaning to file a bug report for this. I think the most obvious deficiency is the lack of the ability to chance the Kerberos-specific LDAP details for the configured Active Directory. In any case, these properties can be updated via the command line using Ambari's configs.py script. This can be found at /var/lib/ambari-server/resources/scripts/configs.py. # /var/lib/ambari-server/resources/scripts/configs.py --help Usage: configs.py [options] Options: -h, --help show this help message and exit -t PORT, --port=PORT Optional port number for Ambari server. Default is '8080'. Provide empty string to not use port. -s PROTOCOL, --protocol=PROTOCOL Optional support of SSL. Default protocol is 'http' -a ACTION, --action=ACTION Script action: <get>, <set>, <delete> -l HOST, --host=HOST Server external host name -n CLUSTER, --cluster=CLUSTER Name given to cluster. Ex: 'c1' -c CONFIG_TYPE, --config-type=CONFIG_TYPE One of the various configuration types in Ambari. Ex: core-site, hdfs-site, mapred-queue-acls, etc. To specify credentials please use "-e" OR "-u" and "-p'": -u USER, --user=USER Optional user ID to use for authentication. Default is 'admin' -p PASSWORD, --password=PASSWORD Optional password to use for authentication. Default is 'admin' -e CREDENTIALS_FILE, --credentials-file=CREDENTIALS_FILE Optional file with user credentials separated by new line. To specify property(s) please use "-f" OR "-k" and "-v'": -f FILE, --file=FILE File where entire configurations are saved to, or read from. Supported extensions (.xml, .json>) -k KEY, --key=KEY Key that has to be set or deleted. Not necessary for 'get' action. -v VALUE, --value=VALUE Optional value to be set. Not necessary for 'get' or 'delete' actions. For example, if you wanted to view the current set of properties in the kerberos-env configuration (where most of the KDC configuration values exist) in a cluster named c1 in and Ambari server running on localhost, you would issue the following command: /var/lib/ambari-server/resources/scripts/configs.py --host=localhost --port=8080 --user=admin --password=admin --cluster=c1 --action=get --config-type=kerberos-env If you wanted to update or set a property, like the LDAP URL, you would issue a command like # /var/lib/ambari-server/resources/scripts/configs.py --host=localhost --port=8080 --user=admin --password=admin --cluster=c1 --action=set --config-type=kerberos-env --key=ldap_url --value="ldaps://newhost.example.com:636" 2017-03-02 21:08:39,407 INFO ### Performing "set": 2017-03-02 21:08:39,407 INFO ### new property - "ldap_url":"ldaps://newhost.example.com:636" 2017-03-02 21:08:39,435 INFO ### on (Site:kerberos-env, Tag:version1488487426247) 2017-03-02 21:08:39,451 INFO ### PUTting json into: doSet_version1488488919451669.json 2017-03-02 21:08:39,510 INFO ### NEW Site:kerberos-env, Tag:version1488488919451669 As for setting the administrator credentials, if you created the credential store and choose to save the administrator credentials, you can go to the Kerberos Administrator page (Admin menu -> Kerberos) and click on the "Manage Credentials" button (I think that is the label on the button). Else, the temporary administrator credential will time out after about 90 minutes or if Ambari is restarted. You will then be prompted to set it when performing a Kerberos-related operation. ... View more

@Timo Burmeister A new container does not need to be created specifically for the Ambari-managed Kerberos identities; however, it would be recommended since there potentially may be a lot of accounts created for service and user principals in the Active Directory. In any case, there needs to be a container available in the Active Directory that Ambari can create and manage accounts within. The credentials used to access the Active Directory must give access to Ambari so that new accounts can be created for each of the cluster-specific service and user principals. That account must able to able to update the password for each of those accounts. It is recommended that a special account is given access to the container for security purposes and ease-of-mind. You may not want to give out a domain administrator's credentials or give Ambari full rein over the Active Directory - not that Ambari will do anything nefarious. ... View more

I believe that a combination of both @Kuldeep Kulkarni and @Vipin Rathor answers are correct. Combining them and assuming the SPNEGO principals (HTTP/<host>) for the Ranger hosts already exist in the Active Directory: Create the account in the Active Directory for the load balancer host (HTTP/<loadbalancer FQDN>@<realm>) Export the keytab file for the created account Combine the relevant keytab file into a single file using ktutil Do not attempt to export new keytab file for the previously existing SPNEGO principals as this will change the password on the account and invalidate the existing (relevant) keytab files in the cluster. You should find the needed keytab file from the appropriate hosts at /etc/security/keytabs/spnego.service.keytab. Creating the new account in the Active Directory can be done by logging into the Active Directory and using the new user wizard - right mouse click on the LDAP container (aka the "OU") and select "new" and then select "user" from the menus. You can also create a new user in the Active Directory by using LDAP commands from the OpenLDAP packages (ldapadd), but you will need to create a unicode password and an LDIF file - I believe there will be a article on HCC about this in the rather near future courtesy of @dvillarreal with a little help from me. Creating the keytab file can be done using the ktpass utility on the Active Directory host; or, since you might know the password for the account, you can use ktutil to build one on a Linux host. ... View more