Ok good progress so far! One thing that stands out is the Owner for Certificate (DN) used by Ranger. The nifi log posted appears to show that "CN=ranger-1, OU=Nifi, O=GR, L=London, ST=Unknown, C=Unknown" doesn't have access. I'm assuming that is the actual DN of the certificate used by Ranger. However in the ranger-nifi-plugin-properties section the Owner for Certificate value appears as "CN=ranger-1, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown". Nifi is expecting to identify and authorize Ranger by that value, however it doesn't appear that is the actual Owner info. You should be able to update to the correct value using Ambari. So I suggest changing the owner.for.certificate in ranger-nifi-plugin-properties to match the actual value "CN=ranger-1, OU=Nifi, O=GR, L=London, ST=Unknown, C=Unknown" as described in Part 2, Step 3 i) on the community document. Just update that one field, save the configuration and restart NiFi. Behind the scenes the authorizers.xml configuration file for nifi should be updated with the values for Ranger Admin Identity. And that's what NiFi will use to identify when Ranger is attempting communication. ... View more

Going back to one of your early responses I think you said you saw two entries in your nifi truststore? I don't think you needed to clear those out; having two entries, that aren't duplicates shouldn't be a problem. The first entry may have been for that specific node or root CA if you used toolkit (I will need to research to check). The second would be your ranger cert. ... View more

The ranger-nifi-plugin-properties is actually used to configure the NiFi service repository in Ranger (the snapshot shown in Part 3 Step 2.) . Those settings help Ranger to be able to reach a secured NiFi in order to look up available rest endpoints that can be secured. When users initially enable the plugin in Ambari, update those values and choose to restart NiFi, Ambari will actually create the service repo populated with those values. The current challenge is when the Ranger plugin is enabled first without SSL settings. If a user goes back to add settings for SSL via Ambari unfortunately the api in Ranger doesn't support update of those fields by Ambari (which is why I suggested checking those settings directly in Ranger). I believe this is a known issue that has been logged (I'll confirm though). The ranger-nifi-policymgr-ssl contains the settings that lives on the NiFi host (in a java credential file) which NiFi uses to talk to Ranger in order to retrieve policies that were configured and store them in it's local cache. Usually any issues with NiFi attempting to communicate with Ranger appear in the nifi-app.log. Also in Ranger you'll be able to see if the particular node connected or not from the Audit/Plugin tab. I hope this makes sense. I'll review the document as well to see if I can make this a bit clearer. ... View more

I think you did it for keystores created for nifi but just wanted to check that both the keystore password and the key passwords are the same value for the key/truststores created for ranger? ... View more

Another thing I'd suggest is to confirm that both the keystore/truststore that you've created for Ranger to use are accessible. I would manually run a keytool -list command: e.g. keytool -list -v -keystore /etc/security/ranger-certs/keystore.jks using the password you used to create the files. I'd run it on both the truststore and the keystore to confirm they are configured properly. ... View more

To add I'm concerned that the settings you need for Ranger to communicate securely with NiFi are not in place. Referring to https://community.hortonworks.com/articles/60001/hdf-20-integrating-secured-nifi-with-secured-range.html if you go to section 3, please confirm that you see the entries described in step 1 & 2. If not you can enter the information directly. Unfortunately Ranger doesn't currently allow us to update that setting through Ambari after it's initially created using Ambari. ... View more

Awesome @Mark Nguyen glad that worked out! ... View more

Ok looking at that exception I also see the "InvalidLoginCredential" exception that is related to NiFi determining that the credentials you provided are invalid. I'm guessing you've confirmed your credentials but just in case please confirm that your credentials are valid against the AD you are pointing to in the login-identity-providers.xml. Also I'd recommend checking that the User Search Base and User Search Filter you are using are appropriate for your AD setup. Here is an article providing details on ldap setup just in case: https://community.hortonworks.com/articles/7341/nifi-user-authentication-with-ldap.html ... View more