Problem with FOG Service …
-
Hello,
Since the recent update of my fog server (from version 1.5.7 to the latest 1.5.10.1622 and Debian 12.7), my fog service no longer works.
Until now, the FOG service was used to rename my machines, integrate them into my university’s Active Directory, remotely stop/start workstations (when my network’s WOL is working), etc.
Since the update, it’s impossible to do these actions. The service runs well in memory on Windows workstations, but it no longer seems to communicate with the FOG server.
Of course, I also tried with the Fog service of version 1.5.10.1622, but that doesn’t change anything.
Have you ever encountered this kind of problem? and if so, how did you solve it?
Thank you,
Laurent -
Do you get any error message in the FOG.log file in the root of C on a client?
-
the only error message I see is:
--------------------------------HostnameChanger-------------------------------
24/10/2024 13:09:05 Client-Info Client Version: 0.13.0
24/10/2024 13:09:05 Client-Info Client OS: Windows
24/10/2024 13:09:05 Client-Info Server Version: 1.5.10.1622
24/10/2024 13:09:05 Middleware::Response Success
24/10/2024 13:09:05 HostnameChanger Checking Hostname
24/10/2024 13:09:05 HostnameChanger Hostname is correct
24/10/2024 13:09:05 HostnameChanger ERROR: Required domain information is missinghowever, I have correctly entered the Domain name, Domain username and encrypted password (with fogcrypt) in the Domain Password Legacy area.
I use an encrypted password because I don’t want other fog users to see my password in plain text
Thanks,
Laurent -
@Laurent Password legacy is no longer used in 0.13.0 I don’t believe. Please enter your domain password in the non-legacy item. 0.13.0 was NOT ever using the legacy fields. It was because of these versions of the FOG client, that the “legacy” items were even created.
-
@Laurent said in Problem with FOG Service …:
I use an encrypted password because I don’t want other fog users to see my password in plain text
I would recommend using a separate domain admin account rather than any 1 user’s domain account. Partly because of the issue you describe (though that’s not something that can be seen in the web gui) but also so that it’s a password that won’t expire with a user leaving and it’s a password that can be rotated without affecting other services.
Just my 2 cents.
-
@Laurent we’re on FOG 1.6, but I think its the same as 1.5.10. FOG doesn’t let you see the AD password once input, but I’d echo @JJ-Fullmer’s point of using a specific account
-
thanks Tom Elliott for your answer. The fog service I used until now (for fog versions 1.5.7 and 1.5.9) used encrypted passwords, and everything worked perfectly.
the problem is that if I don’t encrypt my password, other fog users will be able to see it, and it’s an administrator account of my domain (Active Directory) !
Is there a way to get around this problem?
-
@sideone
you are absolutely right, we can’t see the password anymore !!! you just have to leave the host and come back in, and the password is hidden!!For me, it was still visible because I hadn’t left the host…
Are you on version 1.6? where can I download it to test? any feedback on this version?
-
@Laurent https://docs.fogproject.org/en/latest/installation/server/install-fog-server/#choosing-a-fog-version
Essentially, instead of checking out the
stablebranch and doing a git pull and running the installer, you check-out theworking-1.6branch, do a git pull and run the installer.It’s still in “beta” but I believe we’re very close to releasing it as the new stable version.
It’s a whole new ui it’s pretty great. Lots of feature and security enhancement in the backend, faster search results in a universal search tool, cool stuff like that.
-
@Laurent The information is stored encrypted in the db + the transfer of information is encrypted between the client and the machine.
The only time the password is clear to any user is when you initially enter it in the field.
-
Top, that’s great news! Congrates !
-
@JJ-Fullmer
In our environment we just use a service account that has delegated rights to create / delete computer objects and domain join, it doesn’t have access to anything else. No need for domain admin in that case. -
@iljared98 this is what we do too.
-
@iljared98 I don’t suppose you’d be willing to share more on this config? What specific rights you gave the service account, did you have to do this whole thing https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 related to this whole thing https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 ?
I’ve previously attempted to create a standard user with such permissions, but I hadn’t tried a service account, that’s a grand idea. I would love to document the creation of a least privilege service account for fog domain operations.
