@Eric Lloyd Input and Output ports are designed to send or receive data from one level up. When an input or output port is added at the root canvas level the one level up is another out of the system. You will also notice that ports added to the root canvas are rendered a little differently. There is an open Apache Jira on this subject, feel free to add your comments and use case to it: https://issues.apache.org/jira/browse/NIFI-2933 The current feeling is that adding Remote input and output ports should be left to the system administrator. This is because in a secured connection the admin must add the connecting systems as new users and authorize them to access these ports. Users are not typically granted this level of access. Thanks, Matt ... View more

@Daniel Frank What format is your data in? (text?) Is all the information you need in the content of these files? The getFile processor already writes attributes for the following on every FlowFile it creates: You could use the ExtractText processor to read the FlowFile content and extract bits to FlowFile Attributes. Thanks, Matt ... View more

@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