Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Authorization problem in Nifi cluster

Authorization problem in Nifi cluster

Expert Contributor

Dear community,

I am trying to configure a nifi cluster with authorization and authentification via LDAP. The authentification works correctly, but authorization does not.

I am not using internal CA, but use certificates generated by Let`s Encrypt. Each machine has its own keystore with one certificate.

On login I am receiving message "Unable to perform the desired action due to insufficient permissions. Contact the system administrator.".

In nifi-user.log:

2017-04-04 23:27:01,060 INFO [NiFi Web Server-23] o.a.n.w.s.NiFiAuthenticationFilter Authentication success for my.User

2017-04-04 23:27:01,085 INFO [NiFi Web Server-23] o.a.n.w.a.c.AccessDeniedExceptionMapper my.User does not have permission to access the requested resource. Returning Forbidden response.

I tried the standalone variant according to http://docs.hortonworks.com/HDPDocuments/HDF2/HDF-2.1.2/bk_dataflow-administration/bk_dataflow-admin... It works fine.

However when going into cluster I am getting the error. As mentioned in documentation all the nodes have the same authorizers.xml and authorized-users.xml. On start the authorizations.xml and users.xml are created successfully on all nodes. For configuration I had used this manual: https://community.hortonworks.com/articles/81184/understanding-the-initial-admin-identity-access-po....

authorized-users.xml:

<users>
    <user dn="CN=my User,OU=mydepartment,OU=com,DC=company,DC=local">
        <role name="ROLE_ADMIN"/>
        <role name="ROLE_DFM"/>
    </user>
</users>

authorizers.xml:

<authorizers>
<authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations File">/mnt/hadoop/nifi/conf/authorizations.xml</property>
<property name="Users File">/mnt/hadoop/nifi/conf/users.xml</property>
<property name="Legacy Authorized Users File">/mnt/hadoop/nifi/conf/authorized-users.xml</property>
<property name="Initial Admin Identity"></property>
<property name="Node Identity 1">dev-hdf01.test.company.com</property>
<property name="Node Identity 2">dev-hdf02.test.company.com</property>
<property name="Node Identity 3">dev-hdf03.test.company.com</property>
</authorizer>
</authorizers>

The reason why I do not have Initial Admin Identity because I am trying to control the users via authorized-users.xml.

nifi.properties:

nifi.security.identity.mapping.pattern.dn=^CN=(.*?),OU=(.*?)$
nifi.security.identity.mapping.pattern.dn2=^CN=(.*-[^ ]+?)$
nifi.security.identity.mapping.pattern.kerb=
nifi.security.identity.mapping.value.dn=$1
nifi.security.identity.mapping.value.dn2=$1

Checked patterns with regex tester. Seems to be working.

10 REPLIES 10

Re: Authorization problem in Nifi cluster

Expert Contributor

According to this https://community.hortonworks.com/articles/61729/nifi-identity-conversion.html tried to add:

"nifi.toolkit.dn.prefix": "CN=",
"nifi.toolkit.dn.suffix": "",

nifi.toolkit.dn.suffix is empty because DN from letsencrypt is CN=dev-hdf01.test.company.com

Re: Authorization problem in Nifi cluster

Expert Contributor

Checked https certificates on machines in cluster. Everything seems ok.

  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-SHA256
* Server certificate:
*  subject: CN=dev-hdf01.test.company.com
*  start date: 2017-03-31 08:22:00 GMT
*  expire date: 2017-06-29 08:22:00 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: dev-hdf01.test.company.com:9091
> Accept: */*

Re: Authorization problem in Nifi cluster

Expert Contributor

Still having this picture

14385-nifi.png

Re: Authorization problem in Nifi cluster

Expert Contributor

users.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
    <groups/>
    <users>
        <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def" identity="my User"/>
        <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254" identity="dev-hdf01.test.company.com"/>
        <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319" identity="dev-hdf02.test.company.com"/>
        <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721" identity="dev-hdf03.test.company.com"/>
    </users>
</tenants>

authorizations.xml:

<authorizations>
    <policies>
        <policy identifier="a59757a6-adc8-3d06-8606-6a799634b2bd" resource="/controller" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="7aefc265-1e47-3c26-853a-8ae8edad0bd4" resource="/policies" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="84729226-45e2-324c-999a-d87bd37d7d41" resource="/policies" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="adc44004-0829-3e7b-ba73-6f02abc95e17" resource="/tenants" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="b536bfa5-ab43-38a1-a683-21d209169150" resource="/flow" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="2353d6ee-5514-3c71-b526-bbd4b8184112" resource="/tenants" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="5092ba54-9c82-3261-8e28-456a702a6f46" resource="/process-groups/7c84501d-d10c-407c-b9f3-1d80e38fe36a" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="30c09a19-304a-316f-9848-198c1bd51205" resource="/process-groups/7c84501d-d10c-407c-b9f3-1d80e38fe36a" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="d1feaf04-fdb8-3d9b-857d-e683253b0642" resource="/restricted-components" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="6a4151df-47d0-355c-b330-bff39bbd5c50" resource="/controller" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="835a87d3-48af-347d-974a-667a4c62f0e5" resource="/system" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="68776817-426d-3c54-8397-e99bbd017800" resource="/data/process-groups/7c84501d-d10c-407c-b9f3-1d80e38fe36a" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
        <policy identifier="b8ec3441-5417-30a6-89a7-c466803975bd" resource="/data/process-groups/7c84501d-d10c-407c-b9f3-1d80e38fe36a" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
        <policy identifier="8a19b211-a11c-3d17-8bbe-c58934620154" resource="/proxy" action="R">
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
        <policy identifier="dce9877c-7055-3750-adf3-5aac66a03d17" resource="/proxy" action="W">
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
    </policies>
</authorizations>
Highlighted

Re: Authorization problem in Nifi cluster

Expert Contributor

Tried not using "Legacy Authorized Users File". Instead specified "Initial Admin Identity", but recieve the same error:

2017-04-05 12:29:41,203 INFO [NiFi Web Server-78] o.a.n.w.s.NiFiAuthenticationFilter Authentication success for my.User
2017-04-05 12:29:41,208 INFO [NiFi Web Server-78] o.a.n.w.a.c.AccessDeniedExceptionMapper my.User does not have permission to access the requested resource. Returning Forbidden response.

14386-nifi2.png

authorizers.xml:

<authorizers>
<authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations File">/mnt/hadoop/nifi/conf/authorizations.xml</property>
<property name="Users File">/mnt/hadoop/nifi/conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Node Identity 1">dev-hdf01.test.company.com</property>
<property name="Node Identity 2">dev-hdf02.test.company.com</property>
<property name="Node Identity 3">dev-hdf03.test.company.com</property>
</authorizer>
</authorizers>

users.xml and authorizations.xml look the same as before.

users.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
    <groups/>
    <users>
        <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def" identity="my User"/>
        <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254" identity="dev-hdf01.test.company.com"/>
        <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319" identity="dev-hdf02.test.company.com"/>
        <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721" identity="dev-hdf03.test.company.com"/>
    </users>
</tenants>

authorizations.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
    <policies>
        <policy identifier="5e3cde8a-cc45-3895-93ab-d915c4b25b41" resource="/flow" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="4c56214e-a731-39c8-a55b-01edd488a4c7" resource="/restricted-components" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="8a742337-b4c1-3cfd-a30e-ebbbaaa5d0bb" resource="/tenants" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="ffde3c8e-f9f4-36e3-9495-8c4e0b001633" resource="/tenants" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="56478c43-0cce-335a-9657-4169455eee9c" resource="/policies" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="7786999f-46a8-364d-a5e1-ef8cd56e50c9" resource="/policies" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="68c086a6-c723-3b1f-9598-80524d1daf4a" resource="/controller" action="R">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="e376da0f-4cbc-359a-b014-b504d4a34e9c" resource="/controller" action="W">
            <user identifier="737d2997-486f-3ae2-bf23-ef4686e63def"/>
        </policy>
        <policy identifier="8a19b211-a11c-3d17-8bbe-c58934620154" resource="/proxy" action="R">
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
        <policy identifier="dce9877c-7055-3750-adf3-5aac66a03d17" resource="/proxy" action="W">
            <user identifier="41ccf709-0a95-33e2-bfcb-1788ba3ef254"/>
            <user identifier="41221a52-e9b8-31d9-bdfc-1ef56cece319"/>
            <user identifier="5c60bd68-9ac9-37c1-9e7a-a95ec78af721"/>
        </policy>
    </policies>
</authorizations>

Re: Authorization problem in Nifi cluster

Expert Contributor

Added more verbosity using logback.xml.

logback.xml:

<configuration scan="true" scanPeriod="30 seconds">
    <contextListener>
        <resetJUL>true</resetJUL>
    </contextListener>
    <appender name="APP_FILE">
        <file>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app.log</file>
        <rollingPolicy>
            <!--
              For daily rollover, use 'app_%d.log'.
              For hourly rollover, use 'app_%d{yyyy-MM-dd_HH}.log'.
              To GZIP rolled files, replace '.log' with '.log.gz'.
              To ZIP rolled files, replace '.log' with '.log.zip'.
            -->
            <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app_%d{yyyy-MM-dd_HH}.%i.log.gz</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy>
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!-- keep 30 log files worth of history -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
            <immediateFlush>true</immediateFlush>
        </encoder>
    </appender>
    <appender name="USER_FILE">
        <file>${org.apache.nifi.bootstrap.config.log.dir}/nifi-user.log</file>
        <rollingPolicy>
            <!--
              For daily rollover, use 'user_%d.log'.
              For hourly rollover, use 'user_%d{yyyy-MM-dd_HH}.log'.
              To GZIP rolled files, replace '.log' with '.log.gz'.
              To ZIP rolled files, replace '.log' with '.log.zip'.
            -->
            <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-user_%d.log.gz</fileNamePattern>
            <!-- keep 30 log files worth of history -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
        </encoder>
    </appender>
    <appender name="BOOTSTRAP_FILE">
        <file>${org.apache.nifi.bootstrap.config.log.dir}/nifi-bootstrap.log</file>
        <rollingPolicy>
            <!--
              For daily rollover, use 'user_%d.log'.
              For hourly rollover, use 'user_%d{yyyy-MM-dd_HH}.log'.
              To GZIP rolled files, replace '.log' with '.log.gz'.
              To ZIP rolled files, replace '.log' with '.log.zip'.
            -->
            <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-bootstrap_%d.log.gz</fileNamePattern>
            <!-- keep 5 log files worth of history -->
            <maxHistory>5</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
        </encoder>
    </appender>
    <appender name="CONSOLE">
        <encoder>
            <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
        </encoder>
    </appender>
    <!-- valid logging levels: TRACE, DEBUG, INFO, WARN, ERROR -->
    <logger name="org.apache.nifi" level="INFO"/>
    <logger name="org.apache.nifi.processors" level="WARN"/>
    <logger name="org.apache.nifi.processors.standard.LogAttribute" level="INFO"/>
    <logger name="org.apache.nifi.controller.repository.StandardProcessSession" level="WARN" />
    <logger name="org.apache.zookeeper.ClientCnxn" level="ERROR" />
    <logger name="org.apache.zookeeper.server.NIOServerCnxn" level="ERROR" />
    <logger name="org.apache.zookeeper.server.NIOServerCnxnFactory" level="ERROR" />
    <logger name="org.apache.zookeeper.server.quorum" level="ERROR" />
    <logger name="org.apache.zookeeper.ZooKeeper" level="ERROR" />
    <!-- Logger for managing logging statements for nifi clusters. -->
    <logger name="org.apache.nifi.cluster" level="DEBUG"/>
    <!-- Logger for logging HTTP requests received by the web server. -->
    <logger name="org.apache.nifi.server.JettyServer" level="INFO"/>
    <!-- Logger for managing logging statements for jetty -->
    <logger name="org.eclipse.jetty" level="INFO"/>
    <!-- Suppress non-error messages due to excessive logging by class or library -->
    <logger name="com.sun.jersey.spi.container.servlet.WebComponent" level="ERROR"/>
    <logger name="com.sun.jersey.spi.spring" level="ERROR"/>
    <logger name="org.springframework" level="ERROR"/>
    <!-- Suppress non-error messages due to known warning about redundant path annotation (NIFI-574) -->
    <logger name="com.sun.jersey.spi.inject.Errors" level="ERROR"/>
    <!--
        Logger for capturing user events. We do not want to propagate these
        log events to the root logger. These messages are only sent to the
        user-log appender.
    -->
    <logger name="org.apache.nifi.web.security" level="DEBUG" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
    <logger name="org.apache.nifi.web.api.config" level="INFO" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
    <logger name="org.apache.nifi.authorization" level="DEBUG" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
    <logger name="org.apache.nifi.cluster.authorization" level="DEBUG" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
 <logger name="org.springframework.security.ldap.authentication" level="DEBUG" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
    <logger name="org.apache.nifi.web.filter.RequestLogger" level="INFO" additivity="false">
        <appender-ref ref="USER_FILE"/>
    </logger>
    <!--
        Logger for capturing Bootstrap logs and NiFi's standard error and standard out.
    -->
    <logger name="org.apache.nifi.bootstrap" level="INFO" additivity="false">
        <appender-ref ref="BOOTSTRAP_FILE" />
    </logger>
    <logger name="org.apache.nifi.bootstrap.Command" level="INFO" additivity="false">
        <appender-ref ref="CONSOLE" />
        <appender-ref ref="BOOTSTRAP_FILE" />
    </logger>
    <!-- Everything written to NiFi's Standard Out will be logged with the logger org.apache.nifi.StdOut at INFO level -->
    <logger name="org.apache.nifi.StdOut" level="INFO" additivity="false">
        <appender-ref ref="BOOTSTRAP_FILE" />
    </logger>
    <!-- Everything written to NiFi's Standard Error will be logged with the logger org.apache.nifi.StdErr at ERROR level -->
    <logger name="org.apache.nifi.StdErr" level="ERROR" additivity="false">
        <appender-ref ref="BOOTSTRAP_FILE" />
    </logger>
    <root level="INFO">
        <appender-ref ref="APP_FILE"/>
    </root>
</configuration>

Also added some dn mappings:

nifi.security.identity.mapping.pattern.dn3 : ^cn=(.*?),ou=(.*?)$
nifi.security.identity.mapping.value.dn3 : $1
nifi.security.identity.mapping.pattern.dn4 : ^cn=(.*-[^ ]+?)$
nifi.security.identity.mapping.value.dn4 : $1

However still have the same error when trying to login to web interface. And following errors in nifi-user.log:

2017-04-05 15:17:26,891 DEBUG [NiFi Web Server-85] o.s.s.l.a.LdapAuthenticationProvider Processing authentication request for user: my.User
2017-04-05 15:17:27,229 DEBUG [NiFi Web Server-85] o.s.s.l.authentication.BindAuthenticator Attempting to bind as cn=my User,ou=mydepartment,ou=com,dc=company,dc=local
2017-04-05 15:17:27,312 DEBUG [NiFi Web Server-85] o.s.s.l.authentication.BindAuthenticator Retrieving attributes...
2017-04-05 15:17:27,499 DEBUG [NiFi Web Server-87] o.a.n.w.s.x509.X509CertificateExtractor No client certificate found in request.
2017-04-05 15:17:28,183 DEBUG [NiFi Web Server-18] o.a.n.w.s.NiFiAuthenticationFilter Checking secure context token: null
2017-04-05 15:17:28,183 DEBUG [NiFi Web Server-18] o.a.n.w.s.x509.X509CertificateExtractor No client certificate found in request.
2017-04-05 15:17:28,183 DEBUG [NiFi Web Server-18] o.a.n.w.s.NiFiAuthenticationFilter Checking secure context token: null
2017-04-05 15:17:28,184 INFO [NiFi Web Server-18] o.a.n.w.s.NiFiAuthenticationFilter Attempting request for (eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ2LmZhbGZ1c2h5bnNreWkiLCJpc3MiOiJMZGFwUHJvdmlkZXIiLCJhdWQiOiJMZGFwUHJvdmlkZXIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ2LmZhbGZ1c2h5bnNreWkiLCJraWQiOjEsImV4cCI6MTQ5MTQ0MTQ0NywiaWF0IjoxNDkxMzk4MjQ3fQ.Okgl4l6P8U0vyK5jdcQmo12CkE39p0SDDVaTPWsyf-8) GET https://dev-hdf01.test.company.com:9091/nifi-api/flow/current-user (source ip: 10.1.1.2)
2017-04-05 15:17:28,187 INFO [NiFi Web Server-18] o.a.n.w.s.NiFiAuthenticationFilter Authentication success for my.User
2017-04-05 15:17:28,188 DEBUG [NiFi Web Server-18] o.a.n.w.s.NiFiAuthenticationFilter Checking secure context token: my.User
2017-04-05 15:17:28,188 DEBUG [NiFi Web Server-18] o.a.n.w.s.a.NiFiAnonymousUserFilter SecurityContextHolder not populated with anonymous token, as it already contained: 'my.User'
2017-04-05 15:17:28,216 INFO [NiFi Web Server-18] o.a.n.w.a.c.AccessDeniedExceptionMapper my.User does not have permission to access the requested resource. Returning Forbidden response.

Out of ideas ....

Re: Authorization problem in Nifi cluster

Super Guru

are there any file permissions? firewalls between nodes? every nifi running as same users? no other messages in logs directory of nifi or in /var/log...?

Everything node on the same version? anything upgraded? everything fine in ambari? anything in ambari logs?

see: https://community.hortonworks.com/questions/79363/unable-to-add-new-node-to-nifi-110-cluster.html

http://bryanbende.com/development/2016/08/17/apache-nifi-1-0-0-authorization-and-multi-tenancy

Look at this one: https://pierrevillard.com/2016/11/30/scaling-updown-a-nifi-cluster/

Re: Authorization problem in Nifi cluster

Expert Contributor

Thanks for reply.

I am using debian 7 with Ambari 2.4. Cluster is deployed from scratch without any modifications and custom configuration via blueprints. The file permissions are default. Configuration files belong to nifi user as specified by default. Firewall - all ports between cluster nodes are opened. Can not see any other logs regarding nifi except in /var/log/nifi/. Every node is running the same version of nifi, nothing is upgraded, ambari has no issues neither in GUI nor in logs.

I`ve looked into this: http://bryanbende.com/development/2016/08/17/apache-nifi-1-0-0-authorization-and-multi-tenancy

Will try to look into other to recommendations.

Many thanks for help. Is there a possibility get more verbosity about user authorization?

Re: Authorization problem in Nifi cluster

Expert Contributor

@Timothy Spann

I was able to run apache nifi(package downloaded from nifi.apache.org) on my local machine in cluster mode with ldap and https. The problem was with user identity mapping. The configuration only supports one identity mapping in nifi.properties:

nifi.security.identity.mapping.pattern.dn=^cn=(.*?),ou=(.*?)$
nifi.security.identity.mapping.value.dn=$1

Also the dn attributes should be lowercase for AD.

However when I tried that same configuration on my HDF cluster the authorization failed. I`ve noticed here https://community.hortonworks.com/articles/61729/nifi-identity-conversion.html that there are some rules in HDF for host identity mapping. The link shows an example when NIFI internal CA is used. However I am using letsencrypt for host certificates. Can NIFI internal CA parameters cause the problem?

I`ve looked into sources of NIFI mpack of HDF and it is very integrated with internal CA. Had not found any option how to disable it.

Don't have an account?
Coming from Hortonworks? Activate your account here