SVN 5370 Domain Username Bug

[shird]

Hi,

I’ve been having an issue in the SVN 5370 trunk release (and the last few releases before that), with getting FOG imaged machines to auto join the domain.

In the Active Directory Defaults config section when I enter a domain username, the imaged machine does not join itself into AD. Upon second inspection of the config settings the Username has been populated with many, many backslashes.

My initial thought is that it may be something to do with PHP and Magic Quotes being turned on potentially. I’m wondering if anyone else has come across this issue?

[Wayne Workman]

Can you check and see what’s in the DB?

mysql
use fog
select * from globalSettings where settingKey='FOG_AD_DEFAULT_USER';

You can update that field like this:

update globalSettings set settingValue='Administrator' where settingKey='FOG_AD_DEFAULT_USER';

Other notable settingKeys for this topic:

FOG_AD_DEFAULT_DOMAINNAME
FOG_AD_DEFAULT_OU
FOG_AD_DEFAULT_PASSWORD
FOG_AD_DEFAULT_PASSWORD_LEGACY
FOG_AD_DEFAULT_USER

I should add that the “Domain Password” field in FOG Trunk (1.3.0 and higher) can ONLY be populated properly by using the web interface, because there is code in the web interface that encrypts the new password field, unlike the Legacy Password.

[Tom Elliott]

Can you just set the username to the username?

I just tested saving and resaving things with the \ in the username and I’m not seeing this over and over.

[shird]

@Tom-Elliott said:

Can you just set the username to the username?

I just tested saving and resaving things with the \ in the username and I’m not seeing this over and over.

Tried this and it is still not joining to the domain.

@Wayne-Workman said:
Can you check and see what’s in the DB?

mysql
use fog
select * from globalSettings where settingKey='FOG_AD_DEFAULT_USER';

You can update that field like this:

update globalSettings set settingValue='Administrator' where settingKey='FOG_AD_DEFAULT_USER';

Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0

Nothing to change by the looks of it.

Other notable settingKeys for this topic:

FOG_AD_DEFAULT_DOMAINNAME
FOG_AD_DEFAULT_OU
FOG_AD_DEFAULT_PASSWORD
FOG_AD_DEFAULT_PASSWORD_LEGACY
FOG_AD_DEFAULT_USER

I should add that the “Domain Password” field in FOG Trunk (1.3.0 and higher) can ONLY be populated properly by using the web interface, because there is code in the web interface that encrypts the new password field, unlike the Legacy Password.

Everything as expected in the DB (domainname is FQDN, user is correct, etc). Same as the information that was input into Config options page (sans Legacy Password as this is not used).

[Tom Elliott]

What do you mean the legacy password is not used? You’re whole environment is using 0.9.7 version of the client?

[shird]

It is a test environment at the moment with a view to pushing out to production, so yes client 0.9.7 is being used (that is the latest version, right?).

[shird]

Slight update.

The bug in question only seems to appear when you click on the host AD details, not the overall FOG AD options.

---

I’ve re-checked over the client logs and it would appear that has an invalid certificate. Is there any documentation on how to regenerate certs and apply them to the client as I can’t seem to find any? I suspect I’m being a bit blind…

Thanks.

[shird]

It would seem rebooting the server then issuing the following command ./installfog.sh --recreate-CA --recreate-keys and re-installing the client (with a reboot of the client in-between) has done the tick for the cert error.

Still having problems with auto-joining on AD though. I’m now getting Unknown Return Code: 2202. Is it worth creating a new forum post for?

[ch3i]

@shird Not sure but I think the 2202 error is an authentication problem.

Edit : https://msdn.microsoft.com/en-us/library/windows/desktop/aa370674(v=vs.85).aspx

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