Hi, we have a similar issue and wondering if those steps listed are the resolution.   we have our cluster kerberised and we also deployed Sentry, as part of the setup in hive we disabled impersonation. so all the HIVE queries are being executed by the HIVE user. We configured Dynamic resource manager pools, setting up 3 queues. HighPriority, LowPriority and Default. Everybody can submit jobs to the default queue, that is working as expected. The HighPriority, LowPriority are managed by group membership to two different AD groups. I assigned a test user both groups so it could submit jobs to both queues (HighPriority, LowPriority) when i submitted a job we got the following error message ERROR : Job Submission failed with exception 'java.io.IOException(Failed to run job : User hive cannot submit applications to queue root.HighPriority)' java.io.IOException: Failed to run job : User hive cannot submit applications to queue root.HighPriority this is correct because the hive user doesn't is not a member of any of those groups. I modified the submission access control to add the hive user to the pool and this time the job completed, however that breaks the access control model we are trying to implement because now all hive users can make use of both pools even though they don't belong any of the AD groups that are supposed to be controlling who can submit jobs to the pool. Is there a way to control which users can submit to specific resource pools in HIVE and leverage the Ad groups created for this purpose? ... View more