Thanks for filing the JIRA and checking KAFKA-3866. I'll try to add tests to the PR so that we can merge it.
Ismael On Thu, Mar 9, 2017 at 10:44 AM, Paweł Tomasik <p.toma...@o2.pl> wrote: > Ismael > > Thank you for the response > I've walked through changes for KAFKA-3866. > I think it shall fix the case I mentioned. > > As for server side, I've added a jira wish issue: > https://issues.apache.org/jira/browse/KAFKA-4874 > I'm working on project with high security restrictions, so I need to > find an application layer solution for now. > > Thanks > Pawel > > On 9 March 2017 at 09:53, Ismael Juma <ism...@juma.me.uk> wrote: > > Hi Pawel, > > > > It is by design that authentication is only performed during connection > > establishment in the broker. Kafka relies on long-lived connections, > which > > means that another mechanism is needed to handle users who have been > > removed from the system. A typical approach is to remove all ACLs for > that > > user, so that all actions are disallowed for connections that are still > > live. Authentication will fail for any new connection. Some people would > > prefer to have a way to deal with this scenario via authentication alone, > > so it may be worth filing a JIRA. > > > > Regarding the client-side questions, the ticket refreshes are for the > case > > where a client needs to re-establish a connection. There are a few > > improvements in the following JIRA: > > > > https://issues.apache.org/jira/browse/KAFKA-3866 > > > > Maybe you can check if it solves the issue you identified? If not, feel > > free to add a comment to that JIRA. > > > > Thanks, > > Ismael > > > > On Thu, Mar 9, 2017 at 7:27 AM, Paweł Tomasik <p.toma...@o2.pl> wrote: > > > >> Hi > >> I've found a security issue in the kafka SASL implementation. > >> It seems that ticket refreshments are not necessary to keep > >> client-broker connection up. > >> > >> Test scenario: > >> Client sucessfully connects to the broker using SASL_SSL security > >> protocol. Kerberos server is provided by Windows Server 2012 and > >> Active Directory > >> Client principal account is disabled on Active Directory > >> When Ticket expires the connection is still up and running. (Although > >> client side is no able to refresh it since account is blocked) > >> > >> The problem root-cause on client side is located here: > >> > >> org.apache.kafka.common.security.kerberos::KerberosLogin.java Lines > >> 239-263 > >> In my test scenario: > >> - Relogin fails > >> - Thread sleeps for hardocded 10 second delay > >> - Next relogin attempt is taken but immediately skipped because > >> hasSufficientTimeElapsed returns false (default value of > >> minTimeBeforeRelogin is set to 60 seconds) > >> - Next attempt is scheduled for next minute, but connection is not > closed. > >> Process repeats > >> > >> Application logs: > >> 2017-03-06 12:06:30,709 INFO > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) Initiating re-login for > >> host/domain.com > >> 2017-03-06 12:06:40,713 WARN > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) Not attempting to re-login since the > >> last re-login was attempted less than 60 seconds before. > >> 2017-03-06 12:06:40,714 WARN > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) No TGT found: will try again at Mon > >> Mar 06 12:07:40 CET 2017 > >> 2017-03-06 12:06:40,714 INFO > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) TGT refresh sleeping until: Mon Mar 06 > >> 12:07:40 CET 2017 > >> > >> 2017-03-06 12:07:40,714 INFO > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) Initiating logout for host/domain.com > >> 2017-03-06 12:07:40,715 INFO > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) Initiating re-login for > >> host/domain.com > >> 2017-03-06 12:07:50,717 WARN > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) Not attempting to re-login since the > >> last re-login was attempted less than 60 seconds before. > >> 2017-03-06 12:07:50,717 WARN > >> [org.apache.kafka.common.security.kerberos.KerberosLogin] > >> (kafka-kerberos-refresh-thread) No TGT found: will try again at Mon > >> Mar 06 12:08:50 CET 2017 > >> > >> On the broker side the problem seems to be even more severe, as the it > >> seems not to verify ticket expiration date. > >> So once client provides a valid ticket, it is no longer challenged > >> against its refreshments. > >> It looks that authentication is performed only once at connection > >> establish point by default Krb5LoginModule implementation. It is not > >> challenged later. > >> > >> I'm new here, so forgive me if it is not a good place for such posts. > >> > >> > >> Best regards > >> Pawel > >> > > > > -- > Paweł Tomasik >
