Applying the System Security Manager Settings to other Users

The SiteKiosk System Security Manager helps you to manage the restricted SiteKiosk user. The user is created by the SiteKiosk installer. It is a local standard Windows user account. The System Security Manager further restricts this account to increase the security of the kiosk terminal. The manager enables you to customize the restrictions for the SiteKiosk user to your needs. We strongly recommend to run SiteKiosk with this user, which is the default behaviour when using the Auto Start mode of SiteKiosk.

In case your kiosk environment requires the usage of another user you can do so by using the Customized start options of SiteKiosk. For those scenarios we recommend to use the default Windows options, e.g. local or domain policies, to secure this user to meet your project requirements.

If you want to apply the same restrictions to your user which the System Security Manager applies to the local SiteKiosk Windows user, you can use command line parameters for this. Please note that these parameters are unsupported and provided as is. Use the following information at your own risk. Also note that if you apply the restrictions to a domain user they might only last until the next periodic domain policy update on the computer, because domain policies always overrule local settings if they overlap.

The SystemSecurity.exe is located in the main installation folder of SiteKiosk Windows, e.g. C:\Program Files (x86)\SiteKiosk.

To open the graphical user interface of the SiteKiosk System Security Manager with a user of your choice, use the follwing command line parameters:

SystemSecurity.exe /user:<UserNameOrSID> /pass:<Password> /domain:<DomainName>

To apply the default settings used for the restricted SiteKiosk user to a user of your choice without using the graphical user interface, you can use the following command line parameters:

SystemSecurity.exe /applydefault /user:<UserNameOrSID> /pass:<Password> /domain:<DomainName>

User Logoff on Screensaver Activation or SiteKiosk Logout Button Usage

This script example is suited for environments where SiteKiosk is started when users login to the kiosk terminal with their individual accounts instead of the default SiteKiosk user and the terminal should return to the Windows login screen once the user leaves the terminal. In most cases this means domain environments.

Instead of using the standard Auto Start mode from the SiteKiosk Quick Start menu the Customized mode is used according to the needs of the specific kiosk environment. For example by choosing Run SiteKiosk automatically at Windows startup, unchecking Settings only apply to the restricted SiteKiosk user account and also leaving Disable any keyboard input during startup and Log on automatically at system startup unchecked, this leaves the kiosk terminal at the Windows login screen when turned on, where users can type in their credentials and SiteKiosk will start right after the login of the user.

In order for the kiosk terminal to return to the Windows login screen either when a user presses the default SiteKiosk logout button or the screensaver activates a small script can be added in the configuration tool of SiteKiosk.

The script uses the SiteKiosk Object Model and has this content:

SiteKiosk.OnReset = InitUserLogoff; // Requires the default Screensaver setting to execute a logout to be active

function InitUserLogoff(){
	//Wait 5 seconds to give SiteKiosk time to do the usual screensaver and logout processing, adjust if necessary
	SiteKiosk.Scheduler.AddDelayedEvent(5000, LogoffWindows);
}

function LogoffWindows(){
	//Run the Windows user logoff
	SiteKiosk.LogoffWindows();
}

The script uses the OnReset event to detect the usage of the logout button or the activation of the screensaver. Note that it requires the default screensaver behaviour to execute a logout to be active to work. In case the OnReset event fires, the function InitUserLogoff is called, which uses the AddDelayedEvent method to wait 5 seconds to give SiteKiosk time to perform the usual logout and screensaver actions. You can change the time to match your requirements. After the delay the LogoffWindows function is called, which uses the LogoffWindows method to initiate a Windows logoff while retaining the selected SiteKiosk start settings.

Copy and paste the above code to an editor, e.g. Notepad, and save it as a .js file in the Html subfolder of your SiteKiosk installation (usually located here: C:\Program Files (x86)\SiteKiosk\Html). To add the script to SiteKiosk, go to Start Page & Browser -> Customize -> Advanded and add it as an external script file to be executed on startup of SiteKiosk.

Minimum User Requirements for SiteRemote Server Database Backups

When using the database backup options of the SiteRemote Server Configuration Tool the resulting job will be added to the Windows Task Scheduler. The job requires a user account, the name of which you have to state in the Server Configuration Tool (using [server name or domain name]\[user name], e.g. SRServer\Backupuser).

In order for the job to run successfully the user you choose needs a minimum set of specific rights.

If you use a local SQL database (for the SiteRemote database) and you are not using the SQL Server Management Studio for backups, the user for the SiteRemote database backup needs db_owner rights on the SiteRemote SQL database (the default name of the database is SiteRemoteBackEndServer). Note that there are no special requirements for the user regarding the Mongo DB database used for the SiteCaster part of the server.

The user also needs read and execute rights for the Data and Mongo folders and their subfolders of the SiteRemote directory (by default C:\Program Files (x86)\PROVISIO\SiteRemote\Data and C:\Program Files (x86)\PROVISIO\SiteRemote\Mongo).

Of course the user needs write rights for the backup destination folder (by default C:\Users\Public\Documents\SiteRemoteBackups).

Finally, because the job is added as a Windows task, the user needs the Windows user right to log on as a batch job.


Note that the basics described above also apply to the new SiteKiosk Online Server. Paths and names need to be adjusted.

Using Different User Agents for Websites in SiteKiosk Windows Chrome Browser

For compatibility reasons or identification purposes it can be useful or even necessary to modify the user agent of the browser. You can do that for the browser as a whole in the configuration of SiteKiosk under Start Page & Browser -> Customize.

Replacing the whole default user agent string of SiteKiosk instead of just adding something to it is described here (Chrome) and here (IE).

But a modification that helps on one website can lead to problems on another website. So it can be useful to edit the user agent only for certain pages while on others the default user agent is used. You can do this with SiteKiosk Windows by editing the configuration file of SiteKiosk with an editor like Notepad. Look for urlSpecificUserAgents in the file and create entries for your URL(s). There are two options, you can either just add something to the default user agent of SiteKiosk or you can fully replace the user agent. 

This is how adding something to the default user agent for a specific URL looks like (as you can see, wildcards (*) are supported):

"url": "*whatsmyuseragent.org/*",
"userAgent": {
"add": "SiteKiosk Windows"
}

In this example SiteKiosk Windows is added to the default user agent for the specified page, while other pages receive the default user agent.

You can have as much different specific user agents as you need. This is how more than one looks like:

"urlSpecificUserAgents": [
{
  "url": "*.google.*",
  "userAgent": {
	"add": "Edg/$(ChromiumVersion)"
  },
  "url": "*whatsmyuseragent.org/*",
  "userAgent": {
	"add": "SiteKiosk Windows"
  }
}
],

The option to replace the full user agent string with a custom one looks like this:

"url": "*whatsmyuseragent.org/*",
"userAgent": {
"full": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 Edg/89.0.774.76"
}

This example uses the user agent string of Edge (Chromium engine).

Note that using a user agent that mimmicks another browser can lead to display problems with a webpage. Always test the settings before using them in your production environment.