I see. We have a slightly dynamic environment where we may expect servers not part of our extended network to onboard bigfix.
The main issue is just the registration phase - everything else is fine. Let me try to play with certs then.
It doesn’t look like a ClientSettings.cfg option. It’s a command line option AFTER the client is installed.
Once you have the client installed, and it is failing to communicate with the relay, you need to run the following command from the command line …
BESClient -register <password> [http://<relay>:52311]
My understanding was that you could create a set of one time passwords, and then include one inside of the clientsettings.cfg file. I have never done this, so I have no idea how this works. Maybe you can just use _BESRelay_Comm_KeyExchangePassword on both sides?
Seems like a question for @AlanM
The password that is one time is just again to be used on the command line with the same command above. The password would be used up by the connection and not be available anymore. This is just to allow it to be given to an end user to do the connection
Thank you guys. I tried the setting on the relay and the one time password worked like a charm as per this:
https://www.ibm.com/support/knowledgecenter/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Console/ManualKeyExchange.html
@AlanM that helps. Any future plans/techniques within bigfix which would make it easier to onboard out-of-network fresh devices (eg: isolated IAAS instances) through an Authenticated relay? Food for thought.