SVN 5370 Domain Username Bug

[shird]

@ch3i Looks like you’re right.

I’ve checked the NetSetup.log file on the client and the reason it is failing authentication is due to the Account name containing lots of erroneous backslashes, as mentioned in my first post. Currently the account name in NetSetup.log looks like this: Account: domain\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

In the FOG.log I get the following:

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 20/11/2015 13:15 Client-Info Version: 0.9.7
 20/11/2015 13:15 HostnameChanger Running...
 20/11/2015 13:15 Middleware::Communication URL: http://192.168.1.156/fog/service/servicemodule-active.php?moduleid=hostnamechanger&mac=xx:xx:xx:xx:xx:xx||00:00:00:00:00:00:00:E0&newService=1
 20/11/2015 13:15 Middleware::Communication Response: Success
 20/11/2015 13:15 Middleware::Communication URL: http://192.168.1.156/fog/service/hostname.php?moduleid=hostnamechanger&mac=xx:xx:xx:xx:xx:xx||00:00:00:00:00:00:00:E0&newService=1
 20/11/2015 13:15 Middleware::Communication Response: Success
 20/11/2015 13:15 HostnameChanger Checking Hostname
 20/11/2015 13:15 HostnameChanger Hostname is correct
 20/11/2015 13:15 HostnameChanger Activing host with product key
------------------------------------------------------------------------------

And nothing appears to happen beyond it.

I’ve tried using a different account and restarting the FOG service, however no joy and I get the same as above.

[ch3i]

@shird Could you try to edit the user in the database instead the web UI ?

FOG_AD_DEFAULT_USER entry in the globalSettings table

[shird]

@ch3i I’ll give it a bash (no pun intended )

[shird]

Nope, no difference at all Same output as above

[shird]

Interestingly it there appears to be no attempts on logging onto the domain in the NetSetup.log file since I fixed the cert issue. Could it be getting stuck on the Product Key or something else?

[Tom Elliott]

I am still not understanding the problem.

The ad information presented is displayed as it’s stored on the host.

So why not just update the host?

[shird]

@Tom-Elliott I’m not sure I understand. What exactly are you asking for me to update?

[Tom Elliott]

Update the values as present on the HOST, not the Global settings.

[shird]

@Tom-Elliott Gotcha. Will try now.

[shird]

Brilliant. That appears to have worked!

is there then an issue with the global setting AD values? Entering each host information is fine for one or two hosts but it will be problematic for several or more?

[Tom Elliott]

@shird If you updated the global, then whatever entries are in that are populated to the host by checking the “Join Domain”.

After the initial save, the value is individualized on the host level.

One or two hosts is simple, but when you have 100’s or 1000’s of hosts, doing this one by one is very very tedious. This is where the Group page shines.

From the List/Search of Host page, you can check the boxes for the host or hosts you want to join to a new or existing group. Once they’re in the group, go to the Group and edit that new group. You can then update all hosts in the group at once, by following (more or less) the same exact steps as you would on an individual host.

[shird]

The global settings appear to be working now that the sloppy domain pre-fix has been removed and the cert issue was cleared up. It still appears to be a bug that the extra erroneous slashes are added, but if the expected input is wrong then that is fair enough really!

Thanks for the help, much appreciated.