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