Winbind is out of my league, but I would think that when you log in to the linux host as user bspchaseuser, winbind should automatically kinit for you and your principal should be bspchaseuser@XYZ.ABC.NET not admin/admin@XYZDEV.ABC.NET. So it seems like something is not correct. Or maybe winbind does not handle Kerberos and you are required to kinit separately. Since the realms are different, it seems like you, at one point, kinit-ed as admin/admin@XYZDEV.ABC.NET for the local KDC and that identity is hanging around each time you log in due to the stored Kerberos credential cache. Maybe you need to clear out the cache using kdestroy and then winbind will re-establish the cache using the expected identity. Regarding the KDC, if you are using AD, you really do not need an additional KDC... however I typically recommend using an MIT KDC for the cluster's service principals. You will need to create a trust relationship between the local KDC and the AD to properly authenticate the enterprise users in the XYZ.ABC.NET realm and tell Ambari about the additional realm (XYZ.ABC.NET) so that it knows how to properly create the auth-to-local rules. It does nothing else with that information. So you will also need to edit the krb5.conf template so the realm can be found by the Kerberos infrastructure. You do not need to perform actions for your #2 and #3 items above if Winbind and Ambari are set up correctly. ... View more

Since you have the cluster set up for Kerberos, you should leave that hadoop.security.authentication property set to kerberos. By setting it to simple, it Hadoop will use the acting users local username rather than the authenticated Kerberos principal. This is less secure and can introduce issues since some services will use the local username and others will use the Kerberos identity. What are you using to integrate the AD with the Linux hosts? Maybe the configuration of this is causing the wrong Kerberos principal to be used when logging in to the hosts. After logging in, do a klist to see what Kerberos identity you have acquired. If this is not the expected principal, you should review that integration piece. So people use SSSD for this, but there are other tools out there. I am not familiar with any, as I am not a system administrator and have not had the time to do any research on them. ... View more

@Bala K I think more information is needed. LDAP users are not always directly related to Kerberos identities. However if you are using an Active Director or IPA server they will appear to be. By default, Ambari should set up a default rule to translate the user principals to local user names. If there are multiple realms, the additional realms may be declared to Ambari, for which each will have a rule created. This property can be found on the Admin/Kerberos page. If you wish to create custom rules for the users, see my article on writing auth-to-local-rules - https://community.hortonworks.com/articles/14463/auth-to-local-rules-syntax.html ... View more

There looks to be a property for Solr that can be used for this. See https://lucene.apache.org/solr/guide/6_6/kerberos-authentication-plugin.html. solr.kerberos.name.rules Used to map Kerberos principals to short names. Default value is DEFAULT. Example of a name rule: RULE:[1:$1@$0](.*EXAMPLE.COM)s/@.*// ... View more

@Julian Blin I am not familiar with Solr's configuration options. Where did you set this rule? Maybe @Olivér Szabó, can chime in on helping to configure. ... View more

Thanks. Sorry I didn't know what log to look in. Ranger and KMS is not my forte. Thanks, @vperiasamy for contributing to the effort. ... View more

@vperiasamy would you be able to help out on this KMS issue? ... View more

You have multiple realms involved. I guess I missed that point somewhere. You need to add a specific rule to translate the trusted realm, EXAMPLE.COM. So you should add the following to the rule set: RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*// You should also have (by default, from Ambari) RULE:[1:$1@$0](.*@MY.PROD.EXAMPLE.COM)s/@.*// Ambari should do this for you if you set the "Additional Realms" value to contain "EXAMPLE.COM". I am not sure if you will need to manually update the auth-to-local rules for Solr. ... View more

Can you see what happens when you do the following? Maybe we can rule out Solr. Do you know if your Solr auth-to-local rules are the same as your Hadoop auth-to-local rules? The following will test using the auth-to-local rules set in core-site.xml:hadoop.security.auth_to_local: hadoop org.apache.hadoop.security.HadoopKerberosName user@EXAMPLE.COM ... View more