zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szalay-Bekő Máté <szalay.beko.m...@gmail.com>
Subject Re: Zookeeper and curator SASL authentication
Date Tue, 14 Jan 2020 11:52:36 GMT
The system property name is a bit misleading... this parameter is actually
specifies the username used in the ZooKeeper server principal.  (in your
case the server principal is: zookeeper/zoo1@EXAMPLE.COM)
AFAIK the ZooKeeper client (after authenticated as zkclient/zoo1@EXAMPLE.COM
in Kerberos based on the jaas.conf file) needs to know the ZooKeeper server
principal in order to ask for a specific token from kerberos which can be
read by the ZooKeeper server.

In 3.5.5 (or 3.5.6) you can use the  zookeeper.sasl.client.username
parameter (plus some other parameters) to configure how the server
principal will be determined by the client.
See:
https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48

In future releases (3.5.7, 3.6, ...) you can also use
the zookeeper.server.principal parameter (a much better name I think) to
use a fix server principal name in the client.
See:
https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50

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

> 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