@Mehul Shah You NiFi is failing to start because your Java cannot decrypt your keystore: Caused by: java.io.IOException: exception decrypting data - java.security.InvalidKeyException: Illegal key size at org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.cryptData Java supports only 128-bit encryption by default. 128bits == 16Bytes == 16 Chars. So the cryptKey used by your keystore cannot exceed 16 characters. If you want to exceed more than 16 character you have to install Java Cryptography Extension (JCE) Unlimited Strength. You will either need to obtain new keystore which uses a simpler password or install the JCE to your Java install. Thanks, Matt ... View more

@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