FOG Client Cannot Connect to FOG Server
-
Server: V1.5.0 RC9
OS: CentOS 7Client: 0.11.12
Client OS: Windows 10 B1703Description:
Build all new FOG installation (Main and storage nodes). I have the location plugin installed (don’t think that matters). Moved images from a test/lab system to this new system. Images have FOGService installed from Lab system.
Deploying machines from the new FOG server, all machines boot up and work, but the fog.log file on each deployed machine has this text:
9/26/2017 1:09 PM Data::RSA FOG Server CA cert found
9/26/2017 1:09 PM Data::RSA ERROR: Certificate validation failed
9/26/2017 1:09 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid)
9/26/2017 1:09 PM Middleware::Authentication ERROR: Could not authenticate
9/26/2017 1:09 PM Middleware::Authentication ERROR: Certificate is not from FOG CAChecking the certs on both of the FOG servers:
https://fogserver/fog/management/other/ssl/srvpublic.crtI can tell that:
-
The cert on the lab fog server has the DNS domain name in it from the lab.
-
list itemThe cert on the new fog server has localhost.local domain in it.
I don’t have time to set the DNS name on the FOG server and reinstall FOG to generate the proper cert.
How do I make the correct cert now that FOG is already installed?
What LINUX values have to be set to properly create the cert in the future?Thanks,
Jim -
-
@sebastian-roth
@Taspharel
@george1421All of the info provided lent itself to the ultimate solution…
For anyone who wants to create images on one fog server and have them used on a completely separate, unique and different FOG Server, here’s the process I used.
We’ll create an image that has the FOGService on it associated with the first FOG Server (FOGServer1) by running Sysprep with shutdown. We’ll install the second FOG Server (FOGServer2) and acquire the certs from it by installing the FOGService on a PC and associating it with FOGServer2. We’ll edit the uploaded disk by attaching it as a “D:” drive to a PC and create or add to the SetupComplete.cmd file to load the FOGServer2 certs after Sysprep completes.
Here are the steps:
-
Build the image PC with OS, applications, etc. - whatever you want already installed. I subscribe to the notion that a windows image should contain the MS OS CD installed, FOGService Installed and then the rest of the content should come from Snapins. As little as possible should be done by hand because can seldom repeat the process if we have to. For this process, however, it doesn’t matter.
-
Install the FOG Client Service and associate it with the first FOG Server (FOGServer1). As stated above, I use Snapins to deploy content the makes up my images.
-
Run Sysprep with shutdown, then capture the image to the FOG server (FOGServer1).
-
Install the FOG Client Service on a PC associated with the 2nd FOG server (FOGServer2), accepting all defaults.
-
In the FOG folder (C:\Program Files\FOG or c:\Program Files (x86)\FOG) copy files ca.cert.der and fog.ca.cer to external storage
-
Deploy the image from FOGServer1 to a disk (a virtual is vastly perferred) with Shutdown. Do not let the machine attached to the disk boot.
-
Mount the disk to another computer as an additional disk (as in D Drive).
-
Using this other computer, edit the contents of the sysprep’d drive (D Drive)
-
Copy ca.cert.der and fog.ca.cer to the “D:\windows\setup\scripts” folder
-
Create SetupComplete.CMD file in “D:\windows\setup\scripts”, or add to the existing file
-
Add these lines for a 32 bit OS:
copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles%\FOG\ca.cert.der”
copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles%\FOG\fog.ca.cer”
certutil -delstore Root “FOG Server CA”
certutil -delstore Root “FOG Project”
certutil -addstore Root “%programfiles%\FOG\ca.cert.der”
certutil -addstore Root “%programfiles%\FOG\fog.ca.cer” -
Add these lines for a 64 bit OS:
copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles(x86)%\FOG\ca.cert.der”
copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles(x86)%\FOG\fog.ca.cer”
certutil -delstore Root “FOG Server CA”
certutil -delstore Root “FOG Project”
certutil -addstore Root “%programfiles(x86)%\FOG\ca.cert.der”
certutil -addstore Root “%programfiles(x86)%\FOG\fog.ca.cer” -
Dismount the additional disk, connect it to a machine associated with FOGServer2 as the system drive (C:), and capture the image to FOGServer2.
-
When Deploying the image to additional machines from FOGServer2, the machine will associate with the FOG Server2 but will not join the domain or run Snapins until you Reset Encryption for the new host (button found at the top of the “General” tab for the host).
-
One caveat - I use a DNS alias for all FOG Servers (creatively, I chose fogserver) so I don’t have to worry about FOG server name differences. If your FOGServer1 and FOGServer2 are in the same DNS zones, this won’t work, so if you have different FOG server names, you can save the setting,json file from the \program files\FOG folder from a PC associated FOGServer2 or just edit the one with the new FOG server name in it. When you’ve mount the imaged disk as an additional drive, copy the altered settings.json file to the \windows\setup\scripts folder (along with the certs) and add an additional ‘copy’ command to SetupComplete.cmd to get the file into the FOG folder (just like the certs). I haven’t tested this, so hopefully some who knows better will comment.
While the above process is a pain to execute for each image you create, each time you need to associate it with a new FOG Server, I find it far more cost effective than uninstalling the FOG Service and reinstalling it after imaging each PC.
- Please note that I had to place some very odd quotes around some paths because drive letters become emojis d:
…
Jim Graczyk
-
-
We’re changing the /etc/hostname to have the actual FQDN for the FOG server.
-
Updated host name. Now the hostname command returns the proper host name for the server.
Found FOG Wiki article
https://wiki.fogproject.org/wiki/index.php?title=Installation#InstallerRan:
./installfog.sh -Kto recreate the keys
Still have the same name (localhost.localdomain) in the key. Process created new key (new timestamp).
What do we need to change within the system so the cert is recreated with the correct names included??
Jim
-
@jim-graczyk On first sight to me this looks as if the cert/key on the server don’t match those on the client. Sounds like your client is not a fresh install so it probably has it stored already and using this. Take a look at the install dir (C:\Program Files\FOG or something like this) and see if you find a token.dat file. Rename that and reboot the machine. See if that makes a difference. If not, try re-installing the fog-client on one of the machines to see if that helps.
-
Sebastian,
Will do - but from what you say, this means images with the FOG client installed are married to the FOG server on which they’re created??? This seems unbelievable to me… Can we undo the certs altogether?? I need images that are portable between FOG servers w/o having to crack open the PC after each image. Even manually messing with images then reuploading at each FOG server is a difficult limitation to live with.
I get (maybe) marrying a machine to a fog server after it’s imaged. I’m very keen to know how we can prepare the image during sysprep so it’s read to go into any FOG installation.
Back with results in a sec. And what about the cert having the wrong name on it? Anyway to change it?
Jim
-
I renamed token.dat in the FOG folder on the client, then rebooted. I’m still getting the same error and there is no new token.dat file.
Jim
-
@Jim-Graczyk Client re-install?
-
Uninstalling and reinstalling the FOG Client resolved the issue but this an untenable solution. Can anyone tell me if there is anything short of this step I can try?
Ideally, I’d like deploy the image to a disk, mount the disk, then alter the disk content before booting the machine, then re-capture. I can even add a script to the SetupComplete.cmd file that’s post sysprep.
Any ideas?
Jim
-
@Jim-Graczyk Well I am not as much into the client code as Joe is so sorry for the wrong hint on token.dat. Having a bit of a closer look I think you’d need to fiddle with the windows certificate store. Follow this instructions on how to view certs. Make sure to use Certificates (Local Computer) and find
FOG ProjectandFOG Server CAcertificates in the subfolder “Trusted Root Certificate Authorities -> Certificates”. Those are probably still the old ones that were valid before you ran the installer to create new ones. When you run the fog-client installer it does download and inject those certs into the windows certificate store (when it says pinning the server). If you don’t want to re-run the installer you’ll probably need to delete those two certs by hand and import those from the server again. Possibly this can be done by a script but I guess it’s way easier to just re-install the fog-client.Or the other way would be to go back and grab the old CA, certs and keys from a backup from the old server and put those into the right places on the new server. That way all your clients should be happy again.
-
Don’t have a lot of time sorry, but maybe what I had to do will help here?
During my attempts to make my setup work for us, I at some point had to make sure that the correct Certificates are in the windows store.
So in my Setupcomplete.cmd I have:
certutil -addstore “Root” “C:\Windows\System32\Sysprep\fog.ca.cer”
certutil -addstore “Root” “C:\Windows\System32\Sysprep\ca.cert.der”The cert files I copy to the folders above in my golden image and they are imported into windows then. Possibly the location could be on a network share as well - or automated via FOGs scripting options if setupcomplete isnt able to access them?
This way you would have to only change the certificate files in one location and they would be pulled by either your setupcomplete script or the fog post-install scripting after imaging.
Sorry if I missed the point though, totally possible
Moderator edit: #wiki worthy
-
@taspharel Or of course you use Group Policies and add the correct Certificates there?
-
@taspharel I don’t think “Root” is the proper store, shouldn’t it be “Trusted Root” If that is where the certificates are suppose to go. Only guessing since I didn’t take the time to verify before posting.
-
@Taspharel Nice, thanks for that. I am not a windows guy and didn’t know about
certutil. Sounds like this is just what we were looking for. Though I think that you might want to remove the old ones before adding the new ones or you might end up with a real mess in the store. -
@sebastian-roth
@Taspharel
@george1421All of the info provided lent itself to the ultimate solution…
For anyone who wants to create images on one fog server and have them used on a completely separate, unique and different FOG Server, here’s the process I used.
We’ll create an image that has the FOGService on it associated with the first FOG Server (FOGServer1) by running Sysprep with shutdown. We’ll install the second FOG Server (FOGServer2) and acquire the certs from it by installing the FOGService on a PC and associating it with FOGServer2. We’ll edit the uploaded disk by attaching it as a “D:” drive to a PC and create or add to the SetupComplete.cmd file to load the FOGServer2 certs after Sysprep completes.
Here are the steps:
-
Build the image PC with OS, applications, etc. - whatever you want already installed. I subscribe to the notion that a windows image should contain the MS OS CD installed, FOGService Installed and then the rest of the content should come from Snapins. As little as possible should be done by hand because can seldom repeat the process if we have to. For this process, however, it doesn’t matter.
-
Install the FOG Client Service and associate it with the first FOG Server (FOGServer1). As stated above, I use Snapins to deploy content the makes up my images.
-
Run Sysprep with shutdown, then capture the image to the FOG server (FOGServer1).
-
Install the FOG Client Service on a PC associated with the 2nd FOG server (FOGServer2), accepting all defaults.
-
In the FOG folder (C:\Program Files\FOG or c:\Program Files (x86)\FOG) copy files ca.cert.der and fog.ca.cer to external storage
-
Deploy the image from FOGServer1 to a disk (a virtual is vastly perferred) with Shutdown. Do not let the machine attached to the disk boot.
-
Mount the disk to another computer as an additional disk (as in D Drive).
-
Using this other computer, edit the contents of the sysprep’d drive (D Drive)
-
Copy ca.cert.der and fog.ca.cer to the “D:\windows\setup\scripts” folder
-
Create SetupComplete.CMD file in “D:\windows\setup\scripts”, or add to the existing file
-
Add these lines for a 32 bit OS:
copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles%\FOG\ca.cert.der”
copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles%\FOG\fog.ca.cer”
certutil -delstore Root “FOG Server CA”
certutil -delstore Root “FOG Project”
certutil -addstore Root “%programfiles%\FOG\ca.cert.der”
certutil -addstore Root “%programfiles%\FOG\fog.ca.cer” -
Add these lines for a 64 bit OS:
copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles(x86)%\FOG\ca.cert.der”
copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles(x86)%\FOG\fog.ca.cer”
certutil -delstore Root “FOG Server CA”
certutil -delstore Root “FOG Project”
certutil -addstore Root “%programfiles(x86)%\FOG\ca.cert.der”
certutil -addstore Root “%programfiles(x86)%\FOG\fog.ca.cer” -
Dismount the additional disk, connect it to a machine associated with FOGServer2 as the system drive (C:), and capture the image to FOGServer2.
-
When Deploying the image to additional machines from FOGServer2, the machine will associate with the FOG Server2 but will not join the domain or run Snapins until you Reset Encryption for the new host (button found at the top of the “General” tab for the host).
-
One caveat - I use a DNS alias for all FOG Servers (creatively, I chose fogserver) so I don’t have to worry about FOG server name differences. If your FOGServer1 and FOGServer2 are in the same DNS zones, this won’t work, so if you have different FOG server names, you can save the setting,json file from the \program files\FOG folder from a PC associated FOGServer2 or just edit the one with the new FOG server name in it. When you’ve mount the imaged disk as an additional drive, copy the altered settings.json file to the \windows\setup\scripts folder (along with the certs) and add an additional ‘copy’ command to SetupComplete.cmd to get the file into the FOG folder (just like the certs). I haven’t tested this, so hopefully some who knows better will comment.
While the above process is a pain to execute for each image you create, each time you need to associate it with a new FOG Server, I find it far more cost effective than uninstalling the FOG Service and reinstalling it after imaging each PC.
- Please note that I had to place some very odd quotes around some paths because drive letters become emojis d: …
Jim Graczyk
-
-
@Jim-Graczyk Very nice! Thanks for posting.
#wiki worthy for sure!
-
If you want to go fancy - and automate the process further - have a look at the postdownload script, for example here:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/7
The process would probably be along the lines of:
Image the machine -> FOG Postdownloadscript runs before boot -> Harddrive is mounted -> Certs are copied similar to your process above -> Setupcomplete script only has to add the certificates to the certificate store (or possibly the postdownloadscript can be modified to do that too)
All you would need then is to keep the certificate scripts up to date - which FOG probably does by itself after updates etc. - and they would be copied to your host without any further interaction needed.
Any you would save having to mount the harddrive to another machine to copy stuff … seems like its worth it to have a look at?
-
@jim-graczyk said in FOG Client Cannot Connect to FOG Server:
- Build the image PC with OS, applications, etc. - whatever you want already installed. I subscribe to the notion that a windows image should contain the MS OS CD installed, FOGService Installed and then the rest of the content should come from Snapins. As little as possible should be done by hand because can seldom repeat the process if we have to. For this process, however, it doesn’t matter.
On a side note - check out chocolatey(.org) … I make sure that service is installed on all our hosts. Then all I need to do for new programs or updates is make a simple batch-file as snapin for fog that sends the command
choco update all -y
or
choco install xxxy -yto have all programs brought up to date or a new program to be installed silently. And to make sure I add a > C:\Somepath\Choco-log.txt to the command to be able to check on errors etc.
It is even possible to make windows 10 use the chocolatey repository in apt-get without having to install the chocolatey service if you want to keep it even more simple.
-
Thanks for the link and all the info. Postdownload scripts would be the ideal architecturally to place to make these changes. That would eliminate the manual work and allow for proper separation of content between FOG Server . My problems is ignorance of FOG coding and updating methodologies and future plans.
I have altered FOG for my own needs several times before - in the .32 era - only to find my changes overwritten at update. This became a maintenance issue at best and sometimes a total redo due to changes within FOG. Since I don’t know what the FOG Development team’s plans are, or how long-lived any time investment I make altering FOG would be, I decided long ago to minimize my changes to FOG. Also, for me, it’s far easier to debug changes to the Windows OS when they’re made in the Windows OS. To that end, my Snapins are only a 17K .exe that starts a Windows program I deploy to each PC, and all real installation content is accessed via SMB. This allows me to alter very large installations w/o re-uploading to FOG and requires much less work on the PC’s part installing content. So, as long as I have another option outside of FOG, changing the PostDownload process would be the riskier path.
Your post shows me there’s documentation available, but often it’s point in time - as in each post describes how do solve a problem at the time it was posted. It’s often unclear to which version of FOG the doc applies. It’s very hard for us to get a sense of stability and longevity from these posts.
The Project team is made up of fantastically hard working people, so it’s unreasonable to add to their burden by requesting architecture and development plan documentation. I prefer to expect that anything within FOG is subject to change as they see fit daily change to daily change. I’m thinking this has been essential to the team making FOG what it is today. Consequently, I try to put my hooks in after FOG.
Thanks very much for the help you and the rest of the team provided.
Jim
-
