@Oliver Fletcher Lets assume you have Node A, Node B, and Node C in your NiFi cluster. Now your AD user is logged into Node A and runs a provenance query. That provenance query is propagated to all other nodes (A, B, and C) by Node A. Each node runs the query which may return 0 to many results (Actually looking in the nifi-app.log of each node will show a log line that indicates the number of returned results) All those results are returned to the node A where your user is logged in for display in the provenance UI. Node A upon receiving these events will check to see which results Node A is allowed to access to. In you case your user has access to the data but your nodes do not. The nodes must be granted the access to the data of the component(s) the provenance results belong to. Generally speaking you set data access policies at the process group level and all components and process groups contained within the process group inherit those parent access policies. For you, you will need the UUID of your root process group. Then in ranger you would add a new policy that grants all your nodes access to "/data/process-group/<uuid of root process group>" resource. After doing so, try running your query again and you should see results. You should already have an existing policy in Ranger which grants all your nodes the /proxy resource. Thanks, Matt ... View more

@Christophe Vico In order for users or servers to access any secured NiFi end-point a series of steps occur: 1. User/server authentication: For users this sounds like it is being done via AD which you have configured via Ambari (this sets up the login-identity-providers.xml file in NiFi). For servers this is done via server certificates that are configured for each of your NiFi nodes. If and only if user/server authentication is successful, then the process moves on to step two. Do a verbose listing of the keystore on your newly added node to verify DN structure. 2. User/server Pattern mapping: NiFi can be configured to use pattern mappings to extract a portion of the return DN or principal before passing the resulting mapped value to the configured authorizer (in your case the authorizer is Ranger). These mappings can be setup in Ambari which will update the nifi.properties file. by default, pattern mapping is not enabled. All Authenticated entities no matter how the authentication was completed are passed through every configured mapping looking for a match. If no matches are found, the full return is sent to the authorizer. Check to see if any mappings have been setup that are matching on your new server's DN. 3. User/Server Authorization: User/server authorization is check to see what NiFi resources a particular authenticated entity has been granted access to. Note: You can follow the authentication and authorization process by looking in the nifi-user.log. Thanks, Matt ... View more

@Harshith Venkatesh When performing Site-to-Site (S2S) between two Secured NiFi installs, server authentication and authorization will need to be successful. In your case it sounds like authentication was likely successful (You can confirm this by looking in the nifi-user.log of the target NiFi). What appears to be missing is source server(s) authorization. To resolve the "forbidden" you are seeing on your RPG, you will need to go to the target NiFi and add a new user for the source NiFi server(s) running the RPG. Click on "Users" to add new The user you are adding will need to be the full DN from the source NiFI's server certificate. (Case sensitive and white spaces count as valid characters). You can pull he DN out of the nifi-user.log or by doing a verbose listing source NiFi's keystore. After you have added the server as a user, you will need to authorize that server by clicking on "Policies" and granting the server "retrieve site-to-site details" access policy. After doing the above the "forbidden" response on the RPG should go away on next sync. What you still will not see is a list of available input and output ports on the target NiFi to which your source NiFi can connect with over S2S. Remote input and output ports can only be added to the root canvas level. After they have been added you will need to allow your source NiFi server user to access them as well before they will show up in the RPG. This is done via the "Operate panel": Selecting an input or output port on the canvas will show that component as the selected component in the operate panel. Select the key icon and grant your NiFi source Server the following policy: For input ports --> "receive data via site-to-site" access policy For output ports --> "send data via site-to-site" access policy On next sync RPG should now show these ports as available to your source Nifi for connecting to over S2S. Thanks, Matt ... View more