[Freeipa-users] Using DHCPD with IPA

[Simo Sorce]

On Fri, 2012-01-27 at 14:21 -0500, Dmitri Pal wrote:
> On 01/25/2012 07:38 PM, ~Stack~ wrote: 
> > On 01/25/2012 05:18 PM, Sigbjorn Lie wrote:
> > > On 01/25/2012 02:30 AM, ~Stack~ wrote:
> > > > 2) How do I get dhcpd to update DNS?
> > > > 
> > > > Since I can't find the place to add rndc-keys to BIND, right now I have
> > > > to add every host manually in the web interface because dhcpd isn't
> > > > updating named. This is time consuming and a pain when dealing with
> > > > large amounts of systems. If I could figure out where the named zones
> > > > are stored in IPA I should be able to add my rndc-key and be OK, but
> > > > that gets back into question 1.
> > > > 
> > > > My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients
> > > > have host entries to match their MAC with the group that allows PXE
> > > > booting (ex: host pxe001.project.local{hardware ethernet
> > > > 00:16:17:AB:E9:88; fixed-address 172.31.203.1}).  Unless I mange both
> > > > this file and the IPA interface, the nodes have issues figuring out
> > > > their name. One or the other and the node has issues; both and it works.
> > > > I would really prefer not to manage two locations for all these nodes.
> > > > 
> > > > The normal way for dhcpd to talk to BIND(named) is by having a rndc-key.
> > > > However, me fighting with named.conf was the big part of my problems
> > > > before so I am hoping there is a simple way of doing this inside IPA.
> > > > 
> > > > Any ideas?
> > > This is what I have done to work around issues similar to yours.
> > > 
> > > Over a few years I have developed a pxe boot toolbox called
> > > OneClickKick. OCK manages DHCPD by generating config files based upon
> > > information looked up from naming sources such as Mysql, NIS, or LDAP
> > > (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and
> > > serves kickstart files when PXE booting clients.
> > > 
> > > I have integrated OCK with IPA to make IPA keep records of the MAC
> > > address, and base my DHCP config upon the information I get from IPA.
> > > For your configuration, the steps for adding a new client would be the
> > > following:
> > > 
> > > 1. Add the host to IPA, specify an IP address so that forward and
> > > reverse DNS records are created for the host
> > > 2. The host will appear in OneClickKick, select modify, add the MAC
> > > address (this is being written to the host object in IPA), and select it
> > > for PXE boot / kickstart. This will generate the DHCP config file,
> > > reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg
> > > directory (if you enabled it for PXE booting).
> > > 3. PXE boot the client.
> > > 
> > > By doing this you eliminate the need for dhcpd to update the DNS server,
> > > because the records are already there.
> > > 
> > > The MAC addresses stored in IPA can also be used by normal Linux and
> > > Solaris (Jumpstart) clients by utilizing their "ethers" table in
> > > nsswitch.conf.
> > > 
> > > Have a look at the link below to read more and download if you think
> > > OneClickKick could suit your environment.
> > > 
> > > http://sourceforge.net/projects/oneclickkick/
> > Thank you! I will take a look at it tomorrow.
> > 
> > ~Stack~
> > 
> > 
> > _______________________________________________
> > Freeipa-users mailing list
> > Freeipa-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 
> What Adam was trying to say is that if you want a little bit more
> security to this enrollment process you need when you register host
> with IPA ask IPA for generated OTP (or provide your own). This OTP
> needs then to be seeded into the kickstart file. As the Kickstart file
> is processed the ipa-client-install command will be called with this
> OTP as one of the parameters. The ipa-client will authenticate to IPA
> server and finish the configuration of the system provisioning the
> keys.
> 
> When the machine is rebooted you need to do the same sequence except
> you need to delete and re add the host or clean its keytab and status
> (both options would work).
> 
> The OTP capability was specifically added to address automatic
> provisioning like this in a secure way.
> 
> Would it work for you?       

This needs some more explanation.

Recycling the keytab very often can lead to connection errors (users may
have valid tickets for the machine, and the machine will not longer
recognize them).

Keeping around the keytab for these host would be safer, even if you end
up refreshing the keytab using the OTP method, although if you keep
around the keytab then using the OTP seem more burden than anything.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York