I am not sure what is wrong with the code... I am not familiar with
Curator. I can try to google / reproduce this and see what is wrong, but it
will take a while for me. So first I would ask the others, maybe there is
someone who knows both ZooKeeper SASL and Curator and can help you more in
this mailing list. If noone replies, then I will try to setup a dummy
project with Curator to test this.
Did you also ask around the Curator mailing list maybe? Would it help if I
send you code about setting the ACLs using plain ZooKeeper (and no Curator)?
On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <jain.arp...@gmail.com> wrote:
> Thanks for the clarification.
> I am able to authenticate client with Zookeeper. However, when I started
> to set ACLs with the same client, I get error messages. This is how I am
> creating curator client for setting ACLs
>
> CuratorFrameworkFactory.Builder builder =
>
> CuratorFrameworkFactory.builder().connectString(
> coordinatorHosts).retryPolicy(retryPolicy)
>
> .connectionTimeoutMs(coordinatorConnectionTimeout
> ).sessionTimeoutMs(coordinatorSessionTimeout);
>
> final CuratorFramework curatorFramework =
>
> builder.authorization("sasl", "zkclient/z...@example.com"
> .getBytes()).aclProvider(new ACLProvider() {
>
> @Override
>
> public List<ACL> getDefaultAcl() {
>
> return ZooDefs.Ids.CREATOR_ALL_ACL;
>
> }
>
>
> @Override
>
> public List<ACL> getAclForPath(String path) {
>
> return ZooDefs.Ids.CREATOR_ALL_ACL;
>
> }
>
> }).build();
>
>
> I see below logs in Zookeeper node:
>
>
>
>
>
> *2020-01-14 13:27:53,174 [myid:1] - INFO
> [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
> authenticated client: authenticationID=zkclient/z...@example.com
> <z...@example.com>; authorizationID=zkclient/z...@example.com
> <z...@example.com>.2020-01-14 13:27:53,175 [myid:1] - INFO
> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting authorizedID:
> zkclient/z...@example.com <z...@example.com>2020-01-14 13:27:53,175
> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding SASL
> authorization for authorizationID: zkclient/z...@example.com
> <z...@example.com>2020-01-14 13:27:53,182 [myid:1] - INFO
> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
> /172.30.0.6:36658 <http://172.30.0.6:36658>2020-01-14 13:27:53,183 [myid:1]
> - WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication failed
> for scheme: sasl*
>
> Is this not the correct way to do it ?
>
>
>
> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> wrote:
>
>> 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/z...@example.com)
>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>> z...@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.arp...@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.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
>>>>>>>> >>
>>>>>>>>
>>>>>>>
