i probably can’t install anything on the clients and many are very old and don’t use PowerShell unfortunately. I really appreciate your efforts to help me creatively solve this problem.
this sounds like a possible solution. I will look into trying it this way. Thanks.
…and just as I was putting the finishing touches on a Task, but it requires PowerShell
action uses wow64 redirection {not x64 of operating system}
delete __createfile
createfile until EOF_EOF_EOF_EOF
$req = [Net.HttpWebRequest]::Create($args[0])
try {{$req.GetResponse()} catch {{$_.Exception.Response.StatusCode.Value__}
$req.ServicePoint.Certificate.Subject
EOF_EOF_EOF_EOF
delete GetRelayCert.ps1
move __createfile GetRelayCert.ps1
delete output.txt
waithidden cmd.exe /C "powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass -File GetRelayCert.ps1 https://{ip address of selected server}:{port number of selected server} > output.txt"
continue if {exists file "output.txt" whose (number of lines of it = 1) }
if {not exists setting "RelayServerCertSubject" whose (value of it = line 1 of file "output.txt" as string) of client}
setting "RelayServerCertSubject"="{line 1 of file "output.txt" as string}" on "{now}" for client
endif
This would have created a Client Setting that stores the Subject value of the Relay to which it is connected. For clients connected directly to the root, it’s of the form
OID.2.5.4.41=DBName:ServerSigningCertificate_0, OID.2.5.4.41=Type:Administrator, CN=ServerSigningCertificate_0
For a client connected to a Relay it shows something like
OID.2.5.4.41=ComputerID:1087305353
If you can’t install anything, and can’t run a PowerShell script, I think I’m out of options.
This is great. Many of my clients do use powershell and it should work for those. I really appreciate this!
This has been a real interesting problem, so I have one more possible thing to try…assuming your clients are on the same subnet as your relay, we should be able to pull the relay MAC address out of the ARP cache on the client.
If your clients are not directly-attached to the Relay though, they won’t get an ARP entry cached for the IP/MAC binding. So this is limited to clients on the same IP subnet as the Relay.
Like the Powershell-based task, this one creates a client setting that stores the MAC address of the relay/server that the client is using. This one only requires cmd.exe and the built-in OS commands ‘ping’ and ‘arp’
action uses wow64 redirection {not x64 of operating system}
delete output.txt
delete __createfile
createfile until EOF_EOF_EOF
REM ping relay for best chance of ARP caching
ping {ip address of selected server}
arp -a {ip address of selected server} > arp_out.txt
EOF_EOF_EOF
delete arp_out.txt
delete get_relay.cmd
move __createfile get_relay.cmd
waithidden cmd.exe /C get_relay.cmd
continue if {exists file "arp_out.txt" whose (exists lines containing (ip address of selected server as string) of it) }
parameter "SelectedServerMACAddress"="{substrings between "|" of concatenation "|" of substrings separated by " " whose (it as trimmed string != "") of (it as trimmed string) of lines whose (it as trimmed string starts with ip address of selected server as string) of file "arp_out.txt"}"
if {not exists setting "SelectedServerMACAddress" whose (value of it = parameter "SelectedServerMACAddress") of client}
setting "SelectedServerMACAddress"="{parameter "SelectedServerMACAddress"}" on "{now}" for client
endif
Using that value, comparing the MAC addresses of your Relays to the MAC addresses found by the clients, may give you some criteria you can use to tag your clients.
@JasonWalker
Interesting.
Use local client action to test ARP for the relay MAC… client and then know and report on it’s relay’s MAC address.
Relay also reports relay MAC address
Then we could correlate on the server side for which site is aa:bb:cc:dd:ee:11
It does sound like the network is simple and flat, so I am hopeful on this angle.
Given none of the creative workarounds are a 100% solution for you, I would guide towards temporarily turning Authenticating Relays off, run the existing solution and add on a client setting at the end to permanently leave the Relay Name on the client as a client setting, then turn Authenticating Relay back on.
Just now stumbling onto this, but I recently dealt with a similar wrangling of certificate contents.
This was on a 'nix, but you can pipe that output back into openssl and get just the fields you want:
% echo -n Q | openssl s_client -connect my-relay-server:52311 | openssl x509 -noout -issuer -serial -subject -dates
[snip]
issuer=CN = Client Certificate Authority
serial=REDACTED
subject=name = ComputerID:REDACTED
notBefore=Dec 1 01:41:28 2022 GMT
notAfter=Jan 3 01:41:28 2024 GMT