@Ashwani  This could be a Proxy configuration issue, could be SAN issue, or something else. I'd suggest enabling developer tools in your browser and observe the network transactions when you attempt to access your NiFi. There is no correlation between you current setup and the fact that it worked when using the Single User authentication.  Single User utilizes a local username and Password to authenticate your user. When you have the single user provider configured authentication and then try to access NiFi, NiFi will "WANT" a client certificate.  If the Client does not provide a trusted clientAuth certificate in that TLS exchange, NiFi will try the next configured user authentication method.  In that setup that would be the single user provider. I am not sure the complete setup you have in place now, but if TLS is only method configured for user authentication, NiFi will "Require" a trusted clientAuth certificate is presented.  If a trusted certificate can not be provided, NiFi simply closes the connection. It is the responsibility of the Proxy to facilitate the passing of the clientAuth certificate to the NiFi.   I see from your shared images numerous IP addresses.   The screenshot from your browser shows a 3.x.x.x address, the configured proxy.host is a 18.x.x.x address, and your NiFi node is a 172.x.x.x address.  What is this 3.x.x.x address for? I suggest adding the address you use in your browser as a SAN entry as well. The shared certificates all look correct except for possibly needing that additional 3.x.x.x address as a SAN entry. Have you tried using openssl to observer the TLS exchange (serverHello) response when you try to initiate a connection to the NiFi? openssl s_client -connect <ipaddress or hostname>:<port> -showcerts I'd expect in the serverHello a listed of trusted authorities (localhost from your NiFi truststore). If you are not getting that but some other list, your Proxy is trying to negotiate a TLS exchange instead of proxying the exchange with the NiFi endpoint maybe.   Also possible your proxy is not passing the clientAuth certificate to your NiFi or the proxy is trying to establish its own TLS handshake with NiFi to which a successful mutualTLS handshake is not successful. And just for completeness, you did load your client certificate in to your browser? Hope this helps you with your journey. If you found any of the suggestion/solution provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@MukaAddA  Sorry, writing such script is not a strong area for me.  I just happened to notice you were doing a session.create instead of a session.get.  You may get better help by raising a new question on how to create a script to be executed by the ExecuteScript processor to accomplish your use case and provide details on that use case.  I am sure there are others in the community that are good at writing such scripts. Matt ... View more

@Ashwani  Are you sure your NiFi even starts up completely when you reconfigure the nifi.properties file to use the managed authorizer? If you check the nifi-app.log during startup, do you seen any exceptions? Do you see the log lines that state the UI is available at the following URLs? Looking at your authorizers.xml configuration shared, the following line is not a vlid line for the file-user-group-provider: <property name="Initial Admin Identity">CN=admin, OU=NIFI</property> It should be removed. Really not sure why you added your NiFi server's IP a SAN in a certificate you plan on loading in yoru browser for clientAuth authentication in to your NiFi? Can you share the verbose output of yoru NiFi keystore and truststore configured in the nifi.properties file? keytool -v -list -keystore <keystore or truststore filename>   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@mslnrd  This is likely caused by LDAP on 636 uses referrals that can your initial query can be referred to across the entire domain tree across multiple LDAP servers. So somewhere within that referral your issues arrises in the hostname verification. Switching to the global catalog port 3269 and there are no referrals.  I can't speak to the issues within your ldaps servers causing the issue within the referrals, but makes sense why switching to the secure global catalog port resolved your issue.   Hope this clarifies why the change in port resolved your issue. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@kothari  It is not Ranger's job to inform the client applications using Ranger what users belong to what group.  Each client application is responsible for determining which groups the user authenticated into that service belong to. The policies generated by Ranger are downloaded by the client applications.  Within that downloaded policy json will be a resource identifier(s), list if user identities authorized (read, write, and/or delete) , and list of group identities authorized (read, write, or delete) against each resource identifier.  So when client checks the downloaded policies from Ranger it is looking for the user identity being authorized and if client is aware of the group(s) that user belongs to, will also check authorization for that group identity.   so in your case, it i s most likely that your client service/application has not been configured with the same user and group association setup in your Ranger service.   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@BKZ  Can you share more about your environment setup.  Are you using Knox (from URL it appears so)?  What topology is setup in knox for NiFI and NiFI-API? What are all the methods of user authentication you have setup (nifi.properties file would help here)? You are getting a 401 unauthorized response.  Are you seeing anything logged in the nifi-user.log when you execute your python code? Have you tried going directly to the NiFi node's nifi-api endpoint instead of going through the cdp-proxy-api? What version of CDP and CFM are you using? The details may help get more responses from within the community. Thank you, Matt ... View more

@pashtet04  There is a significant jump in version from NiFi 1.11.4 to 1.23.0 As with any upgrade/migration, you should NOT be just copying core configuration files from old version to new version.  You should instead use the old configuration files to update the new configuration files as those new configuration files would have introduced new properties that would then be missing if you simply copied old to new.   NiFi 1.11.4 loaded a flow.xml.gz file on startup.  With release of NiFi 1.16, NiFi introduced a new flow storage format using flow.json.gz (which also introduced a new property in the nifi.properties file: "nifi.flow.configuration.json.file").  1.16 and later version will still load from the flow.xml.gz file if a flow.json.gz is not present and then generate the flow.json.gz file which will be used for all subsequent launches starting with 1.18+ version.   I am guessing your exception about flow configuration file [NULL] comes from missing configuration property in the nifi.properties you copied over.  This may have also resulted in a failure to convert the flow.xml.gz???  I'd recommend re-copying over your original flow.xml.gz, utilize old config files to populate new config files to avoid missing properties, start NiFi 1.23 first time using original sensitive props key and sensitive props algorithm so that the flow.json.gz gets generated.  Then use the nifi.sh commands to change the sensitive props key and sensitive key algorithm. If you don't know your original sensitive props key, you could use the Encrypt-config toolkit to change it as an alternative to the nifi.sh commands. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more