@casaui  You have multiple issues with your setup. Issue 1: Problem:  Missing ClientAuth certificate in MutualTLS exchange between NiFi's NiFiRegistryFlowRegistryClient and your NiFi-Registry. [NiFi Registry Web Server-50] o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in request. Solution: The NiFiRegistryFlowRegistryClient will use the keystore and truststore defined in the nifi.properties file if a SSL Context service has not been configured in the registry client directly.  For a mutualTLS exchange to be successful, the client side must present a clientAuth certificate that is trusted by the truststore being used on the server side (NiFi-Registry) of the TLS connection.  Likewise, the serverAuth certificate presented by the server (NiFi-Registry) must be trusted by the truststore the client (NiFiFlowRegistryClient) is configured to use.   I have no idea why you have an ALB setup for NiFi-registry since there is just one NiFi-Registry.  The NiFiRegistryFlowRegistryClient should be configured with the direct NiFi-Registry URL: https://nifi_ec2server.com:18443/nifi-registry Without a clientAuth certificate presented in the mutualTLS exchange your Registry client is going to be anonymous. Issue 2: Authorization Problem:  Every action is authenticated and authorized when it comes to interacting with a secured NiFi or NiFi-Registry. When the Registry Client attempts to establish a connection to the NiFi-registry, it uses the DN from clientAuth certificate from the configured keystore (provided server can trust it) as the client/user identity.   From your shared authorizers.xml I can see you are using the managed authorizer --> file-access-policy-provider --> ldap-user-group-provider.   So unless your ldap is returning the DN for your clientAuth certificate, you won't be able to setup the necessary authorization needed for the client. Solution: The authorizers.xml could be setup instead to use managed-authorizer --> file-access-policy-provider (modified to use composite-configurable-user-group-provider instead of ldap-user-group-provider) --> composite-configurable-user-group-provider (configured to use configurable provider = file-user-group-provider and provider ldap-user-group-provider).    Both the file-user-group-provider and ldap-user-group-provider configured in the composite-configurable-user-group-provider need to also be configured.  The file-user-group-provider will allow you manually added client/user identities not provided via your ldap-user-group-provider to which you can set authorization policies needed.  The clientAuth certificate DN (may be unique for each NiFi node in a NiFi cluster) would need to be authorized for "Can proxy user requests (read, write, delete)" and "Can Manage Buckets (read)". Issue 3: Authorizers - ldap-user-group-provider use of {0}. Problem:  I suspect you are not getting any users returned by this provider because your user search filter is using "sAMAccountName={0}" and group search filter is using "member={0}".  "{0}" is going to treated as a literal string.  It only has special meaning in the ldap-provider.   Solution:  Stop using {0} in the authorizers.xml file ldap-user-group-provider.  This provider executes every 30 minutes to sync users and groups from ldap.  It doe snot take any outside input.  The ldap-provider does however.  The username entered at login is inserted in place of the {0} in the ldap-provider to be used to verify the username and password provided at login. Issue 4: Authorizers and login-provider - Auth strategy mismatch Problem:  You configured auth strategy as Simple; however, configured a ldaps url: <property name="Authentication Strategy">SIMPLE</property> ... <property name="Url">ldaps://ldapserver.com:636</property> Solution: This provider is not going to work configured like this.  Auth strategy should be "LDAPS" when connecting to "ldaps://..." or your Url should be unsecured "ldap://..." if you still want to use "SIMPLE" ------ Your user identity as displayed (case sensitive) in the upper right corner of the NiFi UI, must also exist as a user in NiFi-Registry and be properly authorized on the bucket(s) that user can use for version control.  Keep in mind that the NiFiRegistryFlowRegistryClient will proxy read/write request on behalf of your NiFi user.  So the authorizations I stated early for the registry client and the authorizations for the NiFi user must both exist in NiFi-Registry. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more