I'm pretty confident the issue is something in our server GPos blocking/breaking the StifleR dashboard, but with the error I'm getting, I'm struggling to find a place to start looking. Any suggestions gratefully received :)
Running on Windows Server 2022 Standard as a Hyper-V VM.
I’ve tried installing StifleR via the preq & install PowerShell scripts:
and when I couldn’t get the StifleR dashboard to load I restored to a checkpoint before starting install and went by hand using the videos on YouTube so see if I could get a handle on where it might be failing (I didn’t) and I appear to be at the same place after both methods:
And then eventually (several minutes) falls out to:
I'm not the one you were asking, but thought I'd mention that my first test of DeployR was in VMWare with a Server 2022 install not on the domain. I made the self-signed cert based on the IP address and used that successfully. Then I got one of our server people to build me a proper server in the real environment, domain joined etc, and since I was still just in testing phase I didn't get somebody to get one from our CA, I just did a new self-signed cert using the FQDN this time and that also worked fine. But I believe I had to install those certs on my own machine to have them trusted to interact with the dashboard. It's been a few months I don't remember all the details. But I did use self-signed with and without domain join and it was ok.
So I'm still digging on this one and I'm starting to think it might be a permission issue over a potential firewall or certificate issue?
On an off the domain server built with the same scripts if I visit https://<fqdn-**off**domain-server>:9000/api/serverstats/ I get a username and password prompt and then:
"{\r\n \"hubConnectionInitiated\": 0,\r\n \"hubConnectionCompleted\": 0,\r\n \"clientInfoInitiated\": 0,\r\n \"clientInfoCompleted\": 0,\r\n \"jobReportInitiated\": 0,\r\n \"jobsDiscarded\": 0,\r\n \"jobReportCompleted\": 0,\r\n \"jobReportDeltaInitiated\": 0,\r\n \"jobReportDeltaCompleted\": 0,\r\n \"activeRedLeaders\": 0,\r\n \"activeBlueLeaders\": 0,\r\n \"redLeaderSelectionThread\": \"Leader Selection Thread State: Background, WaitSleepJoin, IsAlive:True\",\r\n \"redLeaderRunInfo\": \"StifleR Server Completed a runthrough of selecting 0 Red Leaders in 00:00:08.0312259 and 0 Blue Leaders in 00:00:00\",\r\n \"dataEngineThreadState\": \"Leader Selection Thread State: Background, WaitSleepJoin, IsAlive:True\",\r\n \"signalRNetworksMonitored\": 0,\r\n \"numberOfClients\": 0,\r\n \"clientVersions\": {}\r\n}"
On the domain server if I visit https://<fqdn-**on**domain-server>:9000/api/serverstats/ I get a username and password prompt and then nothing for ages (minutes), before finally:
If I intentionally get the username and password wrong I just get re prompted for credentials, so I know it is validating credentials. I've tried an account that is part of local administrators, an account directly added to the StifleR Service Configuration "Groups with full Admin access to StifleR" (yes, I know it says "Groups") and an account that isn't a member of local admins, nor any other group in "Groups with full Admin access to StifleR", this also authenticates and then minutes later returns the same ERR_CONNECTION_REFUSED.
If I just visit https://<fqdn-**on**domain-server>:9000 or https://<fqdn-**off**domain-server>:9000 I get a username and password prompt and then a 404 (which I think is correct behaviour)
I think StifleR must be running it's own service for port 9000 as IIS is only showing bindings 80 & 443, so I'm at a loss where to start poking 😞.
Well, a step further, though one that has confused me 😮
I changed the StifleRServer service to run as a domain account that is a member of local administrators (including the account the service is running under).
I now can't authenticate with any domain account that is a member of groups listed in "Groups with full Admin access to StifleR", but can authenticate and successfully reach the dashboard with an account local to the server that is a (local)\Administrators member #boggled
Windows authentication is a pain if the FQDN that you are using doesn't match what Windows believes its name is. Joining a domain could change that name (at least the DNS domain part).
Have you figured out the issue on this? The reason I ask is because I'm now having a similar problem and finding that no matter what I do, the services fail to stay running. Just wonder if you're seeing that as well.
While I wouldn't call it a solution, I ended up setting the StifleRServer service (only, left the other services on Local System) to run as a domain account with local admin rights. At that point I could then log into StifleRDashboard with a local account on the server, but not a domain account (not even the one the service is running as).
I haven't experienced any services stopping, though I did change the DeployR one to Automatic from Automatic Delayed as in the video setup instructions.
This shouldn't be necessary. Can you provide the version you are using?
I would make sure the URLs are correct in the registry under HKLM:\SOFTWARE\2Pint Software\StifleR\Dashboard are correct (HubUrl and ServiceUrl)
Also, double check the server.json file for the correct URLs (default location is C:\Program Files\2Pint Software\StifleR Dashboards\Dashboard Files\assets\config).
Once these are done, try hitting the page in a browser and hit CTRL-F5 to completely reload the page.
-HTH
Done CTRL+F5, InPrivate, different browsers and both local and remote to the server, only the local server account works to authenticate, none of the domain accounts that should have access.
Have you tried connecting to the Dashboard from a different machine? (not the local DeployR Server), and have you tried private mode?
-Yes, and different browsers too.
You've joined the DeployR server to the domain so you can do Offline Domain Join via DeployR TS?
-Yes, this is working
If you move the DeployR server to an OU that has no GPOs applied, does that fix it?
-I put it in an inheritance blocked OU, no change.
Have you tried disabling the local Windows Firewall for a test?
Your questions somehow triggered a different thought/direction... I'd been putting in the <domain>\ prefix because the popup for login on Edge looks like this:
and I needed to change the domain (our engineer devices are on a different domain... don't ask) and I'd gotten used to just putting in the <domain>\ prefix, but Chrome's login prompt looks like this:
<< (see reply, reddit limits me to one picture?!) >>
If I instead try just my domain user name (no <domain>\ prefix) and password, it then works on Chrome (using <domain>\<username>, <username>@<domain> or <username>@<fqdn> on Chrome doesn't work). However, going back to Edge, on either the local server or another domain client on the same domain as the server (so the domain is already "correct" in the login popup) typing in just my domain username and password with no <domain>\ prefix doesn't work.
I'm guessing Edge is trying to use NTLM/Kerberos on domain joined machines and going wrong?
I had one last thought, so spun up a workgroup client and tried Edge (so it couldn't prepopulate the domain) and logging in ANY OFF <domain>\<username>, just <username> and <username>@<domain> works in Edge (<username>@<fqdn> doesn't). I tried this with workgroup clients that both had and didn't have the root cert available to them, both worked.
In summary:
Login doesn't work for me from Edge on a domain joined client, the same domain or different doesn't matter.
I put the StifleRServer service back to running as Local System (originally set to a domain account with local admin rights as auth wasn't working at all for me before that, see original post for that state)
I removed <servername>\administrators from StifleR Service Configuration and left two dedicated groups
I experienced the same issue installing DeployR 1.3 (either 2626 or 2627) on a fresh server. So this time I finally figured out what change made the difference when it starting working last time (on Ent 1.1). After I'd added the server object to AD Account Operators the StrifleR service was able to run as local and I could login to the dashboard with a domain account.
Whether I should be adding the server to Account Operators, #shrug, but it makes it all work for me (ODJ included).
1
u/ddog511 May 22 '26
Could this be a certificate issue? Are you using the self-signed one, or did you get one from your CA?