@chhaya_vishwaka    Please stop your NiFi nodes and delete the local NiFi "state" directory on each of them.  Then restart your NiFi nodes to see if this helps.  Removing the local state will clear out the retained node information which may still contain info about your nodes before they were secured. Thanks, Matt ... View more

@chhaya_vishwaka    You can see from the nifi-user.log that the DN passed to NiFi was: CN=nifi-host1, OU=nifi, O=nifi, L=SG, ST=SG, C=SG Where did cert with above DN come from? Is a cert with this DN loaded on your browser? The NiFi user log goes on to tell you that the above authenticated string was not authorized for "view the user interface": [CN=nifi-host1, OU=nifi, O=nifi, L=SG, ST=SG, C=SG], groups[] does not have permission to access the requested resource. Unable to view the user interface. Returning Forbidden response.   This certificate does not have "Admin" anywhere in its DN.  Did you maybe load your NiFi node certificates in to your browser also?  When your browser prompted you to select a certificate to use, did you maybe select the wrong one? I also see from above that the entire DN is being passed for authorization which tells me you do not have an identity mapping pattern setup in your nifi.properties file to trim a portion of the DN (CN value most commonly) from the full DN.    If you used "Admin" as your initial admin identity, then the resulting string after authentication and post any configured identity mapping is applied must match exactly to "Admin". https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#identity-mapping-properties   As an example, the following identity mapping pattern properties would result in the above DN being trimmed so that only "nifi-host1" would be passed to the authorizer. nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=nifi, O=nifi, L=SG, ST=SG, C=SG$ nifi.security.identity.mapping.value.dn=$1 nifi.security.identity.mapping.transform.dn=NONE Note:  The transform property is used to normalize the resulting mapped value to all UPPER or all LOWER case if needed.  NONE results in no transform. Also keep in mind that mapping patterns will also be applied to your server certificates DNs.  So if your server certificate DN matches the pattern regex also, only the server certs CN value will be passed to authorizer. So if you use identity patterns, you are likely going to need to update your "Initial User Identity <num>" and "Node Identity <num>" in your authorizers.xml file to use the CN value instead of the full DN for each of your nodes.   Hope this helps, Matt     ... View more

@nishank_paras    Let's assume your input FlowFile content looks like this: Date, IP, Description 01-30-2020, 10.0.0.1, server1 01-30-2020, 10.0.1.2, server2 01-30-2020, 10.0.3.4, server3 01-30-2020, 10.0.4.6, server4 01-30-2020, 10.0.10.2, server5   You would configure your ReplaceText processor as follows: The Search Value contains a java regular expression which will match on your entire line and uses one capture group.   The Replacement Value says to replace everything matched by the Search Value Regex with only the value from capture group 1.  We then configure ReplaceText to evaluate that Regex against each line. The resulting FlowFile output to the success relationship will have content that looks like this: IP 10.0.0.1 10.0.1.2 10.0.3.4 10.0.4.6 10.0.10.2 Hope this helps, Matt ... View more

@chhaya_vishwaka    "Insufficient Permissions" indicates the issue is with user/client authorization and not authentication anymore. Note: you may or may not see the "log out" option. You should tail the nifi-user.log and then try accessing the NiFi UI to get the full log output for the user action that was attempted. For example: 2020-02-07 15:32:51,925 INFO [NiFi Web Server-26362] o.a.n.w.a.c.AccessDeniedExceptionMapper identity[nifiuser1], groups[nifiDFMeast, users] does not have permission to access the requested resource. Unable to view the user interface. Returning Forbidden response. 2020-02-07 15:32:51,927 DEBUG [NiFi Web Server-26362] o.a.n.w.a.c.AccessDeniedExceptionMapper org.apache.nifi.authorization.AccessDeniedException: Unable to view the user interface.   If you are not ever seeing the canvas, your authenticated user does not have the "view the user interface" (/flow policy) granted to your authenticated user identity string.  As you can see from above nifi-user.log output, we can confirm this. What we also learn from this log output is that the user who successfully authenticated is being identified with user string "nifiuser1" and is a member of two groups "nifiDFMeast" and "users". NiFi authorization is handled by which ever authorizer you have configured in your NiFi authorixzers.xml and referenced my the following property in your nifi.properties file: nifi.security.user.authorizer=managed-authorizer   By default a secured NiFi will use a file based authorizer which relies on a "users.xml" (associates locally created known users to locally created known groups) and an "authorizations.xml" (associates the UUIDs assigned to the users and groups to various authorization policies. So using example above, my users.xml file would need to contain user "nifiuser1" and groups "nifiDFMeast" and "users" (all case sensitive).  Each of those strings would be assigned a UUID.  In order for my user to see the NiFi canvas, one of those assigned UUIDs would need to be assigned to the /flow policy in the authorizations.xml file. NiFi on first startup only creates the users.xml and authorizations.xml file based on initial admin identity and node Identity values configured in the authorizers.xml file.  If you have already started NiFi secure and later edit these identities, those changes will not be reflected in either file.   Remove these two files an restart NiFi so they are created new again with your changes (this should only be done during initial setup of a secure NiFi).  Once your initial admin user is able to access the UI, all additional users and authorizations policies would be added via the NiFi UI. Hope this helps, Matt ... View more

@Pr1    While I am not an IMAP expert, the exception you are seeing here: PKIX path building failed. unable to find valid certification path This is a TLS handshake exception telling you that the complete certificate trust chain does not exist in the keystore.  On the NiFi side the complete trust chain would found in the NiFi truststore.jks.  Note: If NiFi is not secured you may need to add the trust chain certs to the NiFI java's default cacerts keystore. You can use openssl to get the complete trust chain for the IMAP server you are trying to consume from: openssl s_client -connect <IMAP server>:<IMAP port> -showcerts In the server hello response returned from the IMAP server using above command, you will see multiple certificates.  First certificate is the imap server's public certificate (you do not need this one).  You will need all the public certificates that follow that server certificate.  These will be your Signing CAs (there may be one or more in order of signing until you reach the rootCA). The rootCa is last and you will notice the owner and issuer DN is the same. Each certificate begins with: -----BEGIN CERTIFICATE----- and ends with: -----END CERTIFICATE-----   So you want to copy each certificate including the above lines to separate files: Eaxamples: intermediate.pem, intermediate2.pem, rootCA.pem  You can then use keytool to import these CAs in to your NiFi truststore. keytool -importcert -alias <alias usually based off CN name for certiifcate> -file <certificate.pem> -keystore <truststore.jks or java cacerts> -trustcacerts Note: each certificate imported must use a unique alias.   I recommend importing your certificates in the same order as they were listed in openssl response (importing the rootCA last). Restart your NiFi so it loads the modified keystore. Hope this helps resolve your trust chain issue, Matt ... View more