New Fog client and security
-
@LibraryMark It appears to be working fine now.
-
@Wayne-Workman said in New Fog client and security:
@LibraryMark It appears to be working fine now.
Maybe It behaves differently than the old client? In the past, if I change the hostname to something incorrect, it will correct it in short order. That does not seem to happen now.
The VM is up and running, the mac address is correct in FOG, and yet I get a “no such device or address” next to the host in the “all hosts” list. All the other hosts are green and say “success”.
-
A-ha! I just now manually rebooted, the host name did indeed change. There is now a token.dat file. That part of it works. How about that. So the only thing “busted” right now is having it force the change.
I have FOG_ENFORCE_HOST_CHANGES checked. Is there somewhere else this needs to be changed? Looks like I need FOG_TASK_FORCE_REBOOT too? I will try that.
-
@LibraryMark It is the
Make changes even when users are logged on?setting. It is per-host / group. You can find it by selecting your host/group, and going to Active Directory. -
@Joe-Schmitt said in New Fog client and security:
@LibraryMark It is the
Make changes even when users are logged on?setting. It is per-host / group. You can find it by selecting your host/group, and going to Active Directory.BINGO! That was it. It did it all by itself. Wow - what an ordeal. This is going to take some getting used to.
Thanks to all who contributed to this. Now - can anyone tell me what I did wrong in the first place?
-
Since I don’t know everything about your setup I can only speculate. My guess is that at some point you may have tried reinstalling the client on the problematic host. It would cause an issue because:
- the original installation successfully authenticated and set the token.
- on uninstalling / reinstallation the token is deleted from the computer, but the server still has it.
- on installation the client no longer has the old token, but the server is expecting it. Thus causing authentication issues.
-
@Joe-Schmitt - Ok, sounds about like what I did. At least now I have some things to try if it happens again.
Thanks!
-
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.
-
@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?
