Posts made by ITSolutions

@rhekkers No problem, definitely stick with 14.04, there have been problems reported with 16.04 and some of the packages FOG installs.

@rhekkers Welcome to the FOG community, Just for future it is best that when you post let us know what OS FOG is on such as Ubuntu, CentOS, Debian, etc. Also the version of FOG, usually found in the cloud on the webUI, and if it has anything to do with the client the version of Windows you are using.

You say you tried upgrading to trunk, is this from 1.2? For trunk it is a good idea to do a fresh install and not upgrade from 1.2 as it has changed quite a bit

Have you tried to Reset Encryption Data on the host? Is this on all hosts, or just one?

@Junkhacker If I understand him correctly, the way they stage the machines is by creating a host entry in the DB with the Serial number as the Hostname. With a custom iPXE script the machine PXE boots reads the serial number, finds if there is a host with that serial number and then does the imaging. This can be useful in the sense that they know the serial and not the MAC. When the machine is plugged in the first time you don’t need need to do anything it just works.

@abos_systemax I would recommend using one of the “other” fields for the serial number because the early host name changer does use the hostnmae field and is not configurable.

@Wayne-Workman I am not in the business to hack FOG either. But as I work in healthcare and we are a small shop one of my many hats is security, with PHI concerns I think about all possible attack surfaces. We have regular audits of our security and have to justify any thing that is of questionable nature. Right now I am working on closing up a few other areas, and I have been thinking of ways to harden software deployment through snapins. Currently we have a separate vlan for FOG and only deploy snapins at time of imaging, then remove the log and use the client just for user tracking and rebooting basically. I will push small single file snapins, if I need to, but nothing that needs to connect to a share due to not having a good way to do so. I love FOG and it works great, just like to include my thoughts on things to help further FOG and keep it as secure as possible along the way.

FOG 2.0 will be a huge advancement again I am sure. Just like 1.3 is truly leaps and bounds better than .3x was. I thought .3x was great, but the issues were definitely addressed. With all software there is always compromises to maintain backwards compatibility for longer than any @Developers would really want to do. In my opinion 1.3 is not just a decimal increment to 1.2, it is much closer to a 2.0 version. But with the true 2.0 they can finally drop support for the legacy client, partimage, and it sounds like move away from PHP. It will definitely be a more robust and modern system.

@Wayne-Workman and @Jbob I fully agree that you should never use plain text passwords, very bad idea! Like I was saying the randomize password script I was thinking about was to work around limitations within FOG at the time, including now for that matter. If the password changed at times the attack window would be minimized. If someone did get the password it would expire during the next change and no longer be good. This also would eliminate the human error of “random” passwords, all random passwords by humans are bad, and mostly predictable over time.

@Jbob That would be great and make it much more secure, if we could hide the snapin details in the log we could negate plaintext passwords all together. But they can still be intercepted using @Wayne-Workman’s example of scanning tasks with MAC’s as the information is still transmitted and read by the client.

The other thought I had in regards to the client being able to support this type of thing is if we could have the option to map a network share through the snapin management. Have a check box for “map network share and use that location”. Then have a configurable share location in the database. The client would map the share, launch the snap in, perform the task, and disconnect when finished.

As for simplicity the hiding details would be easier and less prone to bugs. But a configurable default share with a check box would be a quicker way of reusing a share for multiple snapins over time.

The problem is anything is hack able given the determination of the attacker. The question is how much effort do they need to put in and how much convince do you give up? Not trying to be negative about it, but it is what keeps us in jobs. I enjoy the discussion and glad that we can discuss the ideas/issues/solutions we have to make FOG a better and more secure system.

@michael_f With the new client you are right about it being encrypted in transit. But the snapin’s are transferred to the client and stored in a temp folder under the FOG install location(C:\Program Files(x86)\FOG\tmp) before being executed, this would be the script with the credentials. This could result in the file with the credentials remaining on the client due to various reasons. Such as if the client gets the snapin and is immediately shut down or the service is stopped and the temp files are not removed. Also given that it is saved on the client it is possible to recover the data using file recovery tools even after deletion.

I had come up with the idea of the random password with the old client as it sent in plain text over the network. But as I didn’t have time, I never got around to working on it. Now with the new client it is less likely to get the snapin file, but still very possible. It all depends on the level of security you need/want for the distribution share. If you keep the share locked down, with little or no information other than programs files that can be installed, the risk is very minimal. That is were I am now, doesn’t seem to be worth the effort, security vs convince, there will always be a trade off.

I know I am going way off of the extreme cautious and almost tin-foil hat security concerns, but just thoughts on if you really want to ensure that passwords are truly secure.

@michael_f Yeah, I would use net use in the script. With the new FOG client it is a little more secure since it uses certs. But the script does still have the credentials in it. When I used it I would create a very restricted account, to access the share. Then remove the mapping it at the end of the script. This basically was security by obscurity. But I felt it was better than a fully open share that a simple scan could find and have access to.

An Idea I had but have never had time to explore is creating a bash script to update the password for a share at set or random intervals.

on FOG install samba
Create a user “snapin user” with whatever rights you needed(probably read-only, but could be write if needed)
Create a bash script to randomly create a password and set it for “Snapin user” and also update a net use script in the snapin dir with new password.

Then you would use that script to push out as a snap in and just pass the net use script what file to run on the share. So it would be:
Run with: CMD.exe
Snapin: Net Use script
Arguments: “mapped drive”\Install_programx

It is complicated but if you are really needed the security it can work to avoid having unchanging credentials passed to your PC’s.

@fry_p There are reasons for every way of doing things. Having an open share is a big security risk, and my other example of passing credentials over a snap in is not the best security practice by any means. Just wanted to give the other options that others may find useful. So in terms of security your solution is the best choice.

Model specific is great, quicker deployments since sysprep is not needed and easier to manage in many ways. When I worked for in the schools I wish we could have gotten to that point. But part of our issue was I was at an ISD and we supported the technology that each school choose. With 18 districts you ended up with everything under the sun. Now I am in a small community health care org and we have model specific images for our 10 models we currently have and are narrowing down to even less of a mix.

@fry_p I also like to use shares for the updating issue. If that driver ever needs updated then you need to update the image. On a share you just replace the file. I have a small samba share on my FOG server that has installers and scripts that I use just for deployment. Just need to make sure there is no sensitive info on that share. I have also set up a site where every script that is pushed through FOG maps a drive with a UN/Password in the script before executing the installer. Not the best, but safer than an open share.

This sounds to me like it is a self-extracting exe and that it kicks off an MSI after the exe finishes extracting. So the script waits, but when the exe is done it continues. The problem is that the MSI, the actual driver install is still running. You maybe able to use 7zip and extract the exe and then find the MSI installer and run it silently instead. I have had to do that for many driver installs.

@michael_f gave a good suggestion if you don’t need anything more than the drive itself, but if you need the Nvidia software also then my suggestion maybe a better option. I know some video cards are picky if they don’t have their entire package installed.

What version of FOG are you running?
Is your FOG server connected to the internet?

@Tom-Elliott Is there a list of what variables available to be used in the scripts? I noticed that $osid and ${postdownloadpath} were used in those scripts. Are there any others that are globally available to a post download script?

I see many advantages to FOG and the reason I chose it over the other 2 you listed are as follows:

• It’s free, so no license issues and in a non-profit that is a great thing
• It can run on nearly any hardware, so I have it running on a PC that we were retiring anyway.
• I can select a PC tell it to image and have it WOL anywhere in the building and PXE and image it. I never have to touch it and it is up in less than 20 min.
• I can push software and scripts that may not be easily pushed via GPO
• I can build in other utilities into the PXE menu easily for troubleshooting
• I have a rudimentary inventory system
• I feel that I get better support than some of the paid solutions, and comparing to clonevilla or WDS definitely better support in the community.

Disadvantages in my personal opinion are few:

• Need to have Linux knowledge(although having Linux knowledge is a advantage in the industry)
  The other disadvantages I used to see, when I first found FOG in the .3x days have been corrected/added. I would like to see what others feel are disadvantages.

Hopefully that helps you and glad you had the ability to learn and see what FOG is capable of.

@Jbob
Setting the “runwith” to cmd.exe did work to run it. Thanks for the help.

That makes sense, but why did it run the first time and not the second time then? Both times it was a batch file, with no “runwith” specified. Obviously it did not run correctly the first time, but it didn’t give an error. I know I run bat scripts quite often with FOG and don’t set the “runwith” argument. I guess I am going to definitely start adding it in as it can cause issues at times.

@Jbob
0_1461791355997_fog.log

I have attached a condensed log with the snapin client area, 2 different spots I found when I started looking again. So I just noticed it was when I changed the file name. It looks like the underscore is throwing an issue. I was able to repeat the error by changing the name back and forth.

The script still is not working correctly on Win 10 for importing wireless profiles, but it is no longer giving the error. Now it just won’t import if run as a snapin, but will if manually run. Not sure if that is something you can assist with or if that is just a Win 10 stupidity issue.

What are you running FOG on(ubuntu, Debian, CentOS)?
What OS are you deploying(Win 7, 10)?
r5323, is that the cloud number? If so than you should update to the latest, there have been lots of bug fixes since then.

@Omar.rodriguez You can try this link for modify a Office 2013 install.
https://technet.microsoft.com/en-us/library/dd630736.aspx#BKMK_UseOCTSilentInstallOpt

as for the link you provided that is specific to using Dell KACE deployment/management.

FOG 7188
Client 0.9.12
Ubuntu 14.04
Windows 10

First starting off with saying that I am in the process of testing windows 10 and learning about building an image with win 10, not as easy as it used to be.

I am having an issue with a snapin, it is our wireless profile import, a simple cmd script that runs the netsh wlan add profile command to bring in our wireless profiles. It will work on Win 7 as a snap in. It will run on Win 10 if I run it manually, but when I run it as a snapin I get the following from the FOG client.

SnapinClient ERROR: Could Not start snapin
SnapinClient ERROR: The Specified executable is not a valid application for this OS platform.

Any insight as to why it is not allowing it to run would be much appreciated.