FOG Client Unable to Decrypt AES Error
Ok I have found this and am trying it, https://forums.fogproject.org/topic/11215/snapins-stuck-in-checked-in-and-auto-domain-join-won-t-work/4
Reset the encryption data and rebooted the host. Having checked the fog.log it does appear it could be the issue.
Hopefully this resolves it.
EDIT: Has not resolved it, still see errors being logged in the fog.log file on the host.
here is an excerpt from the log:
------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 6/5/2018 10:22 AM Client-Info Version: 0.11.16 6/5/2018 10:22 AM Client-Info OS: Windows 6/5/2018 10:22 AM Middleware::Authentication Waiting for authentication timeout to pass 6/5/2018 10:24 AM Middleware::Communication Download: http://10.0.0.2/fog/management/other/ssl/srvpublic.crt 6/5/2018 10:24 AM Data::RSA FOG Server CA cert found 6/5/2018 10:24 AM Middleware::Authentication Cert OK 6/5/2018 10:24 AM Middleware::Communication POST URL: http://10.0.0.2/fog/management/index.php?sub=requestClientInfo&authorize&newService 6/5/2018 10:24 AM Data::AES ERROR: Could not decrypt AES 6/5/2018 10:24 AM Data::AES ERROR: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms. 6/5/2018 10:24 AM Middleware::Response ERROR: Could not parse data 6/5/2018 10:24 AM Middleware::Response ERROR: Error reading JObject from JsonReader. Path '', line 0, position 0. 6/5/2018 10:24 AM Middleware::Authentication Authenticated 6/5/2018 10:24 AM Middleware::Authentication ERROR: Could not authenticate 6/5/2018 10:24 AM Middleware::Authentication ERROR: Object reference not set to an instance of an object.
I created a snapin which is a pretty simple batch file. The batch file runs on first login post deployment automatically and doesnt exhibit any issues then.
When I attempt to run it manually however (using single snapin option) it appears to never be run. It shows up under active tasks with a status of “checked in” but never moves beyond this. The other day I let it sit for ~30 minutes with no change before cancelling, rebooting the server and hosts and trying again with the same result.
Not really sure how to troubleshoot this issue, any help would be great. Thanks
@joe-schmitt Providing a remote machine wont be an option for me to help, but any testing you need done I would be happy to do and report back.
If I need to setup any machines on my end for me to test with I can do that as well.
I have a more clear picture of the process you have detailed with the snapin, makes sense. I will make some alterations next week and test it out. Thanks
@Zer0Cool for the SnapinPack. you’d have it run
start.batWould then copy & run
removeclient.***as a separate task. This means
start.batwould exit fairly quickly, and so the client could inform the server the snapin ran successfully. removing it from the FOG task list. I would, however, recommend putting a short sleep delay at the beginning of
removeclient, just to give the client enough time to inform the server before it is uninstalled.
As for PCI/FIPS compliance, I have done some work for that here: (https://github.com/FOGProject/zazzles/commit/90b76038210175a532a5da522b7d61b281d23a99), but last I tested it still had issues. Right now the ticket is targeted to be done on v1.7 of the FOG server, but if you’d like to see it done sooner, you could hopefully assist me. To continue development/testing I’d either need to turn FIPS compliance on in one of my dev VMs or be able to remote into a machine with it enabled. The latter may be quicker. Feel free to PM me if you’d be interested in helping.
@joe-schmitt I think I am following what you are saying here. Are you suggesting running the removeclient.bat after having had the start.bat run? Would I be running the removeclient.bat as part of the snapin/snapin pack or via some alternate method like a windows task or manually?
As of now, the way I have it is that the uninstall is the last line of my snapin/bat and the uninstall line forces a reboot. So it does successfully run the bat/snapin commands prior to the uninstall but you are correct in that I noticed it would not run any command after which makes sense.
The issue with my approach I noticed is that by uninstalling in this fashion it leaves the tasks in the FOG task list as still running long past completion. I can of course go and manually cancel/delete them, and all is fine.
In any case, question for you @Joe-Schmitt , and I know this question is the bane of all developers existence and I by no means want you to feel like this is me putting pressure or demands on you, as I am certainly not…
When might you anticipate that the FOG client is updated for PCI/FIPS compliance?
I ask as I am trying to gauge if its worth putting effort in work arounds to my problem or if I should just wait until the FOG client is updated which will simplify my process greatly and no longer require uninstalling the client post deploy.
For what its worth I tried something similar to your suggestion but not as a snapin pack, just 2 snapins and realized as soon as the first snapin ran and rebooted the GPO was in affect and the second snapin couldnt run due to the FIPS issue. The 2nd snapin was meant to act upon a AD account, but could not because of the GPO. At the same time the commands couldnt be done in the first command as the AD account hadnt been logged into yet, thus the registry and dir’s for that user didnt exist yet. Catch 22. I couldnt figure out a way to have the bat act upon the AD users local registry entries without having first logged in as that user and/or without triggering the FIPS compliance causing the FOG client to not work.
@Zer0Cool snapins act like children processes attached to the client. This means if the client is stopped (via an uninstall), it’ll likely also stop and delete any running snapins. I’d recommend using a SnapinPack. There could be 2 files in it: a
removeclient.[bat/cmd/ps1]. Essentially the
removeclientto another folder, as otherwise it’ll get removed on client uninstall, and then run that script as a new backgrounded process.
So it appears this is currently the issue, as @Tom-Elliott has made me aware. The PCI / FIPS Compliance is being pushed by Group Policy (as part of my AD), so once thats in place it basically renders the FOG client moot. Prior to this it works just fine, assigning the hostname, activating Windows and joining the domain, then running the snapin initially.
Since my snapin deleted the local admin account and reboots, there is no choice but to log in to an AD account for which this policy is enforced.
So under the local account the snapin runs because the FOG client is allowed to connect and authenticate.
What I have decided to do to address this is the following:
- Leave the FOG client in the image and let it change host name, activate Windows and domain join.
- Let the FOG client run my snapin/batch file to delete the local user, force gpupdate and uninstall FOG client, then reboot
- Login as a domain user and manually run a batch file that just deletes the remaining
The end result is the machine is ready to use, I get all the initial benefits of the FOG client but do not have it left on the machine when it cannot operate. Hopefully when the matter is resolved and it can run with this gpo setting I can leave the FOG client installed to make working with the machines easier long term.
I am currently testing my revised snapin to ensure it runs, uninstalling the FOG client and performing its other tasks properly. Looking at the newely booted images now and the snapin may not be 100% as it appears stuck on “please do not shut down until this is complete”.
EDIT: uninstall works, but the next line in the batch file (to reboot) doesnt execute. I think I can resolve this by adding a forced restart to the uninstall command.
@tom-elliott Ah interesting, I hadnt considered that. Ill start to comb through it.
I now have a feeling that disabling PCI compliance may not be an option in my environment however :/
I may have to, for the time being, consider alternatives to the FOG client for the post deployment then.
Ill check out my group policy and evaluate the options.
EDIT: Seems the GPO setting is likely “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” which is set to enabled for me and unfortunately its not an option for me to disable this.
@zer0cool I’m going to assume, based on your script, that gpupdate is setting the PCI Compliance? That’s assuming this is indeed the case.
@tom-elliott Hello Tom, thanks for the reply. I will look into this and see if I am able to disable the PCI Compliance.
I am a bit confused however why its not a problem until after the FOG client has changed the hostname, joined the domain, activated Windows and run my relatively basic batch file (seen below). Just a bit odd that it does work until after deployment is complete:
net user Temp /del rmdir /S /Q C:\Users\Temp CD C:\Windows\System32 echo y | gpupdate /force /wait:0 shutdown /r /t 00
I will remove my snapin from the host and re-image to see if the problem persists if I do not delete the local account as well as your advice.
I’m, by no means an expert, and Joe is currently in the middle of a move, so unable to respond directly. He asked me to post this:
Basically, what I gather based on what he’s told me is that PCI compliance is enabled for Credit Card information security (or something like that.) If you can disable this Compliance, it might help with the problem? (Or what I understand of it anyway).
The post is part of the issues Joe’s currently aware of so I imagine this may be fixed in the mid to near future.
I re-deployed my image to the host so that I could see the log from deployment to when it stops working.
It appears as if the FOG client works just fine during hostname change, Windows activation, joins the domain/reboots and even runs my snapin assigned to the host which deletes the local user, does a gpupdate /force and reboots again. After that point I get the log posted above and it seems the FOG client cannot properly authenticate.
It appears as if it is able to reach the server as it gets the CA cert, but on the line
Middleware::Communication POST URL: http://10.0.0.2/fog/management/index.php?sub=requestClientInfo&authorize&newServiceIt then seems to fail with a message regarding being unable to decrypt AES.
I have tried multiple times doing the encryption reset option in the web gui for the host to no avail.
Not sure what I am missing here, any help would be great. Thanks
This post is deleted!