hostnamechanger access denied
I am using the new client version 0.10.6 with the latest trunk as of last week and within the log file it gives me access denied error
Hostnamechanger Checking hostname
Hostnamechanger Hostname is correct
Hostnamechanger Access Denied, code = 5
This is the first time I imaged and deployed since upgrading the same system from 1.2.0 using legacy client (which was working fine for joining domain) I manually, through windows joined the domain just to check the username and password were correct for joining and they are. I think I did all the usual things like making sure the service is activated everywhere (which kept the settings from 1.2.0) and not using fogcrypt etc (as thats for the legacy client). Just a bit stuck as to what to try as not much info I can find on the new client.
Yes, it was indeed the permission problem, all it working now as expected, thank you so very much
@Joe-Schmitt Right good to know, I will see if I can get permissions to create and hopefully that should sort the problem (I’m sure it will) thanks for the info, I will get back here once done.
The new client requires the permissions to create an account (this is needed for samba domain support).
I downloaded and put the legacy client back on the host and entered my FOGCrypted password in the appropriate field and it joined the domain no problem. Does the legacy client not verify that it is joined? There must be somthing that I am missing when transitioning over to the new client?
@kickers56 I’m not 100% sure on how things work, but if the account that’s doing the domain joining is NOT allowed to view information from the AD server to verify if it is joined or not, I imagine this might be one of the things a person may see. Again, I’m not 100% sure but it seems to point this way to me.
So my account has permissions to join machines but cannot create new accounts, or take them off presumably. Would this cause a problem with the new client? Would it be trying to remove and then create the account on the AD again? There shouldn’t be a problem if I can manually join through Windows right?
@Quazz I am now in the process of asking and will report back, thanks
@kickers56 Is it possible they altered something behind the screens concerning AD?
What is it that the new client does different to the legacy client (as that worked). I am not in charge of our AD directly so will see about what permissions I have on my credentials and post back when I know more.
@kickers56 Sounds like permission issues to me. That’s generally what Access Denied leads to anyway.
I’m curious why it was looking for access when it already states the hostname to be correct already, though.
So thank you the query through the browser now shows “Not allowed here” so no more information being visible.
Regards the other problem I am having, I upgraded to latest trunk today (7953) and still having the same problem with Access denied on windows 7 and FOG Server ubuntu 14.04
01/06/2016 09:26 Client-Info Client Version: 0.10.6
01/06/2016 09:26 Client-Info Client OS: Windows
01/06/2016 09:26 Client-Info Server Version: 7953
01/06/2016 09:26 Middleware::Response Success
01/06/2016 09:26 HostnameChanger Checking Hostname
01/06/2016 09:26 HostnameChanger Hostname is correct
01/06/2016 09:26 HostnameChanger Access Denied, code = 5
Also if I change the AD password to anything else on FOG server it then issues a logon failure unknown username or password, So it knows the username and password is correct.
Is this something to do with how my FOG server is set up or my AD?
Thanks for any help, if it is my AD I just don’t know what to change as I can manually join the domain and it used to work with the legacy client.
Alright, I’m trying to understand, why are we accessing using hostname.php? 0.10.6 does not make a call to this link. At least not that I’m aware of ( @joe-schmitt let me know if I’m wrong?)
It’s most likely left there for debugging purposes, though I will most likely need to get this corrected.
With this, I can see the AD password…
@falko Find the related host and and reset encrypted data. You’re not seeing unencrypted data in the browser though, correct?
I am also seeing this issue, on 7945.
Seems intermittent though, as I deployed an image to a machine in the office and to virtualbox and they were fine. But I am now in an IT suite and have just seen this access denied code 5 in one of the logs
Well thats what I thought actually the version is 7845
I can even read the password unencypted as is from the browser which obviously is bad. Why would it be doing that?
@kickers56 What version of FOG are you running?
The 2 slashes is fine, but you should NOT be able to discern ANY data out of the url.
It won’t post the two slashes, so to be clears its between mercia and scmmacadmin there are two slashes not one.
Sorry forgot to mention it still isn’t working, in the fog log it still says access denied.
Thanks for the help.