@Anishkumar Valsalam There are two parts that need to be successful to access NiFi: User authentication: In your case, you are using LDAP to authenticate your users. The NiFi login-identity-providers.xml is used to configure the ldap-provider. NiFI offers two supported configurable "Identity Strategy" options (USE_DN or USE_USERNAME). USE_DN is the default. With "USE_DN" the full DN returned by LDAP after successfully authenticating a used. With "USE_USERNAME" the username entered at login will be used. Which ever strategy is used, the value used will be passed through any configured "Identity Mapping Properties" in NiFi before the resulting mapped value is passed to part two. (Review LDAP settings and Identity mapping Properties in NiFi Admin guide for more details on setup) User Authorization: In you case, you are using Ranger for user authorization. (default is NiFi's file-based authorizer). The final value derived form step one above is passed to the configured authorizer to determine what NiFi resources that authenticated user has been granted access. Based on your output above, you appear to have two options possibly to match your authenticated value with your ldap sync'd user in Ranger: Configure an "Identity Mapping Property" in NiFi that will extract on the value from CN= from the entire returned DN. Based on the DN pattern you shared, your pattern mapping would look like this: nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), OU=(.*?), OU=(.*?), DC=(.*?), DC=(.*?), DC=(.*?)$nifi.security.identity.mapping.value.dn=$1 This will return just "anish" from the DN and that is what will be passed to the authorizer. Change your "Identity Strategy" configuration in your login-identity-providers.xml file to use "USE_USERNAME". This assumes the username supplied at login matches exactly with the LDAP sync username. Add/Modify the following line in your ldap-provider: <property name="Identity Strategy">USE_USERNAME</property> Thanks, Matt ... View more

@Anishkumar Valsalam Standalone NiFi instances have no need to perform and 2-way TLS negotiations. Once you cluster, NiFi nodes need to communicate with each other and that negotiation uses 2-way TLS. Not sure where you got your keystore and truststore files from, but you need to verify that the contents of both are correct. The truststore.jks file should contain the necessary trustedCertEntries so that it can trust the client certificate being presented from the other nodes in your cluster. Matt ... View more

@Joshua Adeleke HDF 2.1.4 (essentially HDF 2.1.3, plus the Controller service UI fix) will be out very very soon. keep an eye out for it on the https://docs.hortonworks.com/ page. You can then just do an Ambari upgrade from HDF 2.1.3 to HDF 2.1.4. Thanks, Matt ... View more

@Paula DiTallo 1. Everything you configure in NiFi (Processors, connections, input ports, output ports, Remote Process groups, funnels, Controller services, reporting tasks, etc...) is contained within the flow.xml.gz file (by default located in NiFi's conf directory). You can clear the canvas in a couple ways: Select all components the canvas and click "delete" key. (Depending on connections, some components may not delete first time.) All connections must be absent of any queued data. All Processors must be stopped. This method will not delete any controller services, reporting tasks, or imported templates (these must be removed manually). Stop NiFi and delete the flow.xml.gz file. On next restart, a new blank flow.xml.gz file will be generated. Any FlowFiles that were still queued in NiFi will be deleted during start-up. This method will remove all components including controller services, reporting tasks, and imported templates. 2. User need to use the "upload template" icon found in the "Operate Panel" found to the left of the canvas. Once the template has been uploaded, it can be instantiated on to the canvas by dragging the "Template" icon form the top menu bar in the NIFi UI to the canvas. Thanks, Matt ... View more