On Wed, Dec 31, 2014 at 01:59:32PM -0500, Brendan Kearney wrote:
> i have played with nsupdate, and it does look like updates will be
> allowed if i remove the access restriction, but i am losing the
> authenticity of the update, since the TSIG shared secret signs the
The goal is not to remove the access restriction. The goal is to use
grant DHCP\047dhcp-server.example....@example.com wildcard *
or some similar principal for your DHCP server, retrieve its keytab
(possibly with ipa-getkeytab), and then do
kinit -kt /the/path/to/the/dhcp/service.keytab
> regardless of authentication, client updates to DNS zones are still a
> risk and a rogue app or user can still perform direct updates to zones,
> leading to impersonation/interception of services, denial of service
> attacks and more.
In case of your DHCP use case, you certainly might not want to enable
the client updates. However, client updates are something different
than allowing a particular service (and only that service) to update
the zone records.
Also, note that how you enable the client updates matter. The wiki page
grant EXAMPLE.COM krb5-self * A;
which means that authenticated host can only change its own A record
-- it cannot impersonate another hostname like you suggest.
> endpoints, or their users, should not be trusted to
> make updates to DNS zones. TSIG signed updates from servers are still
> preferred over authenticated updates from endpoints or users.
Server has identity just like service, just like user. You can have
unimportant server and you can have important (admin) user. Ruling
> i am using ISC DHCP, and cannot speak to any level of effort required to
> incorporate Kerberos into the code.
shows how ISC DHCP's execute can be used to send the changes to
an external command, and that command can include the
kinit -kt + nsupdate -g combo.
Principal Software Engineer, Identity Management Engineering, Red Hat
Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project