hostnamechanger access denied

[Tom Elliott]

@falko Find the related host and and reset encrypted data. You’re not seeing unencrypted data in the browser though, correct?

[falko]

@Tom-Elliott
With this, I can see the AD password…
http://<fog_ip>/fog/service/hostname.php?mac=<my_mac>&newService&json

[Tom Elliott]

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.

[kickers56]

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

---

--------------------------------HostnameChanger-------------------------------

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.

[Quazz]

@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.

[kickers56]

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.

[Quazz]

@kickers56 Is it possible they altered something behind the screens concerning AD?

[kickers56]

@Quazz I am now in the process of asking and will report back, thanks

[kickers56]

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?

[Tom Elliott]

@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.

[kickers56]

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?

[Joe Schmitt]

The new client requires the permissions to create an account (this is needed for samba domain support).

[kickers56]

@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.

[kickers56]

Yes, it was indeed the permission problem, all it working now as expected, thank you so very much