We have a very unique environment where there are many clients on non routable networks that can only communicate with 1 Relay which is dual homes on both the non routable network and the routable network. These client computers are duplicated at every site. They all have the same IP and same name. Therefore the only way to distinguish them from other sites is to know what Relay they are connected to. However, because they get installed using the clientsettings.cfg file with an IP address, the default “relay” property is populated with an IP address that is duplicated across the many sites.
Relay 1 has multiple IPs 1 unique IP and 20 non routable duplicate IPs (ie 192.168.1.10, 192.168.2.10, 192.185.3.10… etc.)
Relay 1 has multiple machines connected to it.
Machine 1 has an IP address of 192.168.1.25 and talks to the relay at 192.168.1.10
Machine 2 has an IP address of 192.168.2.208 and talks to the relay at 192.168.2.10
etc. for Machine 3 and on
The Relays and the clients have the first 3 octets of the IP in common.
We use a fixlet as a policy the would query the relay for the name using the URL and then populate a file on the client with the relay name. We then have a retrieved property that reads that file and we get the name of the relay and are able to identify the site.
We recently enabled authenticated relay on all the relays. The clients connect using a password and then the fixlet runs, however, now that authenticated relay is turned on, the file is populated with 403 – Forbidden instead of a relay name. I assume this is because we can no longer browse the Relay URL.
I need a way to identify the relay for these clients. Any idea how how I can get the relay to return its name rather than 403–Forbidden?
Correct, an authenticating relay will not allow a connection without an authentication certificate from the client. It sound like you are using some process outside of the client, like a ‘curl’ command perhaps, to connect to the relay and retrieve information; that is exactly the kind of connection that Relay Authentication is intended to block.
I can think of a couple of approaches to this. You could try retrieving name of selected server in an Analysis, which should return the name of the connected relay.
The other is to parse the RelayChain log on the client (under __BESData\__Global\RelayChain). This file will contain a history of the real name and Computer ID of the relay connected at each relay selection time.
interesting challenge. Sounds a little like a retail store use case.
I assume you don’t have any services running that would provide reverse DNS on your isolated network, where an NSLOOKUP would help?
So the Relay “knows” it’s name and the name of the Relay will help determine which site your clients are located. In the past, you could query the relay service from the client and get the relay name, but with Authenticating relays, this no longer works.
What if we populate the file with the relay name on the Relay instead of on the Client, and then used Download Now on the clients to get that file with the Relay name inside of it?
and Action 2, run on the clients, would be something like
download now {"https://" & preceding text of last "." of (it as string) of addresses whose (it as string starts with "192.") of adapters whose (not loopback of it) of network & ".10:52311/RelayName.txt"}
copy __download/RelayName.txt c:\RelayName.txt
I have not tested, but I suspect the Download Now command will work from the relay where querying the relay service directly is now getting blocked by the Authentication Relay part. And I believe Download Now will allow for relevance substitution in the URL, unlike regular download command, and will allow you to bypass the SHA256 check.
// Direct Parent Relay
Q: tuple string items (number of tuple string items of it - 1) of tuple string of tuple string items whose (it starts with "r:" or it starts with "s:") of tuple string of substrings separated by " - " of lines (maximum of line numbers of lines of it) of files ((unique value of maxima of (((substrings before ".txt" of Names of it) as Integer) of Files of it)) as string & ".txt") of Folders "__Global/RelayChain" of data folder of client
If the RelayChain method works, I like it better than the 2 actions required method.
I suspect relay chain is going to show the ip address instead of the relay FQDN or computer name.
The Relay Chain method should show the BES computer ID and BES computer name of the chosen Relay or root server, prefixed by “s:” if the parent is the root server or “r:” if the parent is a Relay. I’ve used this to distinguish in cases where the clients are connected to a false-root relay (via DNS aliases) or to multiple relays (behind a WAN load-balancer), where the “true” name and IP address of the Relay are hidden to the client.
Q: tuple string items (number of tuple string items of it - 1) of tuple string of tuple string items whose (it starts with "r:" or it starts with "s:") of tuple string of substrings separated by " - " of lines (maximum of line numbers of lines of it) of files ((unique value of maxima of (((substrings before ".txt" of Names of it) as Integer) of Files of it)) as string & ".txt") of Folders "__Global/RelayChain" of data folder of client
A: s:1582295(bes-root)
T: 0.116 ms
q: name of selected server
A: BES-Root.domain.home.
T: 0.027 ms
This looks like a possible solution. I was able to run QNA and get a response. However, I’m not proficient enough to put this in an action script to test it. Also, do you know if this tuple will work on all version of the client 9.2 - 10?
In fact, I’m certain it will not work on the older agents. The RelayChain.txt tracking was added to the client in version 9.5.13, so this method will only work starting from that version.
I created a retrieved property using the tuple and it worked. Thanks so much! I still need a solution for clients between 9.2 - 9.5.12 though. Can anyone look at the download now command in Action 2 to see if there is anything? Is this a command that older clients are not able to do? The client I tested on is version 9.5.8.38.
I’d expect the ‘download now’ command probably just performs an HTTP GET without authentication, much as ‘curl’ would do. I don’t think I would expect the command to present its BES Client Certificate to authenticate just because the URL happens to be directed to its parent Relay.
Does ‘name of selected server’ return any usable values for you?
Otherwise, I think the most straightforward answers would be to upgrade your clients to a version that supports RelayChain storage, or turn off Relay Authentication on these client-facing Relays and block Internet access to those relays at the network perimeters.
@ifreeman will upgrading your agents to allow Jason’s Relay Chain retrieved property method work for you?
re: download now {“https://” & preceding text of last “.” of (it as string) of addresses whose (it as string starts with “192.”) of adapters whose (not loopback of it) of network & “.10:52311/RelayName.txt”}
I wonder what the client error log shows for the download command - perhaps “relevance Substitution Failed”
Perhaps a simplified version, just for troubleshooting? (substitute the correct IP address, of course) download now https://192.168.75.10:52311/RelayName.txt
This command failed as well with the correct IP filled in. So it’s not a problem with relevance substitution. I can get a look at the log file tomorrow.
The only options I can think of that remain get even more complex.
When you initially install the client, using your clientsettings.cfg, you could use another client setting to “tag” the location. That means using a different clientsettings.cfg for each site location.
If the information is available elsewhere in the Registry, you could pull it from there instead of using the Relay name to tag the clients.
If the information can be gleaned from the computers’ AD path or group membership, we probably have some options to work with that.
If you have the ServiceNow Data Flow integration set up and can identify those computers uniquely in ServiceNow, we could bring properties from ServiceNow to the client to tag them.
You could set up some other web service on the Relay hosts, running on a different port, with a page that displays the relay’s hostname, and access that page anonymously using the ‘download now’ command from the client.
One other approach I’m considering, is that even if we can’t authenticate to the Relay we can still retrieve its certificate.
The Certificate has a Subject Name that identifies the BigFix Computer ID of the Relay (but no hostname information). Unfortunately the version of curl that now ships with Windows doesn’t seem to have the ability to display certificate fields, but if you were willing to install an OpenSSL client for Windows it might be possible to run an action to probe the relay and retrieve the Relay’s computer ID based on the certificate it presents.
