Permissions
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).
User Access Control
Access to the StifleR Dashboards and WMI objects are controlled by Domain Group membership and StifleR Configuration file settings. These are described below:
If the AllowAnonymousRead is 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.
Group | Description | Access |
Global Administrators
| Full read and write right access to ALL objects | All (does NOT require Dashboard Access membership) |
Dashboard Access
| Access to dashboard and overview statistics only | Statistics, summary data etc. No WMI access |
Global Read
| Gives read only rights to ALL locations and statistics. Including WMI. | Read Access on ALL locations. Must be member of Dashboard Access also |
Location Administrators | Delegated Admin Role. Provides read (or write) access to individual locations. | Read /write access to only selected (defined) locations. Needs to be in Dashboard Access in order to connect to the dashboard system. |
*StifleR Configuration file setting name
StifleR Client Access Control
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.
No Authentication
If the AllowAnonymousSignalRConnections value is set to “1” – then any StifleR client can connect. This is default currently, as older StifleR Clients (pre- 1.9.7.4) are not capable of ANY authentication and would be rejected if this were set to “0”. This can be disabled by setting the ConnectionSendCredentials option to “0” in the configuration file of the client.
Group Membership
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
RequireAgentGroupMembership=”1”
If the above is set, a second setting, AgentGroupMembership is then used to define the RequiredGroup. e.g. AgentGroupMembership=”2PINT\StifleRClientAccess”
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 RequireAgentGroupMembership.
Certificates
If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access.
If 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 CertificateClientThumbprint and CertificateRootThumbprint values 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.
Client Token
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 RequestAgentToken which should be configured with a string that will then be used by clients to connect (and should be treated like a password).
Test Function
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:
http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test
Last updated