It can also be used to filter out potential spoofs. For example, the Additional and primary mac fields (unless otherwise specified) is how the service is handled for now. Basically, it tests any/all macs against all hosts in the system. If there’s a match, it continues to pass information to the host about what’s being sent. This is important, for example, in the case of Active directory.
If we just assumed all MACs were safe for the host it’s registering from, you would potentially be opening yourself up for attack. Not necessarily in a traditional sense.
For example, the most secure piece of information we want to protect, the Active Directory Password. Yes, I know you shouldn’t have admin rights on the user (create a new one as necessary) to allow FOG to register the host to the domain. However, this isn’t always practical. Whether by inexperience/knowledge, or because the setup was just done quick and dirty. That said, if all mac’s where automatically “approved” the potential arises that somebody could inject their own macs to a host. Because their host is no registered, they can see all the data sent from the server including the AD Password. (of course the new client doesn’t have this issue as readily, but still).
It’s these types of things we’re trying to help prevent as much as possible that we require you to approve the macs. If you are always going in and approving all macs, then I say shame on you, but to each their own. The mac’s can be approved by the individual MAC from the relevant host or hosts. The “green checkbox” that appears is the link on how to approve a single mac address. You can also approve all macs from the host as well.
It’s actually these security concerns that allowed us to have the FOG Client (New again) register the host if it was not already registered to the main FOG system. In olden times the client did register the host to the server if it wasn’t already done, but it also registered them as “approved”.
Main flaw, I think, in that approach is FOG is dependent upon a system being compatible to image/task a system. This is why the full register drops you into the init and you get asked all those questions, followed by a reboot if you wanted the system to image. If we only registered hosts through iPXE, the potential arises that a host is registered, and FOG recognizes it, but the init’s do not have the proper drivers to actually support imaging that device, so your system is stuck in a boot loop. Under the new client, the registration still happens, and the potential is still there that the registered through the client system is not compatible, but you can’t task the system until it is in an “approved” state.
Basically, we’re moving fog into an admin centric style system. The Administrator of the network/systems should know about any and all items being input especially when dealing with a host. If you’re registering through one of the registration/quick reg systems on the PXE menu, you already have a head start because there had to be a form of action performed to enable that reception of the task. So these full/quick registration methods are assumed to be “trusted”. Systems that are registered by the fog client is not automatically assumed trusted, because anybody can download the FOG Client installer and communicate to your fog server. By placing the system in a “pending” state, we keep the service from receiving unwarranted data. It also gives you and your admins a chance to verify the host indeed is valid for your network. The same principle for the MAC addresses.
Hopefully all this makes sense.