Comment on page
StifleR controls access to the two main server components, i.e the SignalR Hub and the Web service. This control applies to both users (which required access to StifleR Dashboards) and StifleR Clients (who need to access the SignalR Hub).
Access to the StifleR Dashboards and WMI objects are controlled by Domain Group membership and StifleR Configuration file settings. These are described below:
AllowAnonymousReadis enabled (value of “1”) in the StifleR Configuration file, we allow all read operations and the following options are not in play.
Full Administrative Access to StifleR Server is restricted to Accounts that are members of a Global Administrators Group. This group is defined during the installation of the StifleR Server. These Global Administrators can then grant specific rights (read/write) over individual resources to Delegated Administrators. Delegated Administrators can only see and administer those Sites and Subnets over which they have been granted control. See table below for full details.
*StifleR Configuration file setting name
NOTE; Unless otherwise stated, the following settings can be found in the StifleR.Service.exe.config file which is located in the StifleR Server Installation folder.
AllowAnonymousSignalRConnectionsvalue is set to “1” – then any StifleR client can connect. This is default currently, as older StifleR Clients (pre- 188.8.131.52) are not capable of ANY authentication and would be rejected if this were set to “0”. This can be disabled by setting the
ConnectionSendCredentialsoption to “0” in the configuration file of the client.
The StifleR client runs as Local System (NT AUTHORITY\System)
If the client and the server are both in the same domain (or trusted), then the Local System account uses the computer account (hostname followed by a $ character, i.e. computer1$) to login on the remote computer. This can then be checked on the server side for limiting access, i.e. verify that the machines account (computer1$) is part of a specific group that gives the right access.
This is configured using the following settings
If the above is set, a second setting,
AgentGroupMembershipis then used to define the RequiredGroup. e.g.
Note: If the client or the server is not in a domain, or the trusted domain, then the Local System account uses ANONYMOUS LOGON. This cannot be verified against a group, and would fail if the server is configured with
If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access.
RequireAgentClientCertificate=”1”is set in the StifleR Config file, the client is required to attach a client certificate to the SignalR connection. This requires the
CertificateRootThumbprintvalues to be configured (added) with a thumbprint of a local certificate which is then present in the personal (MY) store in the local machine store location of the client. The first certificate in the store chain from that thumbprint is used.
The server will then verify the certificate. Failing to verify the certificates will return a 403 error to the requesting client.
NOTE: Client certificates have nothing to do with HTTPS usage, they are separate entities and HTTPS does not verify that the client can authenticate as client certificates do.
There is a further (less secure) method that can be used if you are unable to use Group membership of Client Certificates. This requires a client ‘token’ value to be configured on the server and client. The value for the Server Configuration is
RequestAgentTokenwhich should be configured with a string that will then be used by clients to connect (and should be treated like a password).
You can test access to StifleR using the following URL – which will list the group membership and access rights of the current user. The url should be as follows: