Posts made by mrayzies

Given my discovery today that MAK keys are also getting activated and burned, not just OEM keys (https://forums.fogproject.org/topic/6365/order-of-operations-product-key-activation-client-product-key-updater/9). Would it be possible to change the code such that it only attempts to activate if the key matches what is set in the web interface and if it hasn’t successfully activated before?

---

To expand upon my above request, I think you could do/use the following:

• check if the partial local key (slmgr.vbs /dli) matches some part of the key listed in the database/FOG web interface
• if false, update local key to match web interface (and then either rebooting or restarting the checks to verify it was set properly)
• check if the local key has already been activated; slmgr.vbs /dli, check for “License Status: Licensed” – if it reads “License Status: Notification”, then it has not successfully activated (i.e. it’s prompting the user to activate)
• if it has not yet been activated, try to activate

Today I was imaging another box and it failed activation. I used “slmgr.vbs /dli” to determine what it was using and found that it was using the MAK key. This command also showed that the MAK key had expired.

Thus, it seems that FOG client will actually activate the MAK key.

I am unsure why I saw the “invalid key” once, unless there were additional characters in the web interface (beyond the key and the 3 bad messed up characters).

@Jbob - since I do not want to burn out more MAK keys, would it be possible to get a generic key?

Using FOG build 5688 and FOG client v0.9.9.

TL;DR – Fog seems to repeatedly activate whatever key is associated with the host, even if it already has, ultimately burning the keys.

Details:
Been imaging a few test machines for a few days now, one machine has been imaged maybe 4 times, the others, only twice. Each machine completes the imaging process fine; however, after imaging, they no longer activate their keys.

At every logon, the user is told that Windows needs to be activated (accompanied with the “You may be a victim of software counterfeiting” message) and if you try to activate it online, Windows refuses to activate the key.

FOG client in this state continues to log this message during this period “XX/XX/XXXX XX:XX AM/PM HostnameChanger Activing host with product key” and looking at the code (https://github.com/FOGProject/fog-client/blob/0.9.9/Modules/HostnameChanger/HostnameChanger.cs), it seems like the hostname changer module is always activating the key. This repeated activation is likely what is burning these keys and making them worthless.

I am imaging a fresh host to test this - I will image it, let it sit for several hours, maybe a day, and then try to reimage and see if it can activate.

In the old legacy client, we had a script that activated the clients and in that script, we checked before we attempted to activate the windows key. The check used “slmgr.vbs /dli” to compare the current key to what the key ought to have been and activated only if the two differed.

@Wayne-Workman
You don’t sysprep? I’d be interested to hear more about your setup – I might be missing something, but sysprep with generalize is the only way I know of to get a generic windows image that will be usable on different hardware sets.

@Jbob
Thanks for the offer of the generic keys, but it looks like it may not be necessary. We left the MAK key in the image and for one host, did not input the OEM key in the host information in FOG; when the hostname changer tried to activate the key, it bailed out with an “invalid key” error. While the format of the MAK key is identical (as far as I can tell) to that of an OEM key, I’m assuming the client made a request to the FOG server, got back an empty string, said that was invalid and did not try an activation. My case appears to be covered.

The unattend.xml is the only way (I know of) to get through all the post-imaging/pre-windows screens, like the “enter activation key”. So if you want the whole imaging process to be automated (i.e. the first time you walk to the box, it is 100% done), I believe you do need it. If you don’t mind going and hitting enter a few times, then I guess you would not need the unattend.xml.

@Wayne-Workman

I think I was unclear – the key that we associate with hosts in FOG matches the specific OEM sticker on that specific box (i.e. we are not using the same OEM key on duplicate boxes).

The MAK (multiple activation) key though is the same – and that’s the key that is in the unattend.xml/image by default.

If we could avoid sticking any key in the unattend.xml, that would be great, but I tried both the classic “* instead of product key” as well as setting “skip auto activation to true”, but neither worked. Additionally, even if those did work, I think Microsoft doesn’t allow that unless it’s used with a KMS?

I certainly could be wrong though and any documentation stating how it actually works would be great (every time I’ve looked, I’ve found no Microsoft documentation that clearly states whether we are in the right or wrong).

Just hoping to get a little bit of clarification here.

We have a MAK key that is in our image’s unattend.xml . We also have OEM product keys set in the FOG web interface. The FOG Clients do successfully pull this product key information and activate with the OEM key. However, before they client pulls the OEM key, does it activate with the MAK key?

To my understanding, MAK keys must be used in the imaging process (due to MS volume licensing agreement), but they are pricy and have a limited number of activations; therefore, it would save us in the long run if the client grabbed the OEM key from the fog server and updated with that one (and never with the MAK key). Is that what the client does? Are there any caveats to that process? Are there times when the MAK key would be used, like if the client was running but couldn’t contact the fog server?

To sum up for anyone who stumble across this post (though sadly the title may lead many people away):

There was a bug in the FOG client service and jumping to this commit seemed to fix it: 4adc2c2c02a19edbc8f8b6d7db63cad9ad2572fb (special thanks to @Jbob and @tom-elliott)

@Jbob

Ahhhh okay, now I believe I am understanding the situation better.

If it’s not too much of a sin to hijack and redirect the thread now, I would really appreciate help on figuring out what’s gone wrong with my client (since now I want to use the new client if I can).

As I initially posted, I am getting invalid security token errors in the fog log on the client. Like many of the links suggested, I tried to reset the encryption values for my client, but that has done nothing.

The log (which repeats this endlessly):

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 12/9/2015 2:09 PM Client-Info Version: 0.9.9
 12/9/2015 2:09 PM Middleware::Communication URL: http://fog/fog/management/other/ssl/srvpublic.crt
 12/9/2015 2:09 PM Middleware::Authentication ERROR: Could not get security token
 12/9/2015 2:09 PM Middleware::Authentication ERROR: Could not find file 'C:\Windows\system32\token.dat'.
 12/9/2015 2:09 PM Data::RSA FOG Server CA cert found
 12/9/2015 2:09 PM Middleware::Authentication Cert OK
 12/9/2015 2:09 PM Middleware::Communication POST URL: http://fog/fog/management/index.php?sub=authorize
 12/9/2015 2:09 PM Middleware::Communication Response: Invalid security token
 12/9/2015 2:09 PM Service Sleeping for 120 seconds

If I manually nagivate to the authorize URL, the webpage reads only:

#!im

Even though I have reset the encryption data, the database is pretty much blank for that host:

*************************** 1. row ***************************
          hostID: 1
        hostName: hostname
        hostDesc: 
          hostIP: 
       hostImage: 1
    hostBuilding: 0
  hostCreateDate: 2015-12-08 15:00:57
  hostLastDeploy: 0000-00-00 00:00:00
    hostCreateBy: fog
       hostUseAD: 0
    hostADDomain: 
        hostADOU: 
      hostADUser: 
      hostADPass: 
hostADPassLegacy: 
  hostProductKey: 
hostPrinterLevel: 
  hostKernelArgs: 
      hostKernel: 
      hostDevice: 
     hostPending: 
      hostPubKey: 
    hostSecToken: 
     hostSecTime: 0000-00-00 00:00:00
    hostPingCode: 
    hostExitBios: sanboot
     hostExitEfi: sanboot

@tom-elliott

The client has a “FOG Project” and “FOG Server CA” certificate – if I’m understanding you correctly, the “FOG Server CA” certificate is generated by the installation script for secure communication between the server and clients and the “FOG Project” certificate is for this project to sign the code, correct? Some follow up questions to that:

1. these CAs are installed by the FOG client service, correct?
2. is how would the client actually use the “FOG Project” certificate to verify the code, since the code runs on the server and isn’t directly accessible by the client?
3. if this is all done for secure communication between client and server, then why in the fog log do I see it attempting to communicate over insecure HTTP? Is this feature just not ready yet?

@Wayne-Workman @Jbob

Thanks for clarifying what you (and the industry) do differently and why those other issues don’t pertain to this situation, I appreciate the knowledge.

While working on setting up FOG from the dev git branch (our current production FOG server is version .32 and can’t support our new hardware, requiring an upgrade), I noted that there was now a new FOG client service. When setting up my image for upload, I tried out the new FOG client service.

I’m still having issues getting the client service to run (I’m plagued by invalid security tokens that resetting the encryption data won’t fix: https://forums.fogproject.org/topic/5088/could-not-get-security-token-token-dat/3 https://forums.fogproject.org/topic/6130/certificate-issues-since-moving-fog-from-ubuntu-to-fedora/10 https://forums.fogproject.org/topic/5259/hostnamechanger/4); however, while looking through those links I realized that the new FOG client service installs a CA into client machines.

Am I missing something, or isn’t this just as bad as things like SuperFish, Dell or ESET?
http://fortune.com/2015/11/23/dell-laptop-security-problem/
https://www.reddit.com/r/technology/comments/3twmfv/dell_ships_laptops_with_rogue_root_ca_exactly/
http://www.zdnet.com/article/lenovos-superfish-its-worse-than-we-thought/
https://device5.co.uk/blog/do-not-use-eset-ssl-protocol-filtering.html

What is the motivation to shift to this new style of client service? Is there some other flaw with the legacy client service that makes this model that much better? And if we must move to the new client service model, could FOG be modified so that we could provide our own certificates and rely on existing CAs instead of making one specifically for FOG?