Re: Auto-Join Windows Domain Troubleshooting
Thanks Joe,
Found it was due to my image’s Puppet Service was still pointing to the production Fog Server which was running 1.3.0 svn 4425 (Which my coworker noted might have the quirky security issue with hostname changes and such.)
Once I had it pointed to the test fog server, it carried out the Auto-Join Domain task it should have done. And once it did that, it also auto-updated the puppet service client as well.
@JoeCT said:
I use Centos 6.5 and had a similar problem. This is what was wrong with my setup.
https://forums.fogproject.org/topic/5518/fog-ftp-login-fails-after-image-creation
As Wayne pointed out, you may want to look at the link he has posted, but more than likely, the issue is that fog via the UI thinks the fog user password is ‘x’. On your server, however, the fog user on Centos has a password set to ‘y’.
The way I fixed it is to cludge the passwd on either the UI side or on the Centos side to match. Stronger the password, the better if you are doing this as it can lead to outsiders who can mess with your images if you have an open network.
@kjohnson said:
Hello,
No it did not prompt me to update the schema.
Do I need to run the install again to see if I get the prompt?Ken
I think probably… Not sure. I think one of the devs will need to pipe in on this for sure, but might be the source of your issues with missing information.
@Sebastian-Roth said in Windows 10 Image constantly trying to join domain after join.:
@SKasai said in Windows 10 Image constantly trying to join domain after join.:
Also should note that this is a Windows 10 Machine Joining a Samba 4 Domain (NT domain for Authentication)
Well, that brings another variable into the equation. I do remember that Samba 4 and Windows 10 was a huge fight when Win 10. I will still try to replicate this and see if I can fix it in the next weeks.
Sorry about that… But given I am in an Education (UC, in case), our groups were making use of most open source material (FOG Project included).
In the Samba 3 domain with Windows 7, we never had an issue. I just happen to notice it and with another department with regards to Samba 4 and Windows 10.
@Sebastian-Roth said in Windows 10 Image constantly trying to join domain after join.:
@SKasai said in Windows 10 Image constantly trying to join domain after join.:
Well, the normal behavior for Windows 7 when the fog client joins a domain is that it stops trying to join the Domain after it was joined, as it is joined to the domain in question.
Ok, so this seems to be an issue with Windows 10 I guess. I hope I get some time to look into this in the next weeks. It’s just very busy at the moment and I don’t get to work on all this at the same time.
@SKasai Would you possibly open an issue on github for us? It’s kind of easy to loose track of this kind of things in the forums. Not need to post all the details again, just link this forum topic…
Github issue submitted - Also should note that this is a Windows 10 Machine Joining a Samba 4 Domain (NT domain for Authentication)
We are doing it this way due to OpenLDAP requirements and this was the only way to get the Samba 4 Domain to work. I would have to get someone else to respond to this thread for particulars on the Samba 4 Domain setup.
I did speak with him and he feels it is also a Windows 10/FOG issue than a Samba 4 issue.
I also should clarify that the guys who are running a 1.5.5 (We are on the same campus) are doing a similar Samba 4/NT Domain authentication.
@fry_p said in Windows 10 Image constantly trying to join domain after join.:
@SKasai From the fog.log excerpt you posted, this appears to be regular behavior. I checked a log on one of my clients, it matches exactly. Correct me if I am wrong everyone, but I think the client checks to see if it is joined regardless of if it is already joined. This is only speaking to the fog.log message. It appears to me that the FOG client is successfully “talking” to AD as well judging by the “already joined” message.
May I ask what other behavior this is exhibiting? Is it trying to reboot to change the hostname endlessly? If not, and the only symptom is the log message, I myself would not worry too much about it as my clients also do the same. Others, please correct me if I am wrong!
Well, the normal behavior for Windows 7 when the fog client joins a domain is that it stops trying to join the Domain after it was joined, as it is joined to the domain in question.
What it currently does is basically adds unnecessary event viewer errors, as it shows messages of trying to join a domain while it is already joined. Given the client does this almost every 4-6 minutes when not logged in, it sort of unnecessary, at least for my form of OCD of troubleshooting and wondering why there are errors like this.
While it is authenticating to the joined domain, it isn’t necessary to keep hammering the PDC with join requests.
Luckily, I don’t have it set to reboot on join attempts, so it isn’t an issue, but I do want to reduce the number of unnecessary error events being recorded.
Hi guys,
So we were on FOG version 1.4.3 and I have been putting up some Windows 10 boxes joining a SAMBA 4 PDC for Active Directory purposes.
It joins the domain and we can authenticate to it, but when I Iook into the logs, I see Errors where it is trying to re-join the domain.
I look into the fog.log and it shows the ollowing:
(Note - I upgraded to 1.5.7 to see if this goes away, but as you can see from the log message, still having the same problem.)
When I look on System for the computer:
Computer name: <Hostname>
Full computer name: <Hostname>.<Domain>
Domain: <Domain>
In the past with Windows 7, it was usually:
Computer name: <hostname>
Full computer name: <hostname>
Domain: <domain>
So my guess is that given that the Full computer name is outputting with the <hostname>.<domain> instead of the normal <internet domain name> is what is causing fog to constantly try and join the domain, even though it is joined.
Is there something I should be looking at on Fog Side, or Windows side? Or even our Samba side, given we went from Samba 3 to Samba 4 and had to use an NT4 Domain trick to get LDAP to pass authentication to Samba 4 and to Windows 10.
Edited: I also checked with another guy in our area who is using FOG 1.5.5 and they are doing a similar setup and also having the same problem.
The only thing I can think of is that the FOG client doesn’t seem to recognize that it is joined to the domain, so it tries again, and keeps trying, despite the Domain being set. My guy and the other guy both think this is a Windows 10 problem, but I think the FOG client may need to be updated to recognize when Windows 10 is joined to a domain, given Windows 7 will be phasing out soon.
I believe I found the cause of the issue.
We are running CentOS 6 with FOG version 1.4.3
I was forced to restrict the iptables to not advertise NFS to the rest of our campus and only to our subnets.
In that process, I did not allow for iptables to allow lo (loopback, 127.0.0.1) to be accepted, which will also cause this error.
While I did allow for 127.0.0.1 being the source, which fixed nfs having issues with RPCBind, it does not solve the trying to submit a snapin to FOG as it appears to use -i lo interface path.
This issue should be considered resolved.
I ran into this error when I was trying to submit in a snapin on our FOG server.
I saw the suggestion for fix here:
https://forums.fogproject.org/topic/11202/fogcontroller-class-php-undefined-offset-3-line-1046
However, I tried that and still getting the error message.
Wondering if there is anything else I can look at?
Re: Auto-Join Windows Domain Troubleshooting
Thanks Joe,
Found it was due to my image’s Puppet Service was still pointing to the production Fog Server which was running 1.3.0 svn 4425 (Which my coworker noted might have the quirky security issue with hostname changes and such.)
Once I had it pointed to the test fog server, it carried out the Auto-Join Domain task it should have done. And once it did that, it also auto-updated the puppet service client as well.
I just set up a server running Fog 1.3.4 on CentOS 6.8 and using the DB from our current 1.3.0 svn production box.
The DB has been updated to the 1.3.4 implementation and was able to get an image and also roll out an image. But wondering if there are some things I can look at to find out why the image is not auto-joining the domain.
Fog Service is on the machine (Albeit the 1.3.0 version). I have also tried restarting the fog service on the windows machine to see if it will try to auto-join.
Is there also a way to get it to auto-join or does it only do it after the image task?
@Tom-Elliott
Should have added this now that I have saw this:
Organization - Engineering Computing Infrastructure at University of California, Santa Barbara
Location - Santa Barbara, California
Approx # systems - 130+
How Long - Minimum of 3 years
Can be listed in Wiki
From personal experience…
Each flavor of Linux will have its own frustration. The important thing is, take it slow… Take it easy…
I am currently in a University environment where I literally have 3+ or so OSes to figure out a lot of times. Heck, I am working with Fedora and CentOS as the mainstay, but have others who are on Ubuntu. And mind you, CentOS 6 as well as CentOS 7 now, Fedora 20 and 22…
One of the major problems you will run into is just repositories, unfortunately, FOG will not always have the answers nor their wiki because it is still hard to cover it all and I also found that while the FOG Project guys try to make sure you have all the repositories, sometimes the stumbling block is that the machine you are on may not be ‘nice’ when trying to look at new repositories and you have to make sure you enable the ones they put in.
Another thing to note, that some Repositories may not be ‘ideal’. As CentOS is one of the OSes that tend to change not as much… Some of the expected repositories may not have the ‘latest’ or ‘stable’ builds that some people will be willing to vette. So again, take it slow and easy.
