@spolavarapu Thank you. This works as I wanted. Previously I missed the point that when "group search first"=YES and "enable user serch"=YES, the usersync service does a kind of join between the list of users extracted from group definitions and the users from user search query. In my case i must implement a small optimization. The AD, I will bind to eventually, is a large directory of users. I don't want the user search to get the whole directory so I created an additional group. It'll be used expose it's members to Hadoop. Of course I added the group to the user search filter. To make a user available in Ranger, I will add it to this group and other, more specific groups (which will act as roles). Regards, Pit ... View more

I managed to isolate the issue a bit. Looks that it's not related to oozie jobs but can be observed in java code connecting to hiveserver2 over JDBC. I wrapped a query in some java code and run in my test environment. In the code I make a jdbc connection to hiveserver2. Before the connection is established, I make kerberos authentication. I wrote two separate apps, one uses the Java GSS API, the other one authenticates using UserGroupInformation.loginUserFromKeytab. When the hiveserver2 is in the binary transport mode, both apps perform well. When the hiveserver2 is in the HTTP transport mode, the job which uses Java GSS API calls my KDC before each fetch operation. I run the app with JGSS debugging. Before each fetch the following log is printed: Search Subject for Kerberos V5 INIT cred (<<DEF>>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for piterr@MYIPADOMAIN.BEETLE.INT to go to krbtgt/MYIPADOMAIN.BEETLE.INT@MYIPADOMAIN.BEETLE.INT expiring on Fri Jun 17 09:02:29 CEST 2016 Entered Krb5Context.initSecContext with state=STATE_NEW Service ticket not found in the subject >>> Credentials acquireServiceCreds: same realm Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 18 17 16 23. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType getKDCFromDNS using UDP >>> KrbKdcReq send: kdc=fipasrv.beetle.int. UDP:88, timeout=30000, number of retries =3, #bytes=726 >>> KDCCommunication: kdc=fipasrv.beetle.int. UDP:88, timeout=30000,Attempt =1, #bytes=726 >>> KrbKdcReq send: #bytes read=706 >>> KdcAccessibility: remove fipasrv.beetle.int.:88 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Krb5Context setting mySeqNumber to: 879752450 Krb5Context setting peerSeqNumber to: 0 Created InitSecContextToken: 0000: 01 00 6E 82 02 69 30 82 02 65 A0 03 02 01 05 A1 ..n..i0..e...... 0010: 03 02 01 0E A2 07 03 05 00 00 00 00 00 A3 82 01 ................ 0020: 72 61 82 01 6E 30 82 01 6A A0 03 02 01 05 A1 18 ra..n0..j....... 0030: 1B 16 4D 59 49 50 41 44 4F 4D 41 49 4E 2E 42 45 ..MYIPADOMAIN.BE 0040: 45 54 4C 45 2E 49 4E 54 A2 26 30 24 A0 03 02 01 ETLE.INT.&0$.... .... When I switch back to the binary transport mode, everything works smoothly. ... View more

Thanks for the answers. @Sunile Manjee - we have a dedicated KDC which responds quite quickly, no network issues so far. @Terry Stebbens - we've already bumped the fetch size and that helped a lot. I am wondering if that's ok that each fetch is authenticated. ... View more