Thanks you so much ! It worked finally. I had to change -Dzookeeper.sasl.client.username=zookeeper parameter.
On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <[email protected]> wrote: > 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 <[email protected]> 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/[email protected] >> The client principal is : zkclient/[email protected] >> >> 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/[email protected] >> <[email protected]> for krbtgt/[email protected] >> <[email protected]>, 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/[email protected] <[email protected]> for >> krbtgt/[email protected] <[email protected]>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/[email protected] <[email protected]> for >> zkclient/[email protected] <[email protected]>* >> >> 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/[email protected] >> <[email protected]> for krbtgt/[email protected] >> <[email protected]>, 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/[email protected] <[email protected]> for >> krbtgt/[email protected] <[email protected]>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/[email protected] <[email protected]> for >> zookeeper/[email protected] <[email protected]>* >> >> 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é < >> [email protected]> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 >>>> >> >>>> >>>
