@plegrand yes i would wait, i wouldn’t recommend updating your production server.
if you don’t rely on the LDAP plugin then everything else is functioning as it should but i still wouldn’t recommend it in a production environment.
@plegrand yes i would wait, i wouldn’t recommend updating your production server.
if you don’t rely on the LDAP plugin then everything else is functioning as it should but i still wouldn’t recommend it in a production environment.
@Sebastian-Roth Done I haven’t had chance to look into it any further but it’s the initial bind function that fails.
just some initial testing in my usual environment setup (using 1.5.10.5, location, task state & ldap plugin + FOG running in SSL):
only issues so far i’ve come across is with the ldap plugin (confirmed php8.2-ldap installed and php module enabled on bookworm):
Got error 'PHP message: PHP Warning: Undefined property: stdClass::$DN in /var/www/html/fog/lib/plugins/ldap/pages/ldapmanagementpage.class.php on line 114', referer: https://image-server.ad.wmas.nhs.uk/fog/management/index.php?node=ldap
changing line 114 from ‘searchDN’ => $LDAP->DN, to ‘searchDN’ => $LDAP->SearchDN, resolves this warning.
however getting http error 500 with same config that was working on bullseye (php7):
[Mon Jun 19 00:56:58.958186 2023] [proxy_fcgi:error] [pid 319012] [client 192.168.156.14:53122] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: ldap_unbind(): Argument #1 ($ldap) must be of type LDAP\\Connection, null given in /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php:124\nStack trace:\n#0 /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php(124): ldap_unbind()\n#1 /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php(235): LDAP->__call()\n#2 /var/www/html/fog/lib/plugins/ldap/hooks/ldappluginhook.hook.php(126): LDAP->authLDAP()\n#3 /var/www/html/fog/lib/fog/hookmanager.class.php(86): LDAPPluginHook->checkAddUser()\n#4 /var/www/html/fog/lib/fog/user.class.php(139): HookManager->processEvent()\n#5 /var/www/html/fog/lib/fog/user.class.php(226): User->passwordValidate()\n#6 /var/www/html/fog/lib/fog/fogbase.class.php(2469): User->validatePw()\n#7 /var/www/html/fog/lib/pages/processlogin.class.php(151): FOGBase::attemptLogin()\n#8 /var/www/html/fog/management/index.php(31): ProcessLogin->processMainLogin()\n#9 {main}\n thrown in /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php o...', referer: https://image-server/fog/management/index.php
@fry_p for assurance, FOG still works with windows 11 and it also works on hardware devices that are NOT supported by Microsoft, your image will still deploy, complete and be functional on these devices albeit out of support from a Microsoft perspective but if secure boot becomes compulsory for all your devices then yes, you have to consider the challenges in managing your own secureboot PKI for FOG but Windows 11 should not be a reason to consider an alternative.
unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:
follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
including “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”
copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.
then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:
cd /var/www/html/fog/service/ipxe
mv bzImage bzImage-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned
mv bzImage32 bzImage32-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned
mv bzImage41713m bzImage41713m-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned
just remember to re-sign any init/bzimage when upgrading kernel/fog.
so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.
the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.
unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:
follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
including “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”
copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.
then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:
cd /var/www/html/fog/service/ipxe
mv bzImage bzImage-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned
mv bzImage32 bzImage32-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned
mv bzImage41713m bzImage41713m-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned
just remember to re-sign any init/bzimage when upgrading kernel/fog.
so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.
the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.
@ProfDrSir you will also get this behaviour if the permissions and/or ownership on the image share are incorrect. was the error “segmentation fault. possibly due to run of disk storage?”
if so, on server/node you’re capturing the images to
try:
chown -r fogproject.root /images
or
chown -r fog.root /images
dependant on what version of fog you are on.
then re-run capture
@Greg-Plamondon apologies i thought this was part of main code.
save below code in /var/www/html/fog/lib/hooks/removehosteditgen.hook.php
this is just to get you going, change data and template number to the right id that is relevent for what you want to remove and remove/comment out what you don’t want removing. read up about hooks on wiki. if you get stuck i’ll happily assist when i can to meet what you originally asked for etc but it’s worth you having a go yourself to understand how hooks function.
hope this helps
<?php
class removehosteditgen extends Hook {
public $name = 'removehosteditgen';
public $description = 'Remove unused fields in host edit general';
public $author = 'Rowlett';
public $active = true;
public function __construct()
{
parent::__construct();
self::$HookManager
->register(
'HOST_EDIT_GEN',
array(
$this,
'hostData'
)
)
->register(
'SUB_MENULINK_DATA',
array(
$this,
'RemoveSideNotes'
)
)
->register(
'SUB_MENULINK_DATA',
array(
$this,
'RemoveDelete'
)
);
}
public function HostData($arguments) {
if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
unset($arguments['data'][5],$arguments['template'][5]);
unset($arguments['data'][8],$arguments['template'][8]);
unset($arguments['data'][9],$arguments['template'][9]);
unset($arguments['data'][10],$arguments['template'][10]);
unset($arguments['data'][11],$arguments['template'][11]);
}
}
public function RemoveSideNotes($arguments) {
if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
unset($arguments['notes']['Host']);
unset($arguments['notes']['MAC']);
unset($arguments['notes']['Image']);
unset($arguments['notes']['O/S']);
unset($arguments['notes']['Last Deployed']);
unset($arguments['notes']['Primary Group']);
}
}
public function RemoveDelete($arguments) {
if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
if (!in_array(self::$FOGUser->get('type'),array(0))) {
unset($arguments['submenu']['?node=host&sub=membership&id='.$_REQUEST['id']]);
unset($arguments['submenu']['?node=host&sub=delete&id='.$_REQUEST['id']]);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-printers']);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-service']);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-powermanagement']);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-virus-history']);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']);
unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']);
}
}
}
}
Hi all, i have secureboot working with ipxe (FOG) using a self-signed certificate and you do however need to enroll the keys but i have added an .efi program that you can run to automate all this from the pxe boot menu to ease this process.
i’ve been testing it for the last 12 months or so to see if there is any gotchas but none yet and over 80% of our estate have secureboot with ipxe working (7K devices) - only lenovo x1 carbons have been problematic but this appears to be due to poor bios and/or secureboot implementation.
this does mean you have to manage the certificates yourself going forward too as you are essentially taking ownership and provisioning the devices and applying your own PK which means you have to trust 3rd party CAs however the plus side there is no cost involved. i also don’t have assurances how to remotely distribute a renewed certificate when it expires but expiration is 10 years and there is going to be some work needed when microsoft CA expires in 2026.
on first attempt, i hadn’t included microsoft CA so windows os failed to load with untrusted error from secureboot… i loved the irony… i dont trust microsoft either
if anyone is interested i can write up instructions however you have to remember technically this is outside of FOG remit, so support on FOG forums will be extremely limited and unfortunately with 2 jobs i have very little time to spare either.
@Greg-Plamondon you would need to use hooks to achieve this.
look at removehosteditgen.hook.php in hooks folder on webserver
@agray there are muc more uptodate versions of this done by @george1421 collaberating his version and mine which i’d suggest looking over but for just osid replace if statement with this:
case $osid in
5) osn="Win7" ;;
6) osn="Win8" ;;
7) osn="Win8.1" ;;
9) osn="Win10" ;;
esac
i’d split this up - use GPO or at minimum registry to achieve this then snapin to push out relevant xml start menu layout
Registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\Explorer] - 64bit location
“LockedStartLayout”=dword:00000001
“StartLayoutFile”="C:\PATH\TO\START\MENU\LAYOUT\.xml
you can partially lockdown start menu aswell so you give users a standard put they can pin their own stuff too (not allowed to edit what you’ve set)
the snapin could just handle which start menu they get
i.e. Admin-> this startmenu.xml
IT-> this startmenu.xml
just when they reach the location set in registry name it the same so like:
IT-Startmenu.xml copies locally to startmenu.xml
Admin-Startmenu.xml copies locally to startmenu.xml
Hope this makes sense
crontab -e
0 0 * * * echo “FOG is not Dead…”
0 10 * * * echo “FOG is not Dead by the way…”
0 30 * * * echo “did you know…FOG is not Dead”
@george1421 nice one george! i guess at the moment it is a toss up of functionality over “security” - nice work! i’m sure @tom-elliott could give a better insight on the ipxe parameters…
@jdd49 it sure does microsoft monopolizing the process?..NEVER!!!
@george1421 i can get it to boot to grub now but cannot get it to chainload into FOS
i’ve been tasked at getting fog secure boot complaint due to it now being a requirement by internal audit rolls eyes…
microsoft so far have been as useful as a chocolate teapot. no one appears to know the process and their solution is use MDT or SCCM. If i have to hear “why aren’t you using SCCM one more time…” lol
initial cost is not a concern its already been pre-signed off but the process needs to be as minimal as possible i.e. dont need to keep going back to microsoft to get versions resigned and have the ability to sign them ourselves…
anyone else done this in a enterprise environment or am i going to be the guinea pig lol
any of the other devs got any more insight?
Nice one! having to setup additional locations per CIDR is no biggy really as this will automate the selection anyhow! So shouldn’t be too much of a change for people to get their heads around and most setups will work without the need of additional locations and is really the only caveat we’d need to make users aware of.
so all that’s left to do is edit
locationmanagementpage.class.php to include CIDR field and then the changeitems.hook.php storagenode functions are going to need rewriting - that’s probably the best place to include the CIDR enhancement.
nice start wayne