mikeg's blog

With your freshly installed radmin package, you now need to set up the server to start/run. There is essentially less than nothing to this if you installed the port or package:

1. Add radmind_enable="YES" to your /etc/rc.conf file
2. Optionally specify radmind_flags in your /etc/rc.conf file. You probably want to specify -D (the radmind root directory. Your load sets get stored here, so it needs lots of space. Defaults to /var/radmind). You may also want to specify other options as described below for SSL based authentication

Everything I talk about from here on will refer to /var/radmind as the radmind root directory because that's the default (and what I use in our test lab). Make the mental substitution if you're not using the defaults. You will then want to create a /var/radmind/config file. This file describes which load set/command file goes to which machine. The format of the file is pretty straightforward: Machine_ID [whitespace] Command_File Every machine that needs to access the radmind server needs to have a valid entry in the config file.

Machine_ID is either a reverse DNS hostname, an IP Address, or the Common Name of the Client Certificate. The wildcard * is acceptable in the ID strings, and if you have only one load set it's perfectly acceptable to have a config file that consists of one entry:

* command.K

Command_File needs to exist in order for an entry to be valid. You don't have to populate it (it can be an empty file), but if the file doesn't exist any entries referring to it won't work and the affected machine(s) won't have access to the radmind server. The syntax of command files will be discussed in the next part, but essentially it's a list of transcripts to apply (and the order to apply them in).

---

For my purposes, IP-based identification is "good enough" -- My radmind installation is on a closed, secure network so I'm not worried about encrypting or authenticating my traffic, and I'm dealing with servers which have static IP addresses so I don't need certs for identification. If your installation requires a bit more security, or if god forbid you are managing machines with dynamic or overlapping (!) IP addresses you'll have to enter the wonderful world of certificate-based authentication (and this is why I chased all the n00bs off before). No help will be provided with your CA/PKI woes - I assume if you're considering this you already have a CA set up for your organization with good policies and procedures, and that you have a solid understanding of how the whole PKI thing works. If you don't meet those criteria certificate-based authentication is not for you. See the note waaay at the top and come back when you've done the whole PKI thing. For those of you who need/want to use certificate-based authentication, here's the thumbnail sketch:

• The radmind server and clients get a copy of your CA's certificate (to verify its clients) and their identifying cert in /var/radmind/cert The server's cert is like an Apache certificate (its CN needs to match the hostname of the server), the client cert CNs can be anything you want as long as they don't have whitespace -- these are what you will put in the server's config file.
• You need to specify TLS authentication to the server and all of its clients (and the authentication you specify must match). The -w flag sets the authentication level: -w 0 is "no TLS", the default. -w 1 is Server Verification, The clients make sure the server's cert is trusted & the hostname matches. -w 2 is "Mutual Verification", -w 1 plus the server makes sure the client cert is signed by a known/trusted CA.
• Clients need to contact the radmind server by hostname -- This implies you have DNS working (or use NIS, or are otherwise disting out a hosts file), and if you're advanced enough to be using certs for authentication you better have SOME kind of working name service.
• You need to push out new certificates before they expire -- Expired certs implicitly fail validation because they are expired The implementation of a good system for redeploying certs is left as an exercise for the reader - you can actually use radmind to push them out as long as you do it before the certs expire...

---

The next part will talk about creating transcripts/load sets/command files for deployment. I even promise you some actual sample code in the form of a tarball because I know that's what you all want (fucking perverts!)