LDAP auth and reports: foreman.rb

You're probably hitting the authorisation in Foreman 1.1 that only known
puppetmaster hosts can send reports and fact uploads when anonymous,
else the interfaces can be abused.

Can you check the /var/log/foreman/production.log file at the time of
the 403 and it should log a message in the middle of the response as to
why it's denied.

··· On 05/04/13 11:05, Antonio Xanxess wrote: > Hi all!! > > I have a problem with sending reports to foreman when I activate LDAP > authentication. > My setup is based on passenger + nginx + caching with dalli listening on > port 80. > The problem is that when active authentication to truein the > settings.yaml file, the report is not sent correctly nodes and nginx > gives a 403 error. > I think the problem is that foreman.rb file is responsible for > configuring the access through puppet foreman, I searched the internet > and have not seen any case where it is allowed to send the report using > a user for authentication. > Any ideas?


Dominic Cleal
Red Hat Engineering

Thank you Dominic, expose the file:

production.log:
Started POST "/reports/create?format=yml" for 10.9.8.6 at Tue Apr 02
14:04:28 +0200 2013
Processing by ReportsController#create as YML
Parameters: {"report"=>"[FILTERED]"}
127.0.0.1:11211 failed (count: 47)
DalliError: No server available
DalliError: No server available
DalliError: No server available
DalliError: No server available
No smart proxy server found on []
DalliError: No server available
DalliError: No server available
Redirected to http://10.9.8.10/users/login
Completed 403 Forbidden in 17ms

I notice that the browser redirects the request to http://[foreman_url]
/users/login

Foreman.rb could be programmed to authenticate directly with a internal user
?

My foreman.rb look like this:

URL of your Foreman installation

$foreman_url='http://10.9.8.10'

if CA is specified, remote Foreman host will be verified

$foreman_ssl_ca = "<%= @ssl_ca -%>"

ssl_cert and key are required if require_ssl_puppetmasters is enabled in

Foreman
$foreman_ssl_cert = "<%= @ssl_cert -%>"
$foreman_ssl_key = "<%= @ssl_key -%>"

require 'puppet'
require 'net/http'
require 'net/https'
require 'uri'

Puppet::Reports.register_report(:foreman) do
Puppet.settings.use(:reporting)
desc "Sends reports directly to Foreman"

def process
  begin
    uri = URI.parse($foreman_url)
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl     = uri.scheme == &#39;https&#39;
    if http.use_ssl?
      if $foreman_ssl_ca &amp;&amp; !$foreman_ssl_ca.empty?
        http.ca_file = $foreman_ssl_ca
        http.verify_mode = OpenSSL::SSL::VERIFY_PEER
      else
        http.verify_mode = OpenSSL::SSL::VERIFY_NONE
      end
      if $foreman_ssl_cert &amp;&amp; !$foreman_ssl_cert.empty? &amp;&amp; 

$foreman_ssl_key && !$foreman_ssl_key.empty?
http.cert =
OpenSSL::X509::Certificate.new(File.read($foreman_ssl_cert))
http.key = OpenSSL::PKey::RSA.new(File.read($foreman_ssl_key),
nil)
end
end
req = Net::HTTP::Post.new("#{uri.path}/reports/create?format=yml")
req.set_form_data({'report' => to_yaml})
response = http.request(req)
rescue Exception => e
raise Puppet::Error, "Could not send report to Foreman at
#{$foreman_url}/reports/create?format=yml: #{e}"
end
end
end

Thank you so much!

··· El viernes, 5 de abril de 2013 12:09:46 UTC+2, Dominic Cleal escribió: > > On 05/04/13 11:05, Antonio Xanxess wrote: > > Hi all!! > > > > I have a problem with sending reports to foreman when I activate LDAP > > authentication. > > My setup is based on passenger + nginx + caching with dalli listening on > > port 80. > > The problem is that when active authentication to truein the > > settings.yaml file, the report is not sent correctly nodes and nginx > > gives a 403 error. > > I think the problem is that foreman.rb file is responsible for > > configuring the access through puppet foreman, I searched the internet > > and have not seen any case where it is allowed to send the report using > > a user for authentication. > > Any ideas? > > You're probably hitting the authorisation in Foreman 1.1 that only known > puppetmaster hosts can send reports and fact uploads when anonymous, > else the interfaces can be abused. > > Can you check the /var/log/foreman/production.log file at the time of > the 403 and it should log a message in the middle of the response as to > why it's denied. > > -- > Dominic Cleal > Red Hat Engineering >

> Thank you Dominic, expose the file:
>
> production.log:
> Started POST "/reports/create?format=yml" for 10.9.8.6 at Tue Apr 02
> 14:04:28 +0200 2013
> Processing by ReportsController#create as YML
> Parameters: {"report"=>"[FILTERED]"}
> 127.0.0.1:11211 failed (count: 47)
> DalliError: No server available
> DalliError: No server available
> DalliError: No server available
> DalliError: No server available
> No smart proxy server found on []

Here's the issue… so Foreman bypasses the need for a user when
uploading reports and facts by checking whether the remote host (the
puppetmaster) should be able to upload.

It does this by doing a reverse DNS lookup on your host (10.9.8.6) and
then checking for a known smart proxy server (with the "Puppet" feature)
matching that hostname.

The log entry above suggests the reverse DNS lookup is failing and
returning no hostnames. Your options are:

a) fix the reverse DNS lookup, properly, or by adding it to /etc/hosts
on the Foreman host
b) disable the security checks, if you're on a trusted network (since
the upload mechanism can be attacked otherwise) by setting
"restrict_registered_puppetmasters" to false in More->Settings.

If you still get the error after doing a) but with a hostname this time,
check that the hostname matches the name in the smart proxy URL on your
puppetmaster host.

> DalliError: No server available
> DalliError: No server available
> Redirected to http://10.9.8.10/users/login
> Completed 403 Forbidden in 17ms
>
> I notice that the browser redirects the request to
> http://[foreman_url]/users/login
>
> Foreman.rb could be programmed to authenticate directly with a internal
> user?

We don't do this, but I guess it might work. We use the trust mechanism
outlined above normally.

··· On 05/04/13 11:55, Antonio Xanxess wrote:


Dominic Cleal
Red Hat Engineering

Dominic, solved!!! ^^

Thank you so much!

··· El viernes, 5 de abril de 2013 14:04:29 UTC+2, Dominic Cleal escribió: > > On 05/04/13 11:55, Antonio Xanxess wrote: > > Thank you Dominic, expose the file: > > > > production.log: > > Started POST "/reports/create?format=yml" for 10.9.8.6 at Tue Apr 02 > > 14:04:28 +0200 2013 > > Processing by ReportsController#create as YML > > Parameters: {"report"=>"[FILTERED]"} > > 127.0.0.1:11211 failed (count: 47) > > DalliError: No server available > > DalliError: No server available > > DalliError: No server available > > DalliError: No server available > > No smart proxy server found on [] > > Here's the issue.. so Foreman bypasses the need for a user when > uploading reports and facts by checking whether the remote host (the > puppetmaster) should be able to upload. > > It does this by doing a reverse DNS lookup on your host (10.9.8.6) and > then checking for a known smart proxy server (with the "Puppet" feature) > matching that hostname. > > The log entry above suggests the reverse DNS lookup is failing and > returning no hostnames. Your options are: > > a) fix the reverse DNS lookup, properly, or by adding it to /etc/hosts > on the Foreman host > b) disable the security checks, if you're on a trusted network (since > the upload mechanism can be attacked otherwise) by setting > "restrict_registered_puppetmasters" to false in More->Settings. > > If you still get the error after doing a) but with a hostname this time, > check that the hostname matches the name in the smart proxy URL on your > puppetmaster host. > > > DalliError: No server available > > DalliError: No server available > > Redirected to http://10.9.8.10/users/login > > Completed 403 Forbidden in 17ms > > > > I notice that the browser redirects the request to > > http://[foreman_url]/users/login > > > > Foreman.rb could be programmed to authenticate directly with a internal > > user? > > We don't do this, but I guess it might work. We use the trust mechanism > outlined above normally. > > -- > Dominic Cleal > Red Hat Engineering >