You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by James McMahon <js...@gmail.com> on 2023/01/02 16:38:32 UTC

Re: NiFi failing to start

Russ and Chris, thank you for responding. I got this to work. It turned out
to be a combination of different issues. One was finding the proper
arguments for tls-toolkit so that my CN would be set properly in my certs.
The second was configuration settings in my nifi.properties file.

For that first challenge, these were the tls-toolkit commands I used that
worked:
./bin/tls-toolkit.sh standalone -n 'ec2-52-4-149-72.compute-1.amazonaws.com'
--certificateAuthorityHostname 'ec2-52-4-149-72.compute-1.amazonaws.com'
./bin/tls-toolkit.sh standalone -B <my_password_here> -C "CN=admin, OU=NIFI"
Once I did this, I used openssl to query my pkcs12 file, verifying that my
CN now properly included ec2-52-4-149-72.compute-1.amazonaws.com rather
than *localhost*. This is an excerpt of what I found:

Command: openssl pkcs12 -info -nodes -in CN=admin_OU=NIFI.p12

Enter Import Password:

MAC Iteration 102400

MAC verified OK

PKCS7 Data

...

*subject=/OU=NIFI/CN=admin*

*issuer=/OU=NIFI/CN=ec2-52-4-149-72.compute-1.amazonaws.com
<http://ec2-52-4-149-72.compute-1.amazonaws.com>*

-----BEGIN CERTIFICATE-----

...

-----END CERTIFICATE-----

Certificate bag

Bag Attributes: <Empty Attributes>

*subject=/OU=NIFI/CN=ec2-52-4-149-72.compute-1.amazonaws.com
<http://ec2-52-4-149-72.compute-1.amazonaws.com>*

*issuer=/OU=NIFI/CN=ec2-52-4-149-72.compute-1.amazonaws.com
<http://ec2-52-4-149-72.compute-1.amazonaws.com>*

-----BEGIN CERTIFICATE-----

…..

-----END CERTIFICATE-----

For that second impediment, I eventually got it to work using these entries
in my nifi.properties:
nifi.authorizer.configuration.file=/opt/nifi/config_resources/authorizers.xml
#nifi.login.identity.provider.configuration.file=./conf/login-identity-providers.xml
nifi.login.identity.provider.configuration.file=

I'm still not entirely sure why I don't need to have a
login-identity-providers.xml file, but suspect it is because I now employ
TLS to present my identity, maybe?
My authorizers.xml looks like this:
<?xml version='1.0' encoding='UTF-8'?>
<!-- ANSIBLE MANAGED FILE. DO NOT EDIT -->
<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Initial User Identity 1">CN=admin,
OU=NiFi</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>

<class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group
Provider">file-user-group-provider</property>
        <property name="Authorizations
File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">CN=admin, OU=NiFi</property>
        <property name="Legacy Authorized Users File"></property>
        <property name="Node Identity 1">CN=admin, OU=NiFi</property>
        <property name="Node Group"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>

<class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy
Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

Thanks again for your replies.
Jim


On Wed, Dec 28, 2022 at 2:48 PM Russell Bateman <ru...@windofkeltia.com>
wrote:

> In case you or someone else wishes only to run, develop, start, stop,
> start over, etc., and doesn't care to authenticate a (non-production)
> installation, I have followed this since NiFi 1.14 and last used it for
> 1.19:
>
> https://www.javahotchocolate.com/notes/nifi.html#20210716
>
> If this doesn't work it's usually because the properties file has become
> too modified. Start over with a fresh download.
>
> Russ
>
>
> On 12/28/22 12:03, Chris Sampson wrote:
>
> I think you will need to remove/comment out the references to
> single-user-provider in authorisers.xml and login-providers.xml as well as
> removing it from nifi.properties (see the comments in these files as
> they're provided in the nifi distributions).
>
> If you are using 2-way TLS authentication then I don't think you need to
> configure anything else, but remember that all of your nifi instances in
> your cluster (if applicable) will need to trust one another's certificates
> along with all user certificates - the easiest way of doing this is
> typically to trust a common CA that issues all the nifi instance and user
> certs. This could be nifi-toolkit, but beware that the CA used by toolkit
> is auto-generated on startup, so you need to retain and configure the same
> CA for toolkit of you plan to use it to issue new certs in future.
>
> On Wed, 28 Dec 2022, 17:32 James McMahon, <js...@gmail.com> wrote:
>
>> I continue to experience errors when I try to start my nifi 1.16.3
>> instance. I have followed this guide in an effort to use the toolkit to
>> generate self-0signed certs for user admin, signed by a nifi truststore:
>>
>> Apache NiFi Walkthroughs
>> <https://nifi.apache.org/docs/nifi-docs/html/walkthroughs.html>
>>
>> I seem to be having issues with this in my nifi.properties:
>> nifi.security.user.authorizer=single-user-authorizer
>>
>> When I set it to nothing, it tells me this is required. When I set it to
>> single-user-authorizer, this error results in the log:
>>  Error creating bean with name 'authorizer': FactoryBean threw exception
>> on object creation; nested exception is java.lang.Exception: The specified
>> authorizer 'single-user-authorizer' could not be found.
>>
>> I suspect my authorizers.xml and/or my login-identity-providers.xml files
>> are misconfigured. How should those two config files be structured if I
>> wish to run a secure nifi instance where mith my self-signed certs,
>> generated using the nifi toolkit?
>>
>
>