Active directory Join issue

[Wayne Workman]

@anthonyglamis Honestly, fog trunk has drastically greater and wider support for more devices, and newer devices. Including newer style HDDs and newer boot methods.

I won’t lie, there are bugs sometimes, but they are usually minior. You just report them here in the bugs section, say “Hey ABC happens when I do 123, here’s the error and the version I’m on.”

1.2.0, while mostly stable, is really old. It won’t install out of the box on newer Linux OSs, and doesn’t support newer devices, and has basically zero GPT support.

My org has been using FOG Trunk since February 2015. We haven’t looked back.

Just the massive speed improvements alone in FOG Trunk make it worthwhile.

[JJ Fullmer]

@anthonyglamis said:

Arrowhead,

I am wondering if this is a DNS issue? My host are all “unable to resolve”.

So the unable to resolve thing doesn’t necessarily affect the active directory issue, but it is something of a dns issue. For example, If your dns or perhaps dhcp server assigns hostnames to the computers based on ip address unless you reserve it in the server (It’s an issue I had at my last job where the university had a custom dhcp server that set the hostname based on the ip address unless you manually reserved by mac address, it was annoying). My point is they could relate, but I’ve seen the active directory join work even when the host isn’t showing as green/up in fog. So I would make sure everything else is right first before seeing if this is the cause. For example, does wake on lan work, because that only works if the host is down, because well it has to wake it from being off. Point is the ad join functionality doesn’t depend on the gui host up/down function in my experience.

Are you also setting the hosts to join the active directory in the gui, or are you doing it in the pxe imaging menu at the computer. Your configuration looks correct for the joining default settings. So as long as that user can join a computer to the domain and the hostname doesn’t already exist on the domain it should work. Just want to make sure you’re clicking the checkbox to tell the host to join the domain.

Also, is the latest fog client/service installed on the computer’s in question?
Also once that box is checked it typically just joins the domain right then restart and all. And if someone takes it off the domain it will just join right back again.

Hope that helps in some way

[anthonyglamis]

Well one step forward and two steps back. I used the Git option to update to Trunk via this website
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk#wget

I do not know if has not been updated but I am not on version 1.3.0 for starters. The version is 6032. Everything seamlessly migrated over, however after trying 2 image deployments on Lenovo E431 models Fog loads but errors with “Image Store Corrupt” Unable to locate MBR (restore partition table and bootloaders)

Ha and now both will not boot via the HDD

I downloaded 1.3.0 and it goes through the motions of installing but I am on 6032 still after several restarts. Thoughts?

[anthonyglamis]

@Arrowhead I have since attempted to migrate to the latest version of fog however I seem to be having issues. I am looking for the latest version now.

Upgrade was a success, version is 6038

[JJ Fullmer]

@anthonyglamis 6038 is the latest version. That’s the git/svn revision number. It won’t say 1.3.0 until that version is officially released, so don’t worry about that.

For the image store corrupt error, did that go away after upgrading from 6032→6038?
If not check that image folder on the fog server with

ls /images/imageName 

and make sure there’s a d1.mbr or something of that sort.
Also make sure the permissions are correct on the image store

sudo chmod -R 775 /images

also what does /etc/exports say?

cat /etc/exports

[anthonyglamis]

The error did not go away, and my laptops will not boot via the HDD any longer. I deleted the image I had on the fog server and am uploading another image. I will reply with the results.

[Tom Elliott]

@anthonyglamis I don’t know what reimaging would do to get active directory working. With that said I really wish you hadn’t have deleted the image. I’ve been working to make the scripts that do the work of imaging quite a lot lately. While some of those changes likely caused the problem you were having, it would have been better to keep the “bad” image and upload a new image. This would’ve at least had you do both things and given a point that i can look at. But that is now gone

Of course I can still help but it would’ve been nice to fix the original problem you had. Only if you’re having issues with uploading would I say to delete the image, especially if you’re running trunk. I am very frequent on the forums and most often fix issues as they come up here.

[anthonyglamis]

With Fog 6038 in the management console, Fog Configuration>Fog Settings> Active Directory I see that the plain text password gets automatically encrypted. Is Fogcrypt obsolete? It is still available via download @x.x.x.x/fog/client
Also I noticed in Group Management>Active Directory, as well as Host Management>Active Directory the auto generated encryption hashes are different. Will that be an issue when it comes time to attempt to auto join to AD?

[anthonyglamis]

@Tom-Elliott
AHHHHHHHH!!! You are so right, what was I thinking, I apologize. I will update the status after this image is complete. Maybe I can replicate the error? LOL hopefully not in my case. And yes I have been reading these forums for weeks now and you are basically on almost every Fog post Thanks for chiming in.

[JJ Fullmer]

@anthonyglamis Fogcrypt is essentially obsolete, yes. You can still put the fogcrypt output into the legacy input but I find the new auto-encrypt to work better. But yes I’m pretty sure that the fogcrypt tool is still there

I hadn’t noticed that the hashes were different before, so I checked mine and they are different. I haven’t had any problems though, so I would say it shouldn’t be an issue.

[JJ Fullmer]

@anthonyglamis So what is the current status? Did the new image upload and download successfully? Is AD working like magic with the new version?

[anthonyglamis]

@Arrowhead-IT @Tom-Elliott

OK image upload completed, I attempted to deploy to another Lenovo E431 and same error. I looked in the /images directory and sure enough there is no d1.mbr in my Lenovo E431 directory. I am showing the other 2 images I captured which are a Dell 3450, and a Lenovo E430 and they both have the d1.mbr file.

Not sure if this helps but when creating the image in Image Management I selected Multiple Image Partition #2 and in Partition I selected #1

I created those images in the previous fog version so is this a bug or am I not capturing the image correctly?
Also I deleted those images (Dell3450, LenovoE430) however they are still on my linux box, can I get those back into the fog server?

[Tom Elliott]

@anthonyglamis Multiple image partition should be fine, but the “Partition” selection I’m guessing you’re wanting “All”. I don’t know though.

[anthonyglamis]

@Tom-Elliott Any idea why the d1.mbr file is not being captured in the process?

[Tom Elliott]

@anthonyglamis I need to look further, but I’m pretty sure we don’t need the mbr for specific partitions. Meaning, if you tell it to use only partition 1, it doesn’t need the mbr because it’s only using one partition that is assumed (I’m not sure I didn’t create that particular feature) to already be created on the client receiving the image.

If you can, please retry the upload but use “Partition All” or whatever the setting is. I believe you will see the d1.mbr file for that case. If not, let me know and maybe we can run a debug task to try figuring out what exactly the problem is. While I am editing the scripts, I am doing so mostly blind. I do attempt to test all the elements as I can, but i’m far from perfect.

[JJ Fullmer]

@anthonyglamis said:

I created those images in the previous fog version so is this a bug or am I not capturing the image correctly?
Also I deleted those images (Dell3450, LenovoE430) however they are still on my linux box, can I get those back into the fog server?

If they are still in the /images folder then yes. If they are in a different machine, still yes, just transfer the files to the new fog server /images folder.

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

[anthonyglamis]

@Arrowhead-IT Thanks for the input. That does make sense. Hopefully I can get those back. It will save me some time.

@Tom-Elliott I am attempting to capture another image. Same model LenovoE431. I will post the output.

[Wayne Workman]

@Arrowhead-IT said:

I hadn’t noticed that the hashes were different before, so I checked mine and they are different.

This is by design. https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Security_design

[Wayne Workman]

@Arrowhead-IT said:

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

People always mess that up.

[Tom Elliott]

@Arrowhead-IT To add on, if you don’t mind.

Particularly pertaining to the different hashes, this is intentional.

The intent is to make it that much harder for somebody to see/guess your password. The FOG System in whole does the encryption/decryption when and as needed.

For even more security, with the new client at least, any time a client checks in the hash changes too. This is to further obfuscate possibly breach of your AD Password.