Member since 
    
	
		
		
		09-29-2015
	
	
	
	
	
	
	
	
	
	
	
	
	
	
			
      
                362
            
            
                Posts
            
        
                242
            
            
                Kudos Received
            
        
                63
            
            
                Solutions
            
        My Accepted Solutions
| Title | Views | Posted | 
|---|---|---|
| 1818 | 03-14-2019 01:00 PM | |
| 2102 | 01-23-2019 04:19 PM | |
| 8598 | 01-15-2019 01:59 PM | |
| 6280 | 01-15-2019 01:57 PM | |
| 15243 | 12-06-2018 02:01 PM | 
			
    
	
		
		
		11-21-2018
	
		
		06:09 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							@Ankita Ghate It seems like there is an issue with the principal name. According to the error  2018-11-21 04:01:14,662 - Failed to create principal, zookeeper/local4.domain.coma@DOMAIN.COM,zookeeper/ubuntu25.domain.com@DOMAIN.COM,zookeeper/ubuntu26.domain.com@DOMAIN.COM - Failed to create service principal for zookeeper/local4.domain.com@DOMAIN.COM,zookeeper/ubuntu25.domain.com@DOMAIN.COM,zookeeper/ubuntu26.domain.com@DOMAIN.COM  Ambari thinks the principal name is   zookeeper/local4.domain.coma@DOMAIN.COM,zookeeper/ubuntu25.domain.com@DOMAIN.COM,zookeeper/ubuntu26.domain.com@DOMAIN.COM  As one principal name, not 3 different principal names.  Do you know this could be?  Did you add any custom Kerberos identities to the Kerberos Descriptor or customize it at all?  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-19-2018
	
		
		02:15 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		1 Kudo
		
	
				
		
	
		
					
							 I don't think that you need to remove any of the ticket caches.  They will become orphaned and also eventually time out.  Even if the cache is valid, I do not think that any requests will be allowed at the service level since all ticket requests and validation checks go though the KDC.  So if the KDC no longer knows about a principal, tickets will not be granted or validated.   I may need to test this to be certain that what I say is totally correct, but I believe that once the account in the KDC is removed the relevant principal will no longer be valid for authentication.  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-18-2018
	
		
		03:16 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		1 Kudo
		
	
				
		
	
		
					
							@Shesh Kumar The MIT-specific 'kadmin' utility will not work with the IPA KDC.  To manage users in an IPA KDC, you will need to use the IPA-specific client - 'ipa'.  For example:  ipa user-add rlevas -principal rlevas@LOCAL.REALM --first Robert --last Levas --cn rlevas  And removing a user would be  ipa user-del rlevas  The kinit and kdestroy commands are like login and logout commands. They do not create or remove users in the KDC - MIT or IPA.   On top of this, once you use kinit to authenticate a user, a ticket cache is established for the user.  This ticket cache will live even after you delete the account in the IPA KDC and klist will still show the cached data.  However access to services using that ticket cache should fail as the KDC will not grant service tickets for that user. To remove the ticket cache, kdestroy must executed.  I hope this helps.  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-15-2018
	
		
		02:16 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 I am not exactly sure all of the tasks that the Ambari agent reset operation performs. It seems like it will do a lot more than just clean up the existing certs - if it does that at all.   However, it will not perform any of the Ambari server-side tasks. So at lest the Ambari server steps from the article need to take place manually.  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-12-2018
	
		
		12:58 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 Awesome!  I am glad that I could help out.  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-11-2018
	
		
		02:48 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 It seems like hbase-site.xml does not contain auth-to-local rules and that Hbase may take those rules from the core-site.xml file.  That said, Ambari will add the needed rules to the core-site.xml file - hadoop.security.auth_to_local - if it known about the additional realm(s). This is done by added EXAMPLE.COM to the Additional Realms field in the Kerberos administration view - as discussed in https://community.hortonworks.com/questions/227267/unable-to-authenticate-as-username-to-cluster-afte.html.    Playing with this more, I am able to generate the error you are getting if the auth-to-local rules are not set up properly in core-site.xml. You can test your's my running the following command (not via ycsb):  hadoop kerbname <principal name>   Or by running   hadoop org.apache.hadoop.security.HadoopKerberosName <principal name> 	  For example:  [root@c7401 ~]# hadoop org.apache.hadoop.security.HadoopKerberosName user@UNKNOWN.DOM
18/11/11 14:36:19 INFO util.KerberosName: No auth_to_local rules applied to user@UNKNOWN.DOM
Name: user@UNKNOWN.DOM to user@UNKNOWN.DOM  Since I do not have the full stack track or all of the information, I cannot comment on whether the ycsb tool or Hbase is generating that error.  If it is Hbase, itself, then the hadoop kerbname command (on the relevant host) should show the same error when passing "user@EXAMPLE.COM" to it - assuming Hbase really does use core-site.xml to load the auth-to-local rules. However, if that command does not show the "no auth_to_local_ rules" message, then I would have to assume the error is coming from the ycsb tool and the appropriate core-site.xml file is needed. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-09-2018
	
		
		04:36 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							@Narendra Neerukonda I am not familiar with the ycsb tool.  This error coming from that tool.  Does the ycsb tool have the relevant auth-to-local rules configured? 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-07-2018
	
		
		08:16 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 @Narendra Neerukonda Awesome... I am glad that I could help.  Be sure to accept my answer to close out this issue.  
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		11-07-2018
	
		
		02:53 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		1 Kudo
		
	
				
		
	
		
					
							 @Narendra Neerukonda
  There is a place in the Ambari UI to set "additional realms".  This is a comma-delimited list of realm names that Ambari will use to generate special auth-to-local rules.  For each realm, Ambari will add the following rule  RULE:[1:$1@$0](.*@REALM)s/@.*//  For your example, you will add "EXAMPLE.COM" to the additional realms field.  Ambari will then add the following rule to all auth-to-local rule properties it knows about:  RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//  Then principal names like user@EXAMPLE.COM will be translated into "username" when services are perform auto-to-local rule translations.  The "Additional Realms" field is found in the administrative Kerberos view... not to be confused with the Kerberos service view.   Make sure that you have also edited the krb5.conf template that Ambari uses to generate the krb5.conf files so that the realm is known to the Kerberos infrastructure.  I assume that you already did this since you are able to kinit as a user from EXAMPLE.COM. Also, make sure that you established a trust relationship between the MIT KDC and the Active Directory.  Else, even though you are able to kinit, services will not trust Kerberos tokens for that user and fail authentication. Looking at the error you are seeing, I assume you did this as well since the user appears to have been authenticated. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		10-25-2018
	
		
		01:21 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		1 Kudo
		
	
				
		
	
		
					
							 @badr bakkou  the ktutil utility is used to create keytab files only.  It cannot create new principals in the KDC.  If you want to add new principals to the KDC, you need to use kadmin or kdamin.local.  Both of which can be used to create keytab files as well.   
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		 
         
					
				













