#4958 [RFE] Automatic client enrollment using ip ranges (similar to securenets in NIS)
Closed: wontfix 5 years ago by rcritten. Opened 9 years ago by pvoborni.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1204691

Description of problem:

Currently, the closest method for enrolling clients automatically is adding
hosts beforehand with one time passwords and then launching unattended client
installs. This, however, requires manual intervention by the admin for every
host that needs to be added to the network. In our environment, users own and
are responsible for their hosts. i.e. Users don't change that often, but they
would like to enroll new hosts. If the hosts can be enrolled automatically
based on some criteria (ip range or a regex of the fqdn), it would eliminate
the dependence on the admin for enrolling hosts. This functionality already
exists in NIS in the form of securenets.

Relevant discussion thread:
https://www.redhat.com/archives/freeipa-users/2015-March/msg00616.html

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Triage comments:

  • authorization based on IP address sounds like security measure from 1990's
  • automatic client enrollment were deferred to specific plugins.
  • ssh does not do host based authentication for decade on purpose
  • but this is not about authentication -- it's about "fixating" identity of the host that the host has anyway -- if the host gets a particular IP address from DHCP and the network is willing to route it, why not allow that host to grab a principal as well
  • question is where this check would be added - low level admins have privilege/ACI to enroll (add) hosts

Automatically enrolling hosts that appear on the network can be a good idea in certain environments, specifically when IPA is operated as a second-order infrastructure in the shadows of a primary infrastructure which is already enforcing network access control.

Nevertheless such inventory automation is probably better dealt by hacking scripts into servers dealing with protocols such as RADIUS and DHCP. This is likely to be preferred over adding degrees of freedom to the IPA code base.

My favorite is to hook into ISC DHCPd "on commit" event, and calling {{{ipa host-add}}} when a new host shows up. Users are then directed to visit an LDAP protected web application (portal page) that requires to adopt the host matching the client IP address, provided that it is still not adopted. By adopting the host the right is granted to retrieve the host keytab (and the host is finally allowed through the firewall).

Here is a boilerplate for dhcpd.conf to call scripts with information about the lease:

on commit {
  # commit.sh 192.168.5.11 67899876 5:d:11:22:3:4:6 'hostname'
  execute ("/etc/dhcp3/commit.sh",
    binary-to-ascii(10, 8, ".", leased-address),
    binary-to-ascii(10, 16, "", encode-int(lease-time, 16)),
    binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)),
    pick-first-value(option host-name, "")
  );
}
on release {
  execute ("/etc/dhcp3/release.sh",
    binary-to-ascii(10, 8, ".", leased-address),
    binary-to-ascii(16, 8, ":", substring(hardware, 1, 6))
  );
}
on expiry {
  execute ("/etc/dhcp3/expiry.sh",
    binary-to-ascii(10, 8, ".", leased-address)
  );
}

Metadata Update from @pvoborni:
- Issue assigned to someone
- Issue set to the milestone: Tickets Deferred

7 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata