There are several ways to handle it, increasing in both complexity and security as you move down the list -
-
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.
-
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.
-
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 theBESClient -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. -
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.