The last version of the BigFix Agent to support HP-UX 11.31 is 9.2.x.
Can you confirm that in fact the agent version installed on the endpoint in question is 9.2? The Client logs posted above suggest an 8.2 agent version:
I also have this issue on an old Redhat running v8.2 bigfix. The agent is already at the latest version for that OS. Any other workaround for this 403 error?
RegisterOnce: GetURL failed - General transport failure. - 'http://xxxx:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=8.2.1409.0&Body=0&SequenceNumber=1474&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://xxxx%3a52311&AdapterInfo=00-50-56-94-37-90_10.222.100.0%2f24_10.222.100.133_0&AdapterIpv6=00-50-56-94-37-90%5efe80%3a%3a250%3a56ff%3afe94%3a3790%2f64_0' http failure code 403 - registration url - http://xxxx:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=8.2.1409.0&Body=0&SequenceNumber=1474&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://xxxx%3a52311&AdapterInfo=00-50-56-94-37-90_10.222.100.0%2f24_10.222.100.133_0&AdapterIpv6=00-50-56-94-37-90%5efe80%3a%3a250%3a56ff%3afe94%3a3790%2f64_0
It was able to register and report into my v9 infrastructure but fails when trying to migrate it to a new v10.0.2 BigFix infrastructure.
Is this connecting to the new deployment’s root server, or to a Relay?
Based on the 403 error I’d expect to see that if the new deployment is using an Authenticating Relay, and the client does not have the shared secret for registration.
But if it’s trying to register to the root server it may be something else.
In my browser if I hit the same url from the log but with https, it seems to work. I know these old v8 clients are well out of support but is there anything that could explain why it wont register with this relay?
An 8.2 client is capable of reporting to a 10.x deployment, but I’m not sure what security settings might impact that.
As a test, I’d try building a new 8.2 client and registering it to your 10 deployment. That may expose whether the problem is really the client version, or whether something more needs to happen with the masthead-switching on an 8.x client.
Originally I had the 8.2 client registered with our v10. I then swapped out actionsite.afxm, restarted the client and then got the failure to register. I then did a complete uninstall of the client, deleted /var/opt/BESClient, the latest 8.2 redhat4 rpm. Started the service and then still gets the same registration error.
Good to know your 10.x is not applying some setting that prevents an 8.2 client registering at least.
The HTTP 403 is an authentication failure…I would suspect the __KeyStorage folder under BESClient, but I don’t really know whether that was a thing back on 8.2.
Can you uninstall again, remove all traces of BESClient at /var/opt and /etc/opt, reinstall, apply your masthead, and post that log? The previous log had a ReportSequenceNumber in the registration that might indicate it was not a “new” client.
Apologies but I’m stretching a bit, I’m not as familiar with the 8.x clients
Stopped BESClient
Uninstalled BESAgent
Removed /etc/opt/BESClient
Removed /var/opt/BESClient
Reinstalled BESAgent
Copied actionsite file to /etc/opt/BESClient
Started BESClient
March 17, 2021
At 04:27:13 +1100 -
Starting client version 8.2.1409.0 built for RedHat 4 i386
FIPS mode disabled by default.
Cryptographic module initialized successfully.
Using crypto library libBEScrypto_1_0_0_4 - OpenSSL 0.9.8x-fips 10 May 2012
Restricted mode
At 04:27:14 +1100 -
Beginning Relay Select
At 04:27:15 +1100 -
RegisterOnce: Attempting to register with 'http://xxxx:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=8.2.1409.0&Body=0&SequenceNumber=0&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://xxxx%3a52311&AdapterInfo=00-50-56-94-37-90_10.222.100.0%2f24_10.222.100.133_0&AdapterIpv6=00-50-56-94-37-90%5efe80%3a%3a250%3a56ff%3afe94%3a3790%2f64_0'
At 04:27:16 +1100 -
RegisterOnce: GetURL failed - General transport failure. - 'http://xxxx:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=8.2.1409.0&Body=0&SequenceNumber=0&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://xxxx%3a52311&AdapterInfo=00-50-56-94-37-90_10.222.100.0%2f24_10.222.100.133_0&AdapterIpv6=00-50-56-94-37-90%5efe80%3a%3a250%3a56ff%3afe94%3a3790%2f64_0' http failure code 403 - registration url - http://xxxx:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=8.2.1409.0&Body=0&SequenceNumber=0&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://xxxx%3a52311&AdapterInfo=00-50-56-94-37-90_10.222.100.0%2f24_10.222.100.133_0&AdapterIpv6=00-50-56-94-37-90%5efe80%3a%3a250%3a56ff%3afe94%3a3790%2f64_0
It appears the client is failing to connect using the unsecured http protocol. You earlier stated you could only connect with a browser using https. Did you try connecting from the browser using http? If it failed to do so, I would probably conclude that the 8.2 client is not SSL capable or perhaps not configured for it.
the fixlet that ran on this server in an attempt to migrate it from the old v9 environment to the new v10 environment. Line 1 of the actionscript is: download now as masthead.afxm http://<mastheadurl>:52311/masthead.afxm
I use this download now method because it ensures that the client will be able to reach the destination relay for initial registration before it messes with the old masthead/actionsite.afxm
The fixlet ran on these Redhat3 & 4 servers fine and downloaded the masthead (via http) so I know that it could connect to the v10 relay. But when it gets to registration to the same fqdn, we see these General Transport Failures.
This v8 client was communicating fine with the old v9 infrastructure and I didn’t expect any SSL dependency changes from v9 to v10.
I guess that’s an option, but not one I like Would probably just say these aren’t supported in talking to a v10 deployment in our environment.
Also, we just confirmed that the working servers are being redirected via hsts. We updated one of the broken servers actionsite file to directly point to https, it loaded, but it failed at the crypto. Most likely because the crypto is “Using crypto library libBEScrypto_1_0_0_4 - OpenSSL 0.9.8x-fips 10 May 2012”
Would probably just say these aren’t supported in talking to a v10 deployment in our environment.