Hi @Adarsh_ks    Can you try adding to Client    serviceName="zookeeper"     Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true useTicketCache=false keyTab="<keytab_path>" serviceName="zookeeper" principal="<principal>"; }; Let us know the results. Thanks, Manuel.  ... View more

Hi @Peruvian81    It's difficult to suggest if there are no details about the cluster usage, but it would be useful to start reviewing the below article that provides Kafka best practices.   https://community.cloudera.com/t5/Community-Articles/Kafka-Best-Practices/ta-p/249371   I hope that helps. Regards, Manuel. ... View more

@Peruvian81    You can start testing a flow like below:   tailFile --> PublishKafka_1_0(2_0 depending on your Kafka version)    In publishKafka you can use a configuration example like below:     Ensure that the principal has Ranger authorization to publish data to the topic. In Kafka brokers, provide the brokers FQDM, do not use localhost or IPs   ... View more

@Peruvian81    According to the output, the broker is listening on SASL_PLAINTEXT (kerberos) and host w01.s03.hortonweb.com. We have to specify the connection type we are doing from our clients to Kafka, by default the connection is PLAINTEXT, depending on the Kafka version in use, you should try the following:   1. Get a valid Kerberos token "kinit -kt <keytab> <principal>" 2. Execute the command below for Kafka version until 1.0.0           ./kafka-console-producer.sh --broker-list w01.s03.hortonweb.com:6667 --topic PruebaKafka --security-protocol SASL_PLAINTEXT       Kafka 2.0 onwards:   ./kafka-console-producer.sh --broker-list w01.s03.hortonweb.com:6667 --topic PruebaKafka --producer-property security.protocol=SASL_PLAINTEXT         Test and let us know.   ... View more

@Peruvian81    Are you using kerberos? If yes, make sure you have a valid ticket in order to avoid below exception:     2019-09-25 16:22:54,367 - WARN [main-SendThread(m01.s02.hortonweb.com:2181):ZooKeeperSaslClient$ClientCallbackHandler@496] - Could not login: the client is being asked for a password, but the Zookeeper client code does not currently support obtaining a password from the user. Make sure that the client is configured to use a ticket cache (using the JAAS configuration setting 'useTicketCache=true)' and restart the client. If you still get this message after that, the TGT in the ticket cache has expired and must be manually refreshed. To do so, first determine if you are using a password or a keytab. If the former, run kinit in a Unix shell in the environment of the user who is running this Zookeeper client using the command 'kinit <princ>' (where <princ> is the name of the client's Kerberos principal). If the latter, do 'kinit -k -t <ke ytab> <princ>' (where <princ> is the name of the Kerberos principal, and <keytab> is the location of the keytab file). After manually refreshing your cache, restart this client. If you continue to see this message after manually refreshing your cache, ensure that your KDC host's cl ock is in sync with this host's clock.     From the command line, please add the broker id: get /brokers/ids/<brokerID>   Example: ZK_HOME/zookeeper-client/bin/zkCli.sh -server host:2181 get /brokers/ids/1001   If you don't know your current ids, you can get them by using:   ZK_HOME/zookeeper-client/bin/zkCli.sh -server host:2181 ls /brokers/ids ... View more