Enroll offsite computers with authenticating relays, while preserving existing pathway for internal devices

Usage and Config Platform
1

We have several internal relays, and two internet-facing relays.

In our ActionSite.afxm, we have one of our internal relays defined as the x-bes-fallback-server:

x-bes-fallback-server: internal-relay.bigfix.company.com

If I try to enroll an offsite computer, I predictably see issues connecting to the internal relay to enroll (because the device is not on the same network):

At 22:48:10 -0400 - 
   RegisterOnce: Attempting secure registration with 'https://internal-relay.bigfix.company.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=11.0.5.204&Body=549858408&SequenceNumber=67&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://bigfix.company.com%3a52311&[...]
At 22:50:40 -0400 - 
   RegisterOnce: GetURL failed - General transport failure. - SOCKET CONNECT (winsock error 4294967288 - registration url - http://internal-relay.bigfix.company.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=11.0.5.204&Body=549858408&SequenceNumber=67&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://bigfix.company.com%3a52311&[...]

I then initiate a manual key exchange so the device can enroll, using one of our internet-facing authenticating relays:

sudo ./Library/BESAgent/BESAgent.app/Contents/MacOS/BESAgent -register xxx http://public-relay.bigfix.company.com:52311

which succeeds:

Initializing for key exchange.
Cryptographic module initialized successfully.
Sending key exchange request to http://public-relay.bigfix.company.com:52311/
Successfully collected client certificate.

However, the client does not then proceed with enrollment through the public relay — it instead continues to try and connect to the same internal relay defined in the afxm as the x-bes-fallback-server, and fails because the device is not on our internal network.

Starting over, if I define one of our public, authenticating relays as the x-bes-fallback-server, remote devices can successfully enroll after performing a manual key exchange. But now, all devices, including those onsite, need to perform a manual key exchange because the first relay they connect to is authenticating.

Is there a solution that accomplishes...

  • Onsite devices enroll with just the installation package
  • Offsite devices enroll after a manual key exchange
  • Neither set of devices requires adding additional settings to the clientsettings.cfg

?

Our requirement is that as much as possible is handled before the technician gets to the device, so we can't ask them to modify their clientsettings.cfg files (trying to avoid this as much as possible — asking them to modify the clientsettings.cfg will not go over well).

If it's not currently possible, is either of the below feature requests reasonable?

  • After performing a successful manual key exchange, device proceeds to enroll with the authenticating relay it established a connection with
  • A second relay can be defined in the masthead (not clientsettings.cfg) to attempt connecting to after the x-bes-fallback-server fails to connect.

Thanks for any insight or advice.

2

if a client explicitly validates its identity against a specific relay, it makes sense to attempt registration there. However, the BigFix client design strictly decouples authentication/key-exchange from the relay selection algorithm which we have seen for few clients. The client relies on the masthead or configuration settings to determine its parent.
I think this would need idea to be submitted to HCLSoftware Customer Idea Portal | Submit & Vote on Product Innovations

Also not sure but I guess this can be achieved
Configure Internal DNS to resolve bigfix-fallback.company.com to your internal relay IP address.
Configure External DNS to resolve bigfix-fallback.company.com to your public-facing relay IP address.

Note: For this to work cleanly for offsite devices without a manual key exchange, you would need to configure the public relay to accept secure registrations via a password embedded in a custom installer package or utilize a non-authenticating landing relay in a DMZ that handles initial registrations before passing clients to authenticating relays.

1 Like
3

I have a fallback relay set in my masthead that is an internal relay. DMZ clients would not be able to connect to it.

I then set a client setting to set a list of relays to try. I provide a different list to DMZ servers then internal servers, and it works fine.

_BESClient_RelaySelect_FailoverRelayList=server1.domain.com;server2.domain.com

1 Like
4

Does semicolon works to point to 2 relays? I haven't tried it. If it works then it's fantastic :blush:

5

It does: List of settings and detailed descriptions

”This setting, first introduced in BigFix 9.0, is a semi-colon delimited list of relays to try.”

1 Like
6

it does.. I even put in 4+ relays for my DMZ clients so clients would try relays in a performed order (local DMZ, secondary DMZ, internal, etc). Trying to prevent any issues that a client would fall fully offline

I also use DNS alias heavily in these cases so it’s not even restricted to a specific hostname and I can swap out a relay if required

2 Likes
7

I never got chance to explore semi colons since never had to make such configurations. This is duly noted. Thank you.

8

I just recently had an idea about this: for each automated/secured deployment channel, have an enrollment relay with a single secret for that relay/channel.

  1. MSAutopilot/Intune -- client packages distributed via this channel enroll with secret1 on relay1.
  2. AppleADE/MDMa - client packages distributed via this channel enroll with secret2a on relay2a.
  3. AppleADE/MDMb - client packages distributed via this channel enroll with secret2b on relay2b.

...etc. Meanwhile,

  • Relays at the DMZ (or otherwise Internet-exposed) only accept secure endpoints.
  • A remaining failover relay only accepts connections from the internal corporate VPN.

Right now this is only an idea. But I think it'll work?

9

Another alternative would be to create a clientsettings.cfg that disables relay auto-selection, sets the internet relay as primary and the secondary internet relay as failover. It also sets the _BESClient_SecureRegistration value to a complex unique value that I’ll call “xxxx”.

Then set "_BESRelay_Comm_KeyExchangePassword"="xxxx" on the internet-facing relays.

Microsoft Orca would used to edit the client installation MSI to add the custom values from the CFG as well as the masthead into the MSI.

Now install your offsite clients with the custom MSI. They will find your DMZ relay and be able to register properly. This approach takes a bit of preparation, but does work once you get the pieces in place.

1 Like
10

Thanks all. We're going to try setting up a split DNS to point external devices to one of our public authenticating relays (with a manual key exchange as a post-installation step) and internal devices to one of our internal relays.

It's easier for us right now to ask our clients to download a new afxm, rather than modify their clientsettings.cfg files (lots of unique configs out there that we don't build/distribute for them at this time).

Will report back how it goes.

1 Like
11

It definitely does work.
When I was a customer, I had a huge number of segmented networks, that only allowed Relays to communicate upstream between them. Wanting to have a single client installer to distribute between them, I've had as many as 20 relays in the list.

12

Yes this should work, I've used something similar at scale - where we had a multi-geo organization, each with site-level relays with different enrollment needs and locally-managed authentication passwords, each site distributing their own client installers with their own FailoverRelayList and Auth settings.

13

This solution - a split-brain DNS, where internal clients resolve a Relay name to an internal host, and external clients resolve the same name to a different Relay - should also work.

There are some challenges then if you care to track which relay a given client is really using, since the external clients will be falsely reporting the internal relay name even if they're actually using the external relay. The client keeps working, it's just a reporting issue, and usually it's not a problem as long as you understand the limitation.

If you need more detail about what relays the clients are really using, I have some properties I've built based on the RelayChain.txt that the clients build when they register - it shows the real relay names and computer IDs that the client is using, and is not fooled by DNS aliases, load-balancers, or the like.