SOLVED Active directory Join issue

  • Hello, I am new to this forum but have been reading for several weeks. I recently installed Ubuntu 14.04 LTS on a workstation and have installed fog 1.2.0. I can upload images, and download images; however I am having a few issues. Hopefully with someone’s help I can get past this.
    One issue is my fog server time is off. I have updated the time zone to America/Chicago in both .php files, restarted all services, even rebooted the server and still the time is off. When I go to schedule a delayed task it says the task is in the past. Not sure if this is a bug, but would it prevent me from joining computers to active directory?
    Second issue is I cannot seem to enable auto joining to active directory. My fog.log file states says invalid hostname format. Any ideas as to why I would get that message? I have downloaded the client service, used fog crypt, checked all “active directory” options in the fog server under fog settings, group settings, and host settings. In my dash board for all of my hosts it either states “invalid hostname” or “hostname cannot be resolved”.
    Also I wanted to note, my fog server is not joined to my active directory, is that the underlying issue?
    Any help is greatly appreciated! I feel like I am so close!!

  • @Wayne-Workman Update. OK I have been able to test further. Capturing, deploying, and auto join to AD is working fine. Thank you everyone for all your help! This is a pretty powerful program. I am having printer setup issues, however I will either start another thread or jump in on an ongoing printer thread. You can set this thread as solved. 👍

  • @anthonyglamis said:

    Once I determine that capturing and deploying is stable I will perform my own write up.

    Good documentation is a vital part of any software solution - open source or not.

    So is a helpful and acive forums 🙂

  • @Wayne-Workman @Arrowhead-IT @Tom-Elliott
    Just wanted to update. I noticed the capture on my “golden” image yesterday did not capture or create the 1d.mbr file. I updated Fog today to the latest revision, 6136 (I just noticed there is another) recaptured, and checked for the 1d.mbr file and to my surprise the d1.partions file was there as well. Fog deployed this image to another laptop with success as well as auto joining to AD. I think I am getting the hang of Fog. I want to test a few more platforms. I will update, and if successful we can set this thread as solved!
    Once I determine that capturing and deploying is stable I will perform my own write up. I understand that most of the info is in the WIKI, but some of it is outdated. The instructions still list fog 0.32, which if you remember the beginning of this thread, that’s what I started with 😉

  • @Wayne-Workman I just finished reading your post and the FTP WIKI. I apologize I don’t think I was understanding what you were referring to. So in my storage node settings the FTP path must match, as well as the user name and password. Thanks for the heads up. I have updated all the info. Straight from the WIKI.

    Web Interface -> Storage Management -> Your storage node -> Management Username & Management Password
    Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD
    The local 'fog' user's password on the Linux FOG server
    /opt/fog/.fogsettings -> storageftpuser & storageftppass (For recent FOG Trunk versions only. 1.2.0 does not have this setting. 1.3.0 will though.)

  • @Wayne-Workman Currently I am not receiving an error file not found, but I assume I want a password in that field for added security. Thanks again for the input. 👍

    Now I am curious. Would FTP mismatch in credentials cause the error “image store corrupt”? I know what happened. The d1.mbr file was not created on that image. Duh…at least I’m starting to recognize some of these issues. Capturing again. This time I am trying Single disk (re sizable)

  • @anthonyglamis yes. There’s a article all about ftp. “Troubleshoot FTP” in the wiki.

  • @Wayne-Workman I updated the .fogsettings file to reflect “yes”;
    The ftp credentials were left blank upon install. If I change this does it also have to be changed on the fog server?

  • @anthonyglamis No need, just uninstall the fog client and then reinstall. Reboot a few times and see if the errors go away.

    Make sure you set your /opt/fog/.fogsettings caCreated to yes so this doesn’t happen again.

    Also, I forgot to ask earlier, but is there a reason why your fog ftp credentials are blank in that file?

  • @Wayne-Workman Just deployed my image. I unchecked add to domain and it imaged and did not join to AD. The log output states: “Authentication error. CA is not from the fog server”. Any suggestions on next testing steps?
    I can attempt to perform a factory reset for my most heavily used model, build an image, install the client service , register the host and capture.

  • @anthonyglamis said:

    Once the image is created can I manipulate it if I ever had to?

    In a way, yes.

    You’d un-check the domain joining checkbox for a host, download your image, make your changes, and then re-upload.

    When you re-upload, if you do not change the image assigned, it will write over your old image. You can create a new image and assign the new image to the host, and upload to that if you want. That way lets you keep both the old image and the new image - but it takes up space. This is what I do, if you were wondering. Space is cheap.

  • @Wayne-Workman So what if I restore one of my laptops to factory default? The reason I say is we don’t use WAIK, or sysprep. Let’s say I create a master golden image, but it is time to update it for instance adding an additional program. Once the image is created can I manipulate it if I ever had to?

  • @anthonyglamis said:

    With the new client 0.9.10 do the new clients intended to be deployed and auto joined to the domain need to be created in AD before deployment?

    No. When they join, they will appear in the default OU, whatever that’s configured as. On an unchanged AD setup, this is the “computers” OU. I always change mine though.

  • @Wayne-Workman Thanks for the quick response. Yes the image baseline I used was at a certain point on the domain. I removed it from the domain in order to create a baseline as I do not have a volume license with Microsoft so I have nothing else to go off of. I can try a new windows 7 license though. I have one copy. That might be my best bet. Start from scratch.
    I am deploying the image now as you suggested. With the new client 0.9.10 do the new clients intended to be deployed and auto joined to the domain need to be created in AD before deployment?

  • @anthonyglamis said:


    @Tom-Elliott will need to confirm/deny if that is right… normally when the CA has been created, this is set to yes and if it’s blank, this might be why you get authentication errors every time you update… because it’s remaking the CA every time. I’d say it’s probably safe to type yes inbetween those quotes.

    In my /opt/fog/.fogsettings file, the yes is between double quotes. like this:

    About the image bound question, that’s just a generic term I use, “Bound”. Meaning already joined to a domain. In the Apple world, it’s called “Binding”… but anyways…

    Download your image to a computer, but before you do, disable domain joining for just that particualr computer. You can do this from the host computer’s menu on the left, there’s a link labeled “Active Directory”, in there you can just uncheck the “Join” checkbox and then save that, then deploy your image to this machine.

    After it’s deployed, just look to see if the computer is already joined to the domain or not. If it is, that’s what’s causing your trust relationship error.

    FYI, never capture from a computer that is joined to a domain. Good advice: Never capture an OS build from a computer that has ever been joined to the domain. Joining mucks with settings on the image and all you’ll be doing is begging for complications down the road, even if you later unjoin it and then capture.

  • @Wayne-Workman Wayne, thank you for the reply. I apologize but what do you mean by “bound to the domain”? This is what my .fogsettings file looks like.

    Created by the FOG Installer

    Version: 6124

    Install time: Thu 14 Jan 2016 04:05:49 PM CST

    routeraddress=" option routers;";
    dnsaddress=" option domain-name-servers; “;
    packages=‘apache2 php5 php5-json php5-gd php5-cli php5-curl mysql-server mysql-client tftpd-hpa tftp-hpa nfs-kernel-server vsftpd net-tools wget xinetd sysv-rc-conf tar gzip build-essential cpp gcc g++ m4$

  • @anthonyglamis said:

    “The security database on the server does not have a computer account for this workstation trust relationship”.

    Check to see if your image is already bound to the domain.

    Also, inside of your /opt/fog/.fogsettings file, make sure there is not two fields for CaCreated=

  • @Wayne-Workman Is there any way to get this post categorized as “unsolved”? I am still having issues.

  • Update. Earlier I was successful deploying an image to 3 different laptops. These were for my Austin site. I just tried to deploy the same image to another laptop for my Austin site, and the authentication errors have returned. This is kind of blowing my mind. I am on revision 6124. I’m not really sure why I was successful 3 times and now the CA chain is broken. This is interesting.

    More updates. I have 2 images, both are for my Austin sites. 1 is a baseline, the other has printers already set up as TCP/IP ports. The image with the printers is failing. The log is returning Authentication errors as stated above, and the hostname changer did not work either.
    I decided to try the baseline image. The hostname changer worked. I have a “switch user” option and my domain is showing up as an option to log into. I try to login and it says “The security database on the server does not have a computer account for this workstation trust relationship”. I did stage the computer in my default directory OU before deploying the image. The log is still stating that the CA cert validation failed. Could not authenticate.

  • @anthonyglamis I think this is a bug. Tom’s doing a whole lot of work/improvements on the upload/download scripts at the moment.