FOG 1.5.10 - Problem with AD Join.

[gmaurice]

I’m new here, and while I managed to find solutions to all my problems through the (ab)use of AI and long sessions of forum roaming, I’m hit by a new issue, I can’t really get the hang of.

I have a physical workstation used to create the master, lets call it Master-Client.
I have FOG client installed on it and this client reports to a FOG server, lets call it Production-Server.

I have another FOG server (called Staging-Server) used to create the master out of Master-Client.
Then I export the master informations from the Staging-Server and load them on the Production-Server. At the same time I rsync the files from Staging-Server to Production-Server.

So far so good, all that works fine. I can then deploy the master from Production-Server to a bunch of clients. (called Prod-Client01 to 20)

The Prod-Client01 to 20 are the exact same computer as the Master-Client (the MAC addresses are different, but the hardware is strictly the same)

Deploying the Master to them works fine, except that in some case the Join AD fails.
It’s random, I’ll have two clients deployed at the same time that will fail, while a third will join the AD.

The configuration for the Join AD is the same for all the Prod-Clients Join Domain after Deploy, Name/change AD join Force Reboot checked on all at client level)

The only thing I could find is in the c:\fog.log file of the Prod-Client where the AD Join fails :

(DT stands for DATE &TIME)

-------------------------FOG LOG EXTRACT -------------------------------

---

----------Authentication--------------------

DT Client-Info Version: 0.13.0
DT Client-Info OS : Windows
DT Middleware::Authentication Waiting for authetication timeout to pass
DT Middleware::Communication Download: http:/production-server.tools.local/fog/management/other/ssl/srvpublic.crt
DT Middleware::Authentication Cert OK
DT Middleware::Communication POST URL: http://production-server.tools.local/fog/management/index.php?sub=requestClientInfo&authorize&NewService
DT Middleware::Response Invalid security token

-----------------END OF FOG LOG EXTRACT---------------------------------------

This is repeated 5 times (I guess the clients retry 5 times to talk to the server) and then I have the line :

DT Client-Info ERROR: Failed to authenticate, will not run Module Looper

I tried this procedure :

• removing from the FOG database two of the clients that failed through the GUI.
• recreating the two clients tthrough the GUI with their MAC address and all

but it didn’t change anything.

Since I had another issue with the MAC address that made me check I.M.C. and I.M.I. on the Master-Client so that a deployment test on a VM ( (Hyper-V, Deploy from Production-Server) could actually perform the AD Join, I guess it’s also a MAC Address Issue.

Last but not least : I’m running FOG 1.5.10 on Alma Linux 10.1 for the servers

My questions are :

• Is there a workaround to my problem that doesn’t involve making the AD Join manually for all the clients that fails the automatic join ? (that’s what I ended up doing)

• Is there a way to look in the database at all the registered Mac Addresses
  (because my clients all have several MACs and also have Hyper-V defined ones)

• Has anybody else encountered the problem ?
  ( I rumaged in the forum but didn’t see the exact same problem, even if there’s several that looks similar that I have bookmarked to take the time to read thoroughtly. )

[Tom Elliott]

@gmaurice Invalid Security Token is the key indicator here:

Find the host(s) and go to them within the UI and click the button for “Reset Encryption Data” then you may need to restart the machine(s) in question.

[gmaurice]

@Tom-Elliott

I only have that option on one host… On all the other hosts the option does not appear.
And that host is one of the few that didn’t have the problem.

[Tom Elliott]

@gmaurice The host that you provided the log from is most definitely going to have the “Reset Encryption Data” because that token existing in the first place is what produces the “Invalid security token”.

If you’re saying this “same” message is happening on all machines in your fleet, I’m not sure how that is possible and suspect you’re seeing similar but very different messages?