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.arp...@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.m...@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.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
>>>>> >>
>>>>>
>>>>
