@ARUNKUMAR RAMASAMY Assume by "secondary KDC", you either mean in a master/slave relationship or a trust relationship (where each KDC hosts its own realm) If this is a master/slave relationship, you need to edit that krb5.conf template (under the Advanced krb5-conf tab on the Kerberos service config page) to specify the additional KDC host and (optionally) the master KDC: [libdefaults] renew_lifetime = 7d forwardable = true default_realm = {{realm}} ticket_lifetime = 24h dns_lookup_realm = false dns_lookup_kdc = false #default_tgs_enctypes = {{encryption_types}} #default_tkt_enctypes = {{encryption_types}} {% if domains %} [domain_realm] {% for domain in domains.split(',') %} {{domain}} = {{realm}} {% endfor %} {% endif %} [logging] default = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log kdc = FILE:/var/log/krb5kdc.log [realms] {{realm}} = { admin_server = {{admin_server_host|default(kdc_host, True)}} kdc = fqdn.slave.kdc kdc = {{kdc_host}} master_kdc = {{kdc_host}} } {# Append additional realm declarations below #} Note the addition of the kdc and master_kdc entries in the realm definition. For the additional kdc entry, "fqdn.slave.kdc" should be change to the FQDN (and optionally port) of the slave KDC. If this is a trust relationship, then you need to add the additional realm to the krb5.conf template (under the Advanced krb5-conf tab on the Kerberos service config page). [libdefaults] renew_lifetime = 7d forwardable = true default_realm = {{realm}} ticket_lifetime = 24h dns_lookup_realm = false dns_lookup_kdc = false #default_tgs_enctypes = {{encryption_types}} #default_tkt_enctypes = {{encryption_types}} {% if domains %} [domain_realm] {% for domain in domains.split(',') %} {{domain}} = {{realm}} {% endfor %} {% endif %} [logging] default = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log kdc = FILE:/var/log/krb5kdc.log [realms] {{realm}} = { admin_server = {{admin_server_host|default(kdc_host, True)}} kdc = {{kdc_host}} } {# Append additional realm declarations below #} ADDITONAL.REALM = { admin_server = FQDN.admin.server kdc = fqdn.kdc } Note the additional realm, named "ADDITIONAL.REALM", which should be changed to the actual realm name. Also the admin_server and kdc values need to set appropriately. You will also want to add the additional realm to the "Additional Realms" value in the Kerberos admin page so that an entry will be created in the auto-generated auth-to-local rule sets. By editing the data on this page and saving it, I believe the configurations will be updated and you may have to restart some services. If not, you should click on the "Regenerate Keytabs" button and the configurations will be updated along with the new keytab files. ... View more

@Pranay Vyas, When enabling Kerberos, Ambari set to integrated with an MIT KDC, Active Directory, and soon FreeIPA. This setting allowing Ambari to interact with the specific KDC as needed. In the case of Active Directory, Ambari uses the Active Directory's LDAP interface, via the LDAPS protocol. During the enable Kerberos workflow, the user needs to supply details about this interface (LDAPS URL, container DN, and administrative credentials). Ambari can also be configured to set certain properties on the accounts it creates while enabling Kerberos. Note that the protocol MUST be LDAPS since Active Directory requires a secure connection in order for a password to be set or updated on an account in the domain. As part of this process, Ambari will internally create and distribute the keytab files that are needed. This can be done because Ambari generates and temporarily holds on to the passwords for each account it creates in the Active Directory. Once the process is complete, the passwords are lost and cannot be retrieved. However the keytab files will exist and be distributed, so the passwords are not needed. ... View more

@Rob Ketcherside, You should be able to do what you are currently doing, but you will also need to add kerberos descriptor entries for the custom service. See https://cwiki.apache.org/confluence/display/AMBARI/Automated+Kerberizaton#AutomatedKerberizaton-DescriptorSpecifications for information on creating this entry. As as quick start example, you will want to add a block under the Kerberos descriptor services section (in the blueprint) for your service... { ..., "services" : { ..., { "name" : "OneFS", "identities": [ ... ], "components": [ ... ], ... }, ... }, ... } ... View more