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
>>>>>>> >>
>>>>>>>
>>>>>>
