On 14 Jan 2008, at 16:17, Jeff Blaine wrote: > How are people approaching the creation of host/host.foo.com > without human intervention?
There have been a couple of talks on this subject at recent AFS & Kerberos Best Practices Workshops: http://workshop.openafs.org/afsbpw05/talks/kerb-auto.html (slides at http://www.dice.inf.ed.ac.uk/publications/AFSWorkshop-2005/ AFSWorkshop.pdf ) and http://workshop.openafs.org/afsbpw07/talks/bbense.pdf The first link describes what we do here in Informatics @ Edinburgh University. We have a complex machine configuration system which installs, and customises, the operating system. At the end of that installation process, the machine prompts the user for a set of administrative credentials, and then uses those to create a principal for 'hostclient/machine.inf.ed.ac.uk'. The machine's configuration system then uses this hostclient principal to fetch key material for all service principals that the machine should have. Permissions over which principals to fetch are controlled by our central configuration database, which maintains a record of which services a machine runs, and therefore which principals a machine may be allowed. In addition, a hostclient/<machine> principal may only fetch keys for */<machine> principals. This obviously requires attended installation - part of our installation procedure is that a member of staff goes to each machine once installation is complete, and checks its console, so this isn't a huge burden for us. We did design, but never deployed, an alternative system which used the MAC address of the machine to control access to the initial key material. In this scheme, an administrator would tell a central daemon which machines were about to be installed - this would fetch the configuration details of these machines from a central database. As each machine completed installation, it would send a request to the daemon for key material for the hostclient principal. Only one request per machine would be permitted - multiple requests would be reported as security violations, and requests would have to come from the correct MAC address. This is obviously less secure than our current solution, but has the advantage that it allows unattended installation of large numbers of machines. Hope that helps, Simon. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
