@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

@Sunile Manjee UUIDs are created when a template is add to the canvas. This allows users to instantiate the same template multiple times within a single NiFi. It also insures not conflict of UUID with other existing components already instantiated. There is no way for users to set the UUIDs of any component manually. The only way to maintain UUIDs between NiFi instances is to move the entire flow.xml.gz file from one NIFi to the next rather then using templates. Thanks, Matt ... View more

@Sunile Manjee Even if you were to use NiFi's file based authorizer instead of Ranger the same limitation exists with maintaining authorizations when moving templates from one NiFi environment to another. Templates were never intended or designed to be the answer to the SDLC. Although they represent the closest thing to it for now. Templates are nothing more the a snippet of a NiFi components that can be reused within the same NiFi or downloaded and shared with user of other NiFi instances. They cannot be hardcoded to use specific component uuids nor would be want to because that what hinder there reusability within the same NiFi instance. We also can't include any authorizations with a template since there is no way of knowing that other NiFi instances in which the template is loaded will contain the same set of users. Nor can we set authorizations based on PG names. What if another PG is created with that same name in another process group? What is a user happens to use a PG name that has policies associated to it? The results could present a security issue. There is on going work towards a better SDLC model with NIFi. That being said, the default behavior when adding a template to a graph is that all components inherit the policies from the parent process group. So if at the root level you create several process groups with a specific set of authorizations for each, instantiating your templates in a given process group will establish a controlled set of authorizations. Not the ideal solution, but helps some until future work is done to make SDLC better. Thanks, Matt ... View more