Authenticating relay - manual key exchange

For manual key exchange - is it one password per agent, or same password for multiple agents ?

Both options are supported. Please see https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Console/ManualKeyExchange.html#Manualkeyexchange for more details.

So you set _BESClient_SecureRegistration on the client with value being the password, and set _BESRelay_Comm_KeyExchangePassword on the relay with the value being the password the the client would use ?

1 Like

There are several ways to handle it, increasing in both complexity and security as you move down the list -

  1. Force the client to your internal network / non-authenticating relay for the first registration. If you first install the client on your internal network (either physically or through a VPN), and it can register to a non-authenticating relay or root server, then once it’s registered it has a certificate and can freely roam to your DMZ / authenticating relay afterward.

  2. Use a single registration password for your Relays and Clients. As you say, configure _BESRelay_Comm_KeyExchangePassword with a single password on the Relay, and _BESClient_SecureRegistration on the client (probably using a clientsettings.cfg file to include the setting in the client installer package you deliver to the end-user).

This protects against random Internet scans finding and authenticating to your relay, but does not protect against any insider threats from a user who can retrieve the password from a copy your client settings file or the registry on the client.

  1. Configure _BESRelay_Comm_KeyExchangePassword with a single password on the relay, but don’t deliver the client setting to the user. Instead have either the user, or your help desk via a remote session, log on to the client and manually register by executing the BESClient -register <password> [http://<relay>:52311] command on the client after installation.
    This is slightly more secure than the second option, as the password isn’t left behind on the client and you can periodically rotate the password on the Relay without worrying about old copies of the client installer using the old/wrong password, but clearly is more overhead as it requires the user or help desk to manually intervene.

  2. Configure a number of “one-time passwords” on the Relay. From the article @aram cites

A newline-delimited list of one-time passwords stored in a file named KeyExchangePasswords in the relay storage directory (value StoragePath of HKEY\SOFTWARE\WOW6432Node\BigFix\Enterprise Server\GlobalOptions)

In this case you do not configure _BESRelay_Comm_KeyExchangePassword on the relay, the relay retrieves one-time passwords from the password file.

Assuming all default paths, you create a text file (with no filename extension) at c:\Program Files (x86)\BigFix Enterprise\BES RElay\KeyExchangePasswords
The file contains one password per line. Each password can only be used once, so you give a different password to each client to use when installing. Either you build a separate installation package for each client with a unique clientsettings.cfg containing the password, or instruct the user/helpdesk to use one of the passwords from the list. Once the password has been used once, it cannot be reused to register to the relay.
This is much more secure because the passwords cannot be reused, but also the most overhead to manage as you may need to periodically add more passwords into the relay.

I haven’t gotten around to it, but have been meaning to check whether we can update the relay’s password list on-the-fly without restarting the relay service. That could be useful in an automation where another provisioning source (TPM, Maximo, ServiceNow, Remedy) etc. defines when new machines are supposed to be added to the deployment, and generates new one-time passwords for that specific machine.

I’m always interested in hearing how other people are using these options, so when you give it a try please let us know what you end up doing and how it works out for your environment.

5 Likes

Awesome, thanks you very much. We need a scalable solution, so option # 2 probably works best here.

1 Like

Nice work Jason.
I’ve been working on #2 today, and keep getting a failure. We do our initial push of BF client using group policy, so I’ve been trying to keep things as one MSI file to allow that to work.

To get the _BESClient_SecureRegistration setting, i’ve edited the bigfix client installer MSI using Superorca and added a row to the registry table, which seems to work, where it adds our Relay password to the registry settings installed when the client is installed.

however it keeps failing with “Failed to register the authenticating relay with the provided password”.
I look in the registry, and instead of the password, it has an entry starting with {obf} and then an entirely different password. I’m thinking that it is doing some kind of encryption on the password to store it in the registry.
If i then run the manual command to BESClient -register [http://:52311] it will register and work normally. I was wondering if i need to embed the relay into the registry and have tried a few entries based on what appears after the manual command succeeds, but that isnt working so far.

Has anyone tried to get the MSI to do this automatically?

1 Like

Any chance HCL could improve the support of Manual Key Exchange on Linux hosts? It LOOKS like I have to manually edit the client settings information in order to insert the Key prior to the Client being able to connect with an authenticating relay.

I have not tested this, but I believe you should be able to perform Manual Key Exchange on Linux hosts by running a command against the agent as well:

https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Console/ManualKeyExchange.html

This would look something like:

/opt/BESClient/bin/BESClient -register <password> [http://<relay>:52311]

I know this post is a little older but I have a question… once the password is used from the OTP list, is it removed?

we are using #1, thanks

As a mitigating measure, a policy action could detect and delete the _BESClient_SecureRegistration setting once the machine is registered.

However, in the 2023 context of machines in drawers waking up to find the keys having been rotated out from under them, they’d be out of luck in this scenario.

1 Like

I’d have to check, but I think the client does delete that setting automatically once it registers (which presents its own problems for re-registering deleted or reset clients later)

If anything, it creates a need for a belt-and-suspenders deployment in which one can alternately deploy a manual reregistration. If one has a second agent that can do things, that other agent could perhaps trigger the registration directly, or deploy a package or script that does it, or … etc.

I do like the approach of overlapping controls. Depending on the deployment, I could see scenarios where MDM and BESClient watch each other, and similar between BigFix and EDR/Antivirus.

GPO-based agent deployment or machine startup scripts to check & repair BESClient status also seems fairly straightforward.

:thinking: Can MCM’s current feature set fill this gap?