Finally found out why I couldn’t auth over 636, I needed to add my domain’s CA cert to the FOG server’s root cert store. Once I did that I can now use my AD creds over 636 on the web UI and iPXE menu items.

@AUTH-IT-Center Doesn’t work for me. When I try to log into the web ui it just bring me back to empty login. I ran a packet capture while trying to log in and it looks like the ciphers keep changing. Do I need to have a cert that is trusted by my domain’s root CA in the FOG’s root store?

BTW the screenshot at the bottom of that thread you linked shows “Use LDAP SSL” but I do not have that option.

I read that the LDAP plugin does not currently support 636 and certificate authentication but that article was from 2017. Have there been any updates to this? I prefer using LDAP to authenticate for imaging and management but the credentials are being sent in clear-text. I can always go back to disabling LDAP and setting up local users for all the techs and admins. Just wondering.

@george1421 Thanks! I wonder if a chat bot could help with reading through what worked and make a tutorial.

@george1421 I’ve been reading through it but it all looks like a conversation/experimentation/testing more than a tutorial on how to get it working in FOG. I saw a link from that thread to getting NFSv4 set up on Linux but to get it to work in FOG is the key I need. Was there a specific post or posts that show how exactly you got it working?

I didn’t want to necro the “Feature Request NFSv4…” post. Has anyone successfully got NFSv4 to work properly with capturing and deployment?

@Tom-Elliott said in Hide/Secure FOG Client download page:

Private key is built to the client at install time. The Public server ca cert is pulled at install time

This is what I was unclear about. I thought the installer already had FOG’s private key. So each client gets its own private key?

I noticed the page/url where you can download the FOG client isn’t locked behind a login/auth so in case anyone is looking to lock it you can add these lines to /etc/apache2/apache2.conf:

# Restrict access to FOG Client
<Location "/fog/client/download.php">
    Require ip <*ip or subnet/mask*>
    Require all denied
</Location>

# Hide Server info
ServerTokens Prod
ServerSignature Off

Restart apache2 service after making changes to apache2.conf

What this will do is restrict access to the FOG Client downloads to specific IP or subnet. I have mine restricted to my lab/imaging network. I don’t think it is a good idea to have this download available to all production network users. I’m not 100% sure (devs please correct me) but I believe the FOG Client has the private key embedded in order to connect to the FOG server via HTTPS. I wouldn’t want that private key extracted from the client installer.

Using Access Controls I use the Technician group to restrict the FOG Web UI down to bare essentials for field techs to deploy and capture images. How can I hide a Host group from the Technician user group?

@george1421 I see. So a basic script like (I’m paraphrasing the commands here) “get mac get userID get IP > log.txt” but from there it would have to write to the FOG’s reporting system right?

Currently we can see which user deploys an image to registered hosts but not to unregistered hosts. Why is that? Shouldn’t there be a way to record that an image gets deployed to an unreg’d host? At the very least a MAC address would be helpful. I use LDAP in my environment for FOG auth so theoretically I would be able to see which user deployed an image to this MAC. If an IP address can be reported that would be even better.

Bumping this topic. I too see the issue. I only see imaging events for registered hosts. I have a lot of field techs imaging unregistered hosts and need to have these events logged.

I had to make a correction. I meant to say pre-1Gbit internet not 10Gbit internet. We have 10G backbones (intranet) but not to the internet.

@pauleb In our environment, pre-365 and pre-1G internet, we would use deployment tools to deploy Office from our local repositories using scripts and XMLs. For licensing we used KMS. Now with 365, all licensing is handled on the cloud, and we can install Office apps via internet. The OfficeSetup.exe file has no licensing embedded in it. It is simply a thin-installer that downloads the apps from the internet and installs them. Once complete, when the app starts for the first time it will ask for authentication to activate.

@pauleb When a 365 user logs into portal.office365.com and then goes to my account>install apps, they can download the Office installer, officesetup.exe. This is an online installer for Office.

I simply dropped the OfficeSetup.exe into the snapin and left everything else as is. It will install office or update Office if it is already installed.

I would like to know if it is possible to restrict this page of the FOG server web UI to certain subnets as I don’t want it available everywhere
https://<fogserverip>//fog/management/index.php?node=client

Also these pages
https://<fogserverip>/fog/client/*

@Tom-Elliott Thank you for that! I believe this is the setting “CLIENT HOSTREGISTER ENABLED” that should be disabled:

Not sure if what I’m seeing is due to the FOG client, but lately since I’ve been installing the FOG Client on my VMs, I’ve been seeing more and more pending reg hosts. I only register hosts that need be captured, in my case all of the VMs (since they are the golden image factories), and the field techs use physical PCs sometimes to capture. The one thing the pending hosts have in common is they all have the FOG client installed. Is there a way to completely disable auto reg or the pending reg function so that registration only happens via Full Reg and Inv via the FOG pxe menu?

By the way does the FOG Client use unique GUIDs? If a workstation with the FOG client installed gets captured and deployed to other workstations, does the FOG client recreate a new GUID or does it remain the same as it was on the original workstation?

Another thing to consider which I have observed in my environment is network congestion. If you are imaging on your production network, especially if the subnets aren’t segmented, you may experience slower than normal imaging speed. If your FOG server is connected to the network at 1Gbps, keep in mind that if you are trying to image 10 workstations connected at 1Gbps, the server will only be able to send/receive at 1Gbps. The more imaging that happens at once, the slower they will all be. That is why I have been looking into getting my FOG server connected at 10Gbps so that it can handle at least 10x1Gbps connections without slowing down.