New Fog client and security
-
@Joe-Schmitt said in New Fog client and security:
As much as the security model may seem like its an overkill, believe me when I say it is needed. We also built it in a fashion that you, as an end user, should almost never have to interact with it or manually intervene (e.g. resetting encryption data). The only time you need to step in is if you move your server to another machine or reinstall the client on the computer.
I think where I went wrong is expecting the client to change the host name when the setting was not enabled. The old client just did it because the setting was on a local ini. The new client was probably installed correctly the first time and I didn’t even realize it.
I can appreciate the work and time that went into the new security model. It’s just that for my situation, in a public library with public hosts on a network totally separate from our staff net, I am not sure I have a need for bullet-proof security there. I am more concerned about FOG booting my PC’s and reload them without hassles.
-
@LibraryMark The FOG_ENFORCE_HOST_CHANGES is supposed to enable the AD portion (when selected) to turn on. Seeing, as how I’m reading this thread, that you’re not using AD, this explains why the setting never occurred in your situation. All of these setting work based on defined settings, so if you’re editing a host in the GUI and the host doesn’t have the item checked, the host will display that the item isn’t checked.
This is all the more reason to follow what the logs are telling you. We try to make things as simple as possible but that doesn’t mean we won’t have some areas that do require user intervention.
I’m glad you were able to figure out the issue and that we were able to help you find out. The security is needed. Regardless of how you plan on using it. You are more than welcome to use whatever client you want, but I would recommend sticking with the new client.
-
@Tom-Elliott said in New Fog client and security:
@LibraryMark The FOG_ENFORCE_HOST_CHANGES is supposed to enable the AD portion (when selected) to turn on. Seeing, as how I’m reading this thread, that you’re not using AD, this explains why the setting never occurred in your situation. All of these setting work based on defined settings, so if you’re editing a host in the GUI and the host doesn’t have the item checked, the host will display that the item isn’t checked.
This is all the more reason to follow what the logs are telling you. We try to make things as simple as possible but that doesn’t mean we won’t have some areas that do require user intervention.
I’m glad you were able to figure out the issue and that we were able to help you find out. The security is needed. Regardless of how you plan on using it. You are more than welcome to use whatever client you want, but I would recommend sticking with the new client.
Yup, no AD here. Not for our public machines. I would think, however, that the “Make changes even when users are logged on?” setting might be handier in another spot, especially for those of us who do not use domains.
-
@LibraryMark said in New Fog client and security:
It’s just that for my situation, in a public library with public hosts on a network totally separate from our staff net, I am not sure I have a need for bullet-proof security there.
You’re public users are not a security risk? And I know you say you have HDD locking software (Centurion SmartShield or Faronics DeepFreeze probably), but this doesn’t really matter. If there’s a security hole and someone knows how to exploit it, they can exploit it every time they want. Once there’s a compromise, those computers are no longer safe for users to use, no matter how many times they are rebooted and ‘reset’. The legacy client is not secure. The legacy-enabling functionality server-side is also not secure. It is advised that once you have moved to the new fog client, to remove legacy passwords from the FOG server.
-
This post is deleted! -
@Wayne-Workman said in New Fog client and security:
@LibraryMark said in New Fog client and security:
It’s just that for my situation, in a public library with public hosts on a network totally separate from our staff net, I am not sure I have a need for bullet-proof security there.
You’re public users are not a security risk? And I know you say you have HDD locking software (Centurion SmartShield or Faronics DeepFreeze probably), but this doesn’t really matter. If there’s a security hole and someone knows how to exploit it, they can exploit it every time they want. Once there’s a compromise, those computers are no longer safe for users to use, no matter how many times they are rebooted and ‘reset’. The legacy client is not secure. The legacy-enabling functionality server-side is also not secure. It is advised that once you have moved to the new fog client, to remove legacy passwords from the FOG server.
We are using Reboot Restore Rx. Are you talking about the fog client still?
