@mbraunerde  I guarantee your NiFi is not authenticating via your AzureAD as long as your NiFi is still configured as your configuration is shared above. These two nifi.properties properties are configured to which login provider and authorization provider are actively being used: Authentication: nifi.security.user.login.identity.provider=single-user-provider Authorization: nifi.security.user.authorizer=single-user-authorizer While your authorizers.xml has additional providers: file-user-group-provider aad-user-group-provider composite-configurable-user-group-provider file-access-policy-provider and an additional authorizer that utilizes the above providers: managed-authorizer These are not being used by the NiFi application core because the nifi.properties is still pointing at the "single-user-authorizer" rather then the "managed-authorizer" Also the "Single-user-provider" can only be used with the "Single-user-authorizer", so you'll need to configure a different login identity provider like the "ldap-provider". 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

@svenhans  I would recommend you file an Apache NiFi Jira ticket for your new component processor request. https://issues.apache.org/jira/projects/NIFI Let's say an AD/LDAP lookup processor was create. that means supplying the ldap search configuration properties along with manager DN and manager password in order to do the lookup.  To avoid exposing that to other users in NiFi, maybe creating an LDAPLookup Controller service would be better.  Then create a processor like getLDAPUser that gets configured to use that LDAPLookup CS along with a StandardSSL CS with user defined AD/LDAP attributes to return and require a user Identity property value.    Of course you run the risk of other who have access to your NiFi copying your processor and using it to fetch any details they want about your AD/LDAP users.   Matt ... View more

@Gutao  When interacting with the NiFi rest-api, I'd recommend creating a client certificate to use in your automation.  A secured NiFi will always WANT a client certificate and will only try another configured auth method if a client certificate is not provide in the TLS exchange.  Using a certificate for your rest-api automation removes the need for obtaining a token completely.  You simply pass your client certificate with every rest-api call.   Another advantage here over auth is token expiration. With no token involved with certificate based auth, your certificate will continuously work until it expires (typical default is 1 or 2 years).  You'll need to setup authorization policies for your certificate user (Certificate DN used as user identity) for the various endpoints you are trying to interact with through the rest-api. 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

@mbraunerde Based on what you shared , you are not configured to interact/use your AzureAD at all. Your nifi.properties is configured to use the out-of-the-box "single-user-provider":   nifi.security.user.login.identity.provider=single-user-provider   This login provider generates a single local user with the specific username and password configured in the provider's configuration within the login-identity-providers.xml The only authorizer that supports the single-user-provider is the single-user-authorizer which simply gives your single configured user complete access to everything in your NiFi.  The other authorizer in your authorizers.xml is not being used at all.  These single user authentication and authorization providers also are not support in a NiFi cluster setup.  Their intent when created was simply to make it real easy for user just starting to experiment with NiFi to have a secured setup, so that their NiFi UI was not exposed to the world over http. The first thing i'd recommend is setting up your NiFi in a more production ready configuration using certificate you generate or generate through a certificate authority.  Then switch to a different authentication and authorization providers.  For example the ldap- provider for login which can be configured to authenticate users via LDAP/AD.   Then pair that with a managed authorizer.  This production ready authentication and authorization setup will then give you the ability to support authentication for multiple users and give you ability to set user specific authorizations that control what each user is allowed to access and interact with.  As far as interfacing with your NiFi via the NiFi-API, the recommend method would be to create a clientAuth certificate for the interaction.  A secured NiFi (HTTPS) will support authentication via a mutualTLS handshake (only if not using single user) always.  Meaning it will WANT a client certificate when interacting with the URL or via the rest-api.  If the a client certificate is not presented, NiFi will attempt next configured authentication method.  While you can use other authentication methods to interact with the rest-api (like ldap-provider), it is more difficult to manage since you would first need to interact with the login rest-api endpoint to get a client token and store that token so it can be passed in every additional rest-api call you make.  That token does expire which means you would need to fetch a new token periodically.  With a clientTLS certificate through a mutualTLS based authentication, you simply include that client certificate in every rest-api call (no need to get a token). Client certificate can have a configurable expiration (typically 1 or 2 years by default). 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

@SowmyaP  There seems to be a lot of missing details needed from your use case description. The GenerateFlowFile processor is used to create a FlowFile (it can be configured to produce a FlowFile with specific content and specific custom FlowFile Attributes as well). So from your use case description, you are adding custom text to your GenerateFlowFile processor and want to validate that the custom added text is correct later in your dataflow?  Biot confused on the validation since you are defining the format in the GenerateFlowFile.  Where do you expect that text to get changed in your dataflow(s) thus requiring your to validate it? I am not clear on yoru end-to-end use case. Processors like the following can be used to validate FlowFiles: 1) RouteOnAttribute - could be used to evaluate a NiFi Expression Language (NEL) against the value of an attribute on a FlowFile and the route to a dynamic relationship.  That dynamic failure relationship or unmatched relationship depending on your choice of implementation could be passed to an updateAttribute processor where you generate the log exception text.  Then route to a logAttribute processor that could be configured to produce an ERROR log output line to the nifi-app.log reporting your exception. 2. RouteOnContent - Similar strategy as RouteOnAttribute except here you create dynamic properties that use java regular expressions that are evaluated against the FlowFIle's content instead of a FlowFile's attribute to route FlowFiles to a dynamic relationship. rest of dataflow design is same as above.   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

@MarcusBrandao  As @cotopaul mentioned, providing the full error and any stack trace that may follow might help in your query.  You may also want to to look for any other WARN or ERROR log output generated around the time of attempting the version control your process group.  I'd  look for anything related to Out of Memory (OOM) or too many open files.  Also look at the JVM your NiFi is using. How often and how long are your garbage collection events? 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

@SandyClouds If you don't care about the specific formatting of the FlowFiles content, you could use the ReplaceText processor to append test to the end of the existing content.  I am assuming that you are manually investigating the failure later and will simply remove the appended putdatabaserecord.error text during the evaluation. 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