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 17:03:16 GMT
Does this user name have to be "Zookeeper"
(-Dzookeeper.sasl.client.username=zookeeper) always ?
And the client principal name is different than this username..Correct me
if I am wrong ?

On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain <jain.arpit6@gmail.com> wrote:

> 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