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
>>> >>
>>>
>>
