Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

NiFi Reporting Task - Getting Unable to refresh Remote Group's peers due to response code 403:Forbidden with explanation: null

avatar
New Contributor

93577-hdf-community-question.png

In stanalone and secured NiFi 1.7.0 using oauth 2.0 as authentication mechanism. I try to use the SiteToSiteProvenanceReportingTask

The property 'Transport Protocol' of Remote Process Group is 'HTTP'. I get the error message:

Attached is the snapshot of the Reporting Task configurations:

I get the below error in bulletin and logs:

Unable to refresh Remote Group's peers due to response code 403:Forbidden with explanation: null 2018-11-12 06:20:27,984 INFO [Timer-Driven Process Thread-4] o.a.n.c.s.TimerDrivenSchedulingAgent Stopped scheduling SiteToSiteProvenanceReportingTask[id=<id>] to run

The Site to Site properties nifi.properties are as below:

nifi.remote.input.host=<hostname>, nifi.remote.input.secure=true, nifi.remote.input.socket.port=10443, nifi.remote.input.http.enabled=true, nifi.remote.input.http.transaction.ttl=30 sec nifi.remote.contents.cache.expiration=30 secs

How to resolve it?

Thanks for your help.

Poonam

1 ACCEPTED SOLUTION

avatar
Super Mentor
@Poonam Mishra

-

When using Site-To-Site (S2S) between two secured NiFi instances a 2-way TLS handshake occurs. Based on the specific error you are getting, this handshake appears to have been successful. This means your issue purely falls on the Authorization side.

-

The NiFi instance running the SiteToSiteProvenanceReportingTask is acting as the client in this connection to your other NiFi instance acting as the Server side of the connection. So it is the Server side NiFi that is checking what authorizations have been granted for the client NiFi instance(s) (If source is a NiFi cluster, every node will need to be authorized).

-

The full DN from the PrivateKeyEntry found in your keystore on the client NIFi will be used. If your target/Server side NiFi has any configured Identity.mapping.patterns defined in its nifi.properties file, then that full DN will be evaluated against them to see fi any match. If a match is found, then resulting mapping value is passed to the authorizer; otherwise, full DN will be passed to authorizer.

-

You have not shared what authorizer you are using, but there must exist user entries for every client NiFi who is connecting.

For S2S, these client strings passed to the authorizer (case sensitive) must be granted the following policies:

1. "retrieve site-to-site details" <-- This policy allows the client NiFi (one with reporting task) to retrieve details about the target which includes details on supported transport protocols, number of nodes, RAW port values, Node hostnames, node load, etc...).

2. "receive data via site-to-site" <-- This policy allows the authorized client to utilize this remote input port for sending FlowFiles. This would be authorization set on your "ProvenanceMonitoring" remote input port.

-

Check both your nifi-app.log and nifi-user.log for full stack traces and error related to this process.

-

Thank you,

Matt

-

If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link.

View solution in original post

3 REPLIES 3

avatar
Super Mentor
@Poonam Mishra

-

When using Site-To-Site (S2S) between two secured NiFi instances a 2-way TLS handshake occurs. Based on the specific error you are getting, this handshake appears to have been successful. This means your issue purely falls on the Authorization side.

-

The NiFi instance running the SiteToSiteProvenanceReportingTask is acting as the client in this connection to your other NiFi instance acting as the Server side of the connection. So it is the Server side NiFi that is checking what authorizations have been granted for the client NiFi instance(s) (If source is a NiFi cluster, every node will need to be authorized).

-

The full DN from the PrivateKeyEntry found in your keystore on the client NIFi will be used. If your target/Server side NiFi has any configured Identity.mapping.patterns defined in its nifi.properties file, then that full DN will be evaluated against them to see fi any match. If a match is found, then resulting mapping value is passed to the authorizer; otherwise, full DN will be passed to authorizer.

-

You have not shared what authorizer you are using, but there must exist user entries for every client NiFi who is connecting.

For S2S, these client strings passed to the authorizer (case sensitive) must be granted the following policies:

1. "retrieve site-to-site details" <-- This policy allows the client NiFi (one with reporting task) to retrieve details about the target which includes details on supported transport protocols, number of nodes, RAW port values, Node hostnames, node load, etc...).

2. "receive data via site-to-site" <-- This policy allows the authorized client to utilize this remote input port for sending FlowFiles. This would be authorization set on your "ProvenanceMonitoring" remote input port.

-

Check both your nifi-app.log and nifi-user.log for full stack traces and error related to this process.

-

Thank you,

Matt

-

If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link.

avatar
New Contributor

@Matt Clarke After granting receive data via site-to-site policy to "ProvenanceMonitoring" remote input port, also all user entries are there in authorizers for every client. But still I get an error: "org.apache.nifi.remote.client.PeerSelector@6fcc8729 Unable to refresh Remote Group's peers due to Read timed out". Please help!

avatar
Super Mentor

Is the destination NiFi of your ReprotingTask a NiFi cluster or Single NiFi instance?

On the NiFi instance the RPG is pointing at, what is configured in the following property:

nifi.remote.input.host