@Josh Nicholson When using the kerberos-provider via the login-identity-providers.xml file. The user's full kerberos principal is going to be used every time. You can ignore the "default realm" property in the kerberos-provider provider (NiFi's code does not actually use it right now --> https://jira.apache.org/jira/browse/NIFI-6224 ) So when a user enters a username that does not include the "@<realm>" portion, the default realm as configured in the krb5.conf file configured in the nifi.properties file is used. That full DN is then passed through your configured identity.mapping.patterns. This means you need to have a pattern that matches on: ^(.*?)@(.*?)$ And a resulting value of: $1 so that only the username portion is then passed on to your configured authorizer. In the case of some user coming in with just username and other with full principal names... Those user coming in with just usernames must not being authenticated using the login provider. Even with a login provider configured the default TLS/SSL authentication is attempted first. So if these users have a trusted client certificate loaded in their browser it will be presented for authentication to your NiFi and those user will never see the login window. From a user certificate the full DN will be used to identify the user. That full DN is likely matching on your existing mapping pattern resulting in just the username you are seeing. So it is important that you not remove this existing mapping pattern, but instead add a second. nifi.security.identity.mapping.pattern.<any string> nifi.security.identity.mapping.value.<any string> Patterns are searched in a alpha-numeric order. First matching regex will be applied. Thank you, Matt ... View more

@Rinki Flow: 1. You can list out the files from the directory on every first day of month and check the filename attribute using RouteOnAttribute Processor to get only the current date files. In RouteOnAttribute processor you can use either of the above attributes to making use of nifi expression language we can only filtering out only the required files. 2.You can use ReplaceText processor to replace all this required metadata and store into HDFS/Hive..etc i'm thinking filetype is csv,avro,json so i kept expression like ${filename:substringAfter('.')} Replacement Value ${filename},${file.creationTime},${filename:substringAfter('.')},${file.size} To store the data to table you can use PutHDFS and create table on top of this directory. 3.You can use cron schedule to run the processor on first day of month and Execution in only on Primary node - If the Answer helped to resolve your issue, Click on Accept button below to accept the answer, That would be great help to Community users to find solution quickly for these kind of issues. ... View more

@Frank Gaibler First to your question: In general secure communication over IP is possible. I had a closer look to the issue you described and I have figured out that the nifi-toolkit does not seem to handle the Subject Alternative Names correctly, when you use it for creating the certificates. Right now, the toolkit does not differentiate between DNS names and IP addresses. Normally, you need to declare each subject alternative name as IP address or DNS name like dns:de1000-xxxx,ip:172.18.61.254,.... in your example. But, the nifi-toolkit ignores this syntax and by default everything is declared as DNS name. You can see it in the following screenshot: Here you should get "IP address 192.168.100.120" normally. So from my point of view, it is just a matter of how you create the certificates in the end, because when you use openssl / Java keytool directly for certificate creation, you can create proper certificates following exactly this way. I will follow up internally, but as a workaround you can create the certificates directly using openssl / Java keytool. This should solve the problem. ... View more