zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arpit Jain <jain.arp...@gmail.com>
Subject Re: Zookeeper and curator SASL authentication
Date Mon, 13 Jan 2020 16:58:52 GMT
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é <szalay.beko.mate@gmail.com>
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 <jain.arpit6@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/zoo1@EXAMPLE.COM
>> The client principal is : zkclient/zoo1@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/zoo1@EXAMPLE.COM
>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>> <EXAMPLE.COM@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/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@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/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>> zkclient/zoo1@EXAMPLE.COM <zoo1@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/zoo1@EXAMPLE.COM
>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>> <EXAMPLE.COM@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/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@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/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM> for
>> zookeeper/zoo1@EXAMPLE.COM <zoo1@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.mate@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 <
>>> ddiederen@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 <ddiederen@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
>>>> >>
>>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message