You are using 3.5.5 or 3.5.6, right? I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper can you give it a try? If it doesn't work then I can take a deeper look (also we can enable some debug logging)
On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain <jain.arp...@gmail.com> wrote: > Hi > > I have Kerberos, Zookeeper and my application (using curator) running in 3 > docker containers with ZK SASL authentication enabled. The ZK can login to > Kerberos and starts successfully. > > The ZK server principal is zookeeper/z...@example.com > The client principal is : zkclient/z...@example.com > > While starting my application, I am seeing failure while obtaining TGS. > See the log at Kerberos side: > > > > *Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) > 172.30.0.6 <http://172.30.0.6>: NEEDED_PREAUTH: zkclient/z...@example.com > <z...@example.com> for krbtgt/example....@example.com > <example....@example.com>, Additional pre-authentication requiredJan 13 > 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6 > <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes {rep=18 tkt=18 > ses=18}, zkclient/z...@example.com <z...@example.com> for > krbtgt/example....@example.com <example....@example.com>Jan 13 15:22:19 kdc > krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6 > <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes {rep=18 tkt=18 > ses=18}, zkclient/z...@example.com <z...@example.com> for > zkclient/z...@example.com <z...@example.com>* > > However, if I use the zkCli.sh to login to Zookeeper, it successfully logs > in. See the log on Kerberos side. See the difference in the last line while > requesting TGS. > > > > *Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) > 172.30.0.3 <http://172.30.0.3>: NEEDED_PREAUTH: zkclient/z...@example.com > <z...@example.com> for krbtgt/example....@example.com > <example....@example.com>, Additional pre-authentication requiredJan 13 > 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.3 > <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes {rep=18 tkt=18 > ses=18}, zkclient/z...@example.com <z...@example.com> for > krbtgt/example....@example.com <example....@example.com>Jan 13 15:26:14 kdc > krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3 > <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes {rep=18 tkt=18 > ses=18}, zkclient/z...@example.com <z...@example.com> for > zookeeper/z...@example.com <z...@example.com>* > > The client section in JAAS config file is same in both the cases but the > server it is looking for is different in both the cases. > Could someone suggest why there is a difference ? > > Thanks > > > > On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő Máté < > szalay.beko.m...@gmail.com> wrote: > >> Also please note, that the 'Configuration.getConfiguration().refresh()' >> will reload only the jaas.config. >> If you also need to reload the kerberos client config, then you can add >> the "refreshKrb5Config=true" line to your jaas.conf file. This will trigger >> to reload the krb.cfg file as well if needed. >> >> I am just working on a PR where I had to use both of these: >> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a >> >> Cheers, >> Mate >> >> On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen <ddiede...@sinenomine.net> >> wrote: >> >>> >>> Hi Enrico, >>> >>> > There is a method to force JAAS to reload the system property. >>> > >>> > Something like Configuration.getConfiguration().refresh() >>> >>> Great to know! Thanks! >>> >>> > You have to call that method after changing the system property >>> >>> Cheers, -D >>> >>> >>> >>> > Il gio 9 gen 2020, 20:05 Damien Diederen <ddiede...@sinenomine.net> ha >>> > scritto: >>> > >>> >> >>> >> Hi Arpit, Máté, >>> >> >>> >> Arpit wrote: >>> >> >>> >> > The solution is to pass JAAS file >>> >> > with -Djava.security.auth.login.config=/path/to/jaas.conf. >>> >> >>> >> Okay—good. >>> >> >>> >> > Using System.setProperty does not work for me. >>> >> >>> >> Ah, I see. And I'm not surprised; I think Máté is on the right track: >>> >> >>> >> >> I also faced this exception not long ago. I think it is an edge >>> case, >>> >> most >>> >> >> probably you have something else, but still... maybe it helps: >>> >> >> >>> >> >> I tried to write a unit test which dynamically generated multiple >>> >> >> jaas.conf files. Then I was setting the >>> >> >> java.security.auth.login.config system property to the config file >>> I >>> >> needed >>> >> >> in the given testcase, and when I tried to establish a ZooKeeper >>> >> connection >>> >> >> in the unit test, I also got the same exception that you got. >>> >> >> >>> >> >> The problem was, that the security configuration file I referred >>> in the >>> >> >> java.security.auth.login.config system property file was read only >>> once, >>> >> >> then stored in memory. And it haven't got reloaded, even if the >>> file (or >>> >> >> its path in the system property) changed. >>> >> >>> >> My understanding is that the property is read very early after "VM >>> boot" >>> >> (the first time any class tries to access the java.security.Provider): >>> >> the resource it points to is parsed at that point, and the property >>> >> "never" checked again. >>> >> >>> >> (It *may* be possible to flush the "Spi" or something, but it's >>> clearly >>> >> not the kind of usage it was designed for.) >>> >> >>> >> >> Maybe the best in this case is to >>> >> >> specify separate JAAS config sections for each tests and use a >>> single >>> >> >> JAAS.conf file per JVM. >>> >> >>> >> That's probably the easiest if the set is enumerable. >>> >> >>> >> "Real dynamism" might require overriding the "Spi" or "Provider," but >>> >> that's probably overkill for a few tests. >>> >> >>> >> (Now that I think of it… our tests are already run under the JMockit >>> >> agent, so live-patching JAAS methods using mockit.MockUp might be >>> >> another option :) >>> >> >>> >> Anyway. It looks like setting the property externally worked for >>> Arpit. >>> >> >>> >> Cheers, -D >>> >> >>> >>