Fog Client 11.12 not renaming computer/joining domain (Could not authenticate)
-
@Sebastian-Roth Thanks for the suggestions so far
I tried the query again with single quotes instead of double quotes, probably should have noticed that, but I still received the same message:
mysql> UPDATE hosts SET hostPubKey='', hostSecToken='', hostSecTime='0000-00-00 00:00:00' WHERE hostname like 'hostname'; ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'hostSecTime' at row 1In case it should be updated to have single quotes, here is the article that had that query.
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Reset_encryption_dataI did also run this query and it looks like you’re right, those fields don’t appear to be set.
mysql> select hostname,hostPubKey,hostSecToken,hostSecTime from hosts where hostname like 'hostname'; +--------------+------------+--------------+---------------------+ | hostname | hostPubKey | hostSecToken | hostSecTime | +--------------+------------+--------------+---------------------+ | hostname | | | 0000-00-00 00:00:00 | +--------------+------------+--------------+---------------------+ 1 row in set (0.00 sec) -
@gnevills Tried this on my debian machine. Seems like your Ubuntu 17.04 comes with a newer version of MySQL: https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-changes
… in MySQL 5.6 with strict mode but not NO_ZERO_DATE enabled, TIMESTAMP columns can be defined with DEFAULT ‘0000-00-00 00:00:00’. In MySQL 5.7.4 with the same mode settings, strict mode includes the effect of NO_ZERO_DATE and TIMESTAMP columns cannot be defined with DEFAULT ‘0000-00-00 00:00:00’. This causes replication of CREATE TABLE statements from 5.6 to 5.7.4 to fail if they contain such TIMESTAMP columns.
@Tom-Elliott Do you know about this already? I think this could cause us a lot of problems when people migrate to newer versions of MySQL.
@Joseph-Hales Thanks a lot for reminding me on this post. Looks very similar and I already tried ti figure out where this
Value cannot be null. Parameter name: authorityis coming from. So far it looks like this could be something with the C# runtime environment. Has there been a windows update on that kind of stuff lately? -
I am getting errors as well in my fog log only recently. I am using ubuntu server. Not sure if these are related to gnevills’s error.
----------------------------------------------------------------------------- --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 6/20/2017 3:34 PM Client-Info Version: 0.11.12 6/20/2017 3:34 PM Client-Info OS: Windows 6/20/2017 3:34 PM Middleware::Authentication Waiting for authentication timeout to pass 6/20/2017 3:34 PM Middleware::Communication Download: http://10.1.4.59/fog/management/other/ssl/srvpublic.crt 6/20/2017 3:34 PM Middleware::Communication ERROR: Could not download file 6/20/2017 3:34 PM Middleware::Communication ERROR: Unable to connect to the remote server 6/20/2017 3:34 PM Middleware::Authentication ERROR: Could not authenticate 6/20/2017 3:34 PM Middleware::Authentication ERROR: The system cannot find the file specified.``` -
@coop90 Looks different, but you never know. Can you download the certificate with your browser or wget? http://10.1.4.59/fog/management/other/ssl/srvpublic.crt
-
@Sebastian-Roth Yes, I can download it through the browser.
-
@gnevills @Joseph-Hales Unfortunately I don’t know the client code well but I still jumped in to figure this one out. As I don’t have any Windows machine here at home I am left to dig in the code but cannot verify my findings so far.
To me this looks as if the CA certificate didn’t get installed on the client. Although I am not sure I think you should be able to find the certificate in your windows cert store. Please check if you can find it.
I guess you can’t. Then we need a full client log to hopefully be able to spot why it wasn’t able to install the CA cert on the client in the first place. AFAIK this is not done by the client installer but when running the client for the first time…
-
@coop90 said:
ERROR: Could not download file
ERROR: Unable to connect to the remote serverThose errors clearly point to a download/communication issue. Did you try accessing that file from the same client? Maybe a personal firewall or antivirus is getting in the way here?
Would you mind starting a new posting with this error? Right now it looks as if those two things are not related and I don’t want to confuse things.
-
@Sebastian-Roth Somehow I’ve gone blind or it got deleted, it seems like there was something posted that involved editing a couple files (functions.sh) on a test environment. I got a test fog server setup, is this still worth trying or was it deleted because that seemed like the wrong path?
I do not see that certificate installed, in the local or computer certificate stores. Although again I can download it from the link and open it, it does appear to be a valid certificate. I should mention this is a certificate that we issued from our internal Root CA, which is trusted by all of our clients. It’s CN & SAN are not the IP address, they are the FQDN of the fog server. I have tried installing the fog client specifying the fog server address as both the IP address and as the FQDN.
This is the powershell command I used to search the certificate stores.
get-childitem -recurse | where-object {$_.subject -like '*ipaddressORhostname*'}How do I obtain a full client log
-
@gnevills said in Fog Client 11.12 not renaming computer/joining domain (Could not authenticate):
Somehow I’ve gone blind or it got deleted, it seems like there was something posted that involved editing a couple files
Yeah, I edited my initial post as I was on the wrong track with that!
I should mention this is a certificate that we issued from our internal Root CA, which is trusted by all of our clients.
You mean the srvpublic.crt is issued by your own CA and not the FOG CA? Well that could actually be the problem. The certificate can surely verify the certificate signature but the fog-client uses the string “FOG Server CA” to find the CA cert in the client’s cert store. Please tell us more about which cert was issued by your internal CA and how did you install it on the server? Maybe the certs are a bit mixed up.
-
@gnevills said in Fog Client 11.12 not renaming computer/joining domain (Could not authenticate):
To upgrade we installed fog 1.4.0 on a fresh Ubuntu server and then imported the database and upgraded the schema.
If the db came from 1.3 or higher, you must also copy the certs. Info on how to do all of this correctly is here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
-
@wayne-workman @Sebastian-Roth I’m starting to look at this again. It’s been a busy month & somehow I missed your last post on this until a few days ago.
It does seem that this may be related to the srvpublic.crt file in /var/www/fog/management/other/ssl. I now have 1 test server (deployed from our Ubuntu template) with the “incorrect” cert & 1 test server (clean Ubuntu install) with the normal Fog CA cert. Clients contacting the server with the incorrect cert don’t join the domain (get the errors previously mentioned in fog.log), clients contacting the server with the Fog CA cert do join the domain (and have no errors in fog.log).
All I did was deploy our template and install Fog, I’m honestly not sure how this other cert ends up in /var/www/fog/management/other/ssl yet. I was wrong previously in saying that it’s issued by our internal root CA. It’s a certificate that is issued to our domain name by our domain name (issued to example.org issued by example.org) with an effective date that matches the date/time that Fog was installed. Very strange …
-
@gnevills Yes, the join issue is definitely caused by the cert problem from what it looks like in the logs. So maybe just move those weird cert files out of the way and rerun the installer using the option
--recreate-CA(not sure if the key is also gone, then add--recreate-keys) as well. -
@sebastian-roth Thanks for the suggestion, those commands are handy. I ran --recreate-CA alone & with --recreate-keys and just got a newer version of that same strange cert. I’m looking into it now but I believe someone may have customized the openssl.cnf file on our template, and something with that may be causing this behavior.
