Account Management
One click to add, modify and delete user accounts across systems.
On multiple operating systems in your installation (UNIX/Linux, Windows, OpenVMS)
Acquiring a SysMan license
SysMan licenses can be acquired from http://www.sysgem.eu/registration-sysman.
The license comes as a text-file and is mostly named as '<licencee> License PAK (Base).txt', or just 'License.txt'.
After the license has been imported and SysMan has been restarted, it will show all features which it has been licensed for. Should you for any reason believe that these are incorrect, then please consult your distributor or reseller for advise.
Importing a license - Methods
To accomodate various needs, SysMan supports various ways to import a license.
All SysMan versions make use of Windows Management Instrumentation (WMI) for remote administration. By default, Windows allows inbound WMI queries from members of the Domain Admins group (when the remote machine is in a domain) and the built-in Administrator account (when the remote machine is in a workgroup).
Machines which are in a workgroup by default have inbound queries blocked by User Account Control (UAC), for all user accounts (except the built-in local Administrator account). UAC ensures that even if the account who is conducting the query is a member of the administrator-group, the connection is established in his normal-user-token. As a result, WMI is left with a lower privilege-level than what is needed to gather the requested information.
Below are examples on how remote administration through WMI could be set up for workgroup machines.
(Please note that all examples below involve reducing the overall security of the operating system in a certain way)
More information: User Account Control and WMI.
Method 1: Authenticate as the remote machine's local Administrator
Note:
It is stronlgy discouraged to use method 3 in production / live environments. Before falling back to disabling UAC completely, please consult any other means possible (like the ones written above), or even consider moving this machine in a domain environment after all. Domain environments are better manageable than workgroup machines.If SysMan is running in evaluation-mode, the trial-period automatically expires after an uninstall. When
SysMan is then re-installed, after starting the user-interface, the client would then show a License
Expired message like below.
To keep (or extend) you evaluation-period, either:
The Sysgem Password Management documentation can be downloaded here.
Host Management
Usage of tools against the remote system
(for instance, showing the list of running services running on a remote machine)
All SysMan versions make use of Windows Management Instrumentation (WMI) for remote host administration. Therefore SysMan needs Windows Management Instrumentation enabled in the remote machine's firewall.
| Name | Program | Services | Protocol | Local Port | Remote Port |
|---|---|---|---|---|---|
| Windows Management Instrumentation (DCOM-in) | svchost.exe in %systemRoot%\system32 | Remote Procedure Call (RPC) - RpcSs | TCP | 135 | Any |
| Windows Management Instrumentation (WMI-in) | svchost.exe in %systemRoot%\system32 | Windows Management Instrumentation - Winmgmt | TCP | Any | Any |
| Name | Program | Services | Protocol | Local Port | Remote Port |
|---|---|---|---|---|---|
| Windows Management Instrumentation (DCOM-in) | svchost.exe in %systemRoot%\system32 | Remote Procedure Call (RPC) - RpcSs | TCP | 135 | Any |
| Windows management Instrumentation (ASync-In) | unsecapp.exe in %systemRoot%\system32\wbem | Any | TCP | Any | Any |
Note:
The Sysgem WMI provider is not running as a service. Therefore, when it is not actively handling a request, it is not using any resources.| Program | Protocol | Local Port | Remote Port |
|---|---|---|---|
| SysgemRC.exe in <installation path>\Sysgem AG\Sysgem Remote Control Server | TCP | Any | Any |
| SysgemRC.exe in <installation path>\Sysgem AG\Sysgem Remote Control Server | UDP | Any | Any |
| Name | Program | Protocol | Local Port | Remote Port |
|---|---|---|---|---|
| File and Printer Sharing (NB-Datagram-In) | System | UDP | 138 | Any |
| File and Printer Sharing (NB-Name-In) | System | UDP | 137 | Any |
| File and Printer Sharing (NB-Session-In) | System | TCP | 139 | Any |
| File and Printer Sharing (SMB-In) | System | TCP | 445 | Any |
Note: XP MACHINES ONLY
If the remote host is an XP machine, then for push installations to be possible, the 'simple file sharing' feature needs to be disabled.Defining a new alarm or modifying an existing shows various options disabled on the Actions-pane. These options would be a script to run, e-mail to send and SMS to send.
When running SysMan Utilities, this is correct.
These features are reserved for SEM Enterprise Manager usage.
The Sysgem Access Gateway dcumentation can be downloaded here.
The Sysgem WMI Provider is a piece of software that is installed on a target machine and used only by the SysMan set of tools. Please note that it is not running as a service. Therefore, when it is not actively handling a request, it is not using any resources.
By default, the WMI-provider is installed remotely on request.
For some reasons though, one might want to revert to a manual install locally.
The WMI-Provider is no more than a DLL file which can be copied over between machines and registered as normal in Windows without the need for a reboot on the source- or target-machine..
How-to:
Code: Select all
regsvr32 <path>\SysgemWMIProvider.dllNote:
To quickly include the path and the DLL-file, drag the SysgemWMIProvider.dll-file from the explorer window in the command-prompt window.
The following list shows software and applications that we know of to be incompatible with the SysMan Remote Control Server service
VNC Server on the same machine
The SysMan RC server can not co-exist with a VNC server on the same machine. If you have found yourself in that situation, you need to uninstall one of them in order for the other to be able to operate.
This article discusses the requirements and techniques for providing data to the SEM Dashboard from custom displays. If you are not already familiar with the SEM Dashboard, it is recommended that you read the relevant Getting Started guide to better understand how the Dashboard works before continuing.
Download the SSyM Dashboard module
The current release of the SSyM Dashboard module is 2021-11-16.
The SEM Dashboard allows administrators to quickly configure monitoring and alerting within their SEM environment. This is done by way of selecting a number of probes that should be measured on relevant agents; the Dashboard system then automatically runs the appropriate SEM displays on those agents to obtain the requested probe data, and then concentrates it into a central database for passive display or interrogation by users. In order for this to work, the various displays that gather information need to be extended to be ‘Dashboard-aware’; at a minimum, this means defining and implementing the Dashboard probes. The following sections describe the steps involved in extending a display to work with the Dashboard.
The features described in this article require the following component versions:
| SEM Component | Minimum Required Version |
|---|---|
| SEM Management Console | Build 8640 (of either version 2.3 or 3.0) |
| SSyM Dashboard | 20211011 (release date 11-Oct-2021) |
Before you start working with any displays, it is worth taking some time to consider which information will be most useful in the Dashboard. The following characteristics of a Dashboard probe are useful when deciding whether a given statistic is suitable for reporting:
Some probes may not naturally meet all these criteria, but can be made to fit into them when considered in the context of how alerting would be configured. For instance, one of the probes included with the Dashboard is ‘Prohibited Processes (Windows)’ - this is used to alert when a certain process name is active on a Windows agent, and works by matching the item name configured for the probe instance against the process list and reporting the number of running instances. Alerts can then be triggered if this number is greater than 0; in this way, the probe meets criteria 1, 3 and 4, and is actually monitoring to ensure criterion 2 is met!
Once you have decided which statistics you wish to report to the Dashboard, you can assemble the required information for defining the probe. This is described in the next section.
Probes are defined using a new SEM feature called Introspection, which was introduced in build 8549 of the SEM framework. Introspection allows a SEM display to include a number of Introspection Aspects, which describe aspects of the display that the rest of the SEM system might want to discover automatically - in this case, each probe a display can gather data for becomes one aspect defined in that display.
To define a probe, open the display in the Custom Display editor as usual, and select the Introspection page in the sidebar. That will display an editor pane such as the following:
Click on the Add button in the toolbar and choose Dashboard Probe when prompted to select an aspect template; this will add a new probe to the list of aspects on the left, and open it for editing in the table on the right:
Fill in the details for the new probe; the editor pane provides information on each field as you move through them, but the fields required are as follows:
| Field | Description |
|---|---|
| Probe Name | The name of the probe, as displayed in the Dashboard and its wizards |
| Probe Group | The name of the group to show the probe under in the Dashboard |
| Advanced | Checked to indicate that the probe should be hidden from the Add New Monitoring Policy wizard by default, and only shown if advanced options are requested |
| Items Supported? | Checked to indicate that the probe represents a number of items on an agent rather than the state of the agent as a whole |
| Item Syntax Hint | A prompt string displayed to the user to indicate the format of item names for this probe (e.g. this might be ‘C:, / or DKA100:’ for a probe relating to disks) |
| Unit | The unit suffix to be displayed after a probe value (e.g. ‘MB’ or ‘ items’ - leading whitespace is supported) |
| Alert When Below | Checked to indicate that a lower value is worse for this probe |
| Default Update Interval | The default number of seconds between updates of this probe data |
| Default Alert Threshold | The default value above/below which the probe should be considered in Alert state |
| Default Warning Threshold | The default value above/below which the probe should be considered in Warning state |
| Default Hysteresis | The default amount the probe needs to move back away from the alert/warning thresholds to drop back to a less-severe state; this is used to avoid an oscillating value that straddles a threshold causing duplicate alerts |
The four 'default' parameters should be chosen to be sensible starting points for a new monitoring policy, but can be overridden as required by the user once they start to configure instances of the probe. The other parameters cannot be overridden by the user as they are considered intrinsic to the definition of the probe itself.
Once the form has been completed, click Save to store the definition. If you have multiple probes to define, you can either repeat the process by following the above steps again, or alternatively using the Batch Add… button in the template selection list to create several aspects from the same template in one go. Using this option will allow you to provide a list of probe names; these bulk-created aspects can then be edited individually to provide the rest of the probe details as required.
To provide data to the Dashboard, the post-processing script of the relevant displays needs to be extended to gather the correct information and pass it to a routine defined in the Dashboard Integration Class. To simplify this process, the Dashboard provides an include file called Dashboard_Update; this include file defines a number of Perl subroutines, with the most important of these also being called Dashboard_Update.
The Dashboard_Update subroutine expects the following parameters:
The simplest example of using Dashboard_Update can be found in the CPU Top Processes display. This display reports a single probe value - CPU Usage in percent - for each agent; since it has to calculate this differently for each supported agent platform, a global $dash_value variable is set in each platform-specific section of the post-processing script. After all processing is completed, the following code sends the calculated value to the Dashboard:
#include Dashboard_Update
if ($LOOP_COUNTER > 0 && Dashboard_Enabled)
{
Dashboard_Update($server_name,
"CPU Top Processes",
["CPU Usage"],
"" => [$dash_value] );
}
The main points to note here are the parameters to Dashboard_Update - the agent name taken from a variable provided to the script by the SEM framework, the display name, the list of probe names (containing just the one entry, “CPU Usage”), and finally the data hash. This hash has one key (the empty string, representing the agent as a whole) and its associated value (a list of probe values, again containing just the one CPU usage figure).
In addition, notice that the Dashboard_Update call is guarded by a conditional which checks both that the display is running in a Dashboard context (the Dashboard_Enabled condition) and that it has valid data to return ($LOOP_COUNTER is greater than zero; it’s only on the second and subsequent cycles of the display that the display can calculate CPU usage over the elapsed interval).
To illustrate a more complex scenario, consider the following code taken from the Dashboard-compatible version of SSyM’s Disk Usage display:
#
# Dashboard support
#
#include Dashboard_Update
my %dash_data = ();
my $dash_pcused, $dash_mbfree, $dash_device = "";# ... omitted for brevity ...
foreach $line (@input_array)
{
my $prefix = substr($line,0,5);#
# Gather statistics for the Dashboard
# (% Used is stored when calculated below)
#
if ($prefix eq "DV : ")
{
$dash_device = substr($line,5);
}
elsif ($prefix eq "FM : ")
{
$dash_mbfree = substr($line, 5);
}
elsif ($line eq "@" && $dash_device ne "")
{
$dash_data{$dash_device} = [ $dash_pcused, $dash_mbfree ];
$dash_device = "";
}# ... omitted for brevity ...
$pc = sprintf "%d", 0.99999 + (($used * 100) / $size);
$fp = 100 - $pc;$dash_pcused = $pc;
# ... omitted for brevity ...
}Dashboard_Update($server_name, "Disk Usage", ["Percentage Used", "Free Space"], %dash_data);
Here we can see that some data values are pulled directly from the display data ($dash_device and $dash_mbfree), and another is taken from a calculation that was already being performed ($dash_pcused). These values are remembered as the post-processing script works through the agent output, and stored in the %dash_data hash (keyed by $dash_device) once the end of each display row is found (the ‘$line eq "@"‘ conditional). Once the entire input array has been processed, the collected data is handed directly to Dashboard_Update; notice that this time the list passed as the third parameter contains two probe names, corresponding to the list consisting of the $dash_pcused and $dash_mbfree values that was previously stored in each hash entry.
For displays that may need to perform more complex operations on the data before sending it to the Dashboard, it may be useful to make use of the other routines defined in the Dashboard_Update include file. We have already seen Dashboard_Enabled used to check whether a display is running in order to obtain Dashboard data or not; if finer-grained information is required, for instance to avoid particularly expensive processing for some probes that isn’t required for others, the following additional routines are available:
Dashboard_AllRequiredProbes returns a list of probe names that the Dashboard wants the display to gather data forDashboard_AgentsWithProbes returns a list of agents that the Dashboard wants the display to gather data from (although this will currently be identical to the list of selected agents for the display, this call is provided in case this assumption changes in future versions)Dashboard_ProbesForAgent($agent_name) returns a list of probes that the Dashboard wants the display to gather data from the specified agent forDashboard_ItemsForProbe($agent_name, $probe_name) returns a list of items on the given agent that the Dashboard wants to gather the specified probe data forThe last of these routines is particularly useful where a display may return data for a lot of items but only a few of them are likely to be of interest to the Dashboard. An example of this is the Windows Processes display, which supports the ‘Required Processes’ and ‘Prohibited Processes’ probes; these probes both need to be configured with a process name, and the display uses the Dashboard_ItemsForProbe routine to provide the Dashboard with a count of instances of each configured process name.
Once you’ve defined the relevant Introspection Aspects for your probes and implemented the necessary code to gather the corresponding data, your Dashboard installation will need to be refreshed so that it can discover the new probe definitions. This is done using the Maintenance -> Update Available Probe List menu item in the main Dashboard display; selecting it will display the following form:
The ‘refresh existing probes’ option should be selected if you have made changes to any Introspection Aspects that were previously registered with the Dashboard; it makes sure that the probe details held in the Dashboard database match those defined in any loaded displays. If you don’t select this option, only probes that did not previously exist will be copied into the Dashboard database; this can be quicker when you know that only new probes have been added.
After clicking OK, the operation will return statistics regarding how many new probes were discovered and how many existing ones were refreshed, if applicable. You can now close the menu window and use the Add New Monitoring Policy wizard to create monitoring policies that use your new probes. Bear in mind, though, that the SEM Service Displays service responsible for running the Dashboard monitoring displays will need to be restarted in order to load your updated displays before the probes will operate!
The easiest way to test your new probes is just to create a monitoring policy and wait for the new statistics to show up in the Dashboard display; this should only take a few moments (assuming the SEM Service Displays service has been restarted since the last change to your displays).
When developing new probes, however, especially in more complex displays, you may find you need to test and debug your code in a running SEM environment rather than as a ‘black box’ background process. Unfortunately the Dashboard does not currently offer an easy way to isolate certain displays for this purpose; if you were to start the Dashboard Central Controller display manually, it will probably go into its ‘standby’ mode where it does nothing except monitor the status of the background process. Once you stop that background process the interactive session will take over - but it will promptly launch every display required to handle your monitoring configuration, not just the ones you want to work with!
The two approaches currently available to deal with this situation are:
We acknowledge that this is a shortcoming of the current release of the Dashboard environment, and are working on improving the development and testing experience for a future update!
The Sysgem WMI Provider is a piece of software that is installed on a target machine and used only by the SysMan set of tools. Please note that this concerns a registered DLL file only. I.e. it is not running as a service. Therefore, when it is not actively handling a request, it is not using any resources.
Should there be a requirement to remove the file and registration from the node, then please perform the exercise below.
How-to:
Code: Select all
regsvr32 /u <path>\SysgemWMIProvider.dllNote:
To quickly include the path and the DLL-file, drag the SysgemWMIProvider.dll-file from the explorere windo in the command-prompt window.
This article is all about the 'No security keys defined’ message, which in some circumstances could appear when trying to start or log in SysMan:
Quick fix:
Note:
Please note the difference between applying the 'Kn' parameter in step 3 and 4 (with and without the '=' sign).Note:
The above commands assume that the standard security-key (i.e. 'SysMan’) is used. If you have overwritten the standard security key with another, then please apply that key in the commands above.SEM 3.0 Management Consoles from build 8554 onwards include support for running within a web browser, using Cybele Software’s Thinfinity VirtualUI product. This article describes the steps required to evaluate this configuration or make SEM available to end users in this fashion.
There are two licensing considerations to be taken into account when using SEM under VirtualUI; most importantly, VirtualUI uses a per-seat licensing system, so sufficient licenses will need to be purchased (either via Sysgem or directly from Cybele Software) to cover the largest anticipated number of concurrent users. A free trial license is available for evaluation purposes.
Secondly, SEM’s VirtualUI support is a separately-licensed option, so your SEM license will need to include the VirtualUI option; please contact Sysgem or your distributor to discuss adding this option to your existing license if needed. VirtualUI support is currently not enabled by default for SEM trial licenses but can be added on request.
The SEM Management Console should be installed in the usual fashion on the server or servers which will be hosting the VirtualUI environment. This can be done either before or after installing VirtualUI itself; however, installing SEM first does allow you to install the required SEM license before attempting to start SEM within VirtualUI.
For a first SEM installation, or evaluating VirtualUI in a standalone environment, the SEM Authorization Server can also be installed on the same server; however, this isn’t necessary if the VirtualUI clients are to be connected to an existing SEM installation.
The Thinfinfinity VirtualUI package can be downloaded from Cybele Software’s downloads page, and installs as a standard Windows application; the required options will depend upon your environment and requirements but for an initial installation we recommend selecting the VirtualUI Server option (there is no need to install the Development Environment) and then installing ‘all components’. For larger deployments it is possible to configure load balancing across several application servers, as described in the VirtualUI documentation, but during your initial evaluation of the environment this is unlikely to be necessary.
Once installation has completed, start the Thinfinity VirtualUI Server Manager from the Start menu. This will prompt you to register your VirtualUI license, or create a trial license; once this has been completed, the Server Manager will appear. This should show a default web server configuration (‘binding’) for HTTP port 6580 on all addresses and hostnames; if not, click the Add button followed by OK to create one with these defaults. Tick the ‘allow external access in Windows Firewall’ checkbox to allow users access to the web server, then click Apply to update the running configuration:
You should now be able to visit http://localhost:6580/ from the server where VirtualUI has been installed, and see a default application list containing icons for the Thinfinity VirtualUI documentation. If not, please contact Sysgem or Cybele for further assistance with installation and configuration.
Once the initial VirtualUI configuration is complete, you can publish the SEM Management Console to web users by creating an entry for it in the Applications tab of the Thinfinity VirtualUI Server Manager. The simplest way to do this is to click the Add button, then the Open button next to the ‘Program path and file name’ field of the General tab in the resulting dialog box. In the file chooser that appears, browse to the SEM installation directory and then select the SEM Management Console\SEM Client.exe file; confirm the choice and then press OK to select the default icon in the following dialog box. This will populate some default options for the application entry; however, we recommend that you remove the tick from the ‘Allow browser arguments’ checkbox, and also change the ‘Name’ field at the top of the window to read ‘SEM’ rather than ‘SEM Client’ for consistency with SEM’s usual Start menu entry:
Once happy with your settings, click OK to save the new application entry and then Apply to update the running VirtualUI service with your changes:
You should then be able to visit (or refresh) the http://localhost:6580/ page again to see the new SEM icon in the application list:
Clicking on the SEM icon should, after a moment, display the normal SEM login dialog box. Log in as usual and you should find SEM starts and operates in the same way as it does when running as a standard Windows application; if instead you receive an error regarding your SEM license not supporting VirtualUI, please contact Sysgem to discuss licensing options.
By default, VirtualUI allows anonymous, unauthenticated users to access the available applications, and will run these applications within the context of whichever user is currently logged in to the Windows desktop on the VirtualUI server. Whilst this may be a reasonable configuration for a simple test environment, in a production (or larger-scale evaluation) scenario it is likely that better security controls should be configured.
The available controls come in several layers: user permissions to access VirtualUI, user permissions to access individual applications such as SEM, and the user credentials used by VirtualUI to run the application on the user’s behalf. For each of these, there are several options available within VirtualUI; a full discussion is beyond the scope of this article, but a basic configuration that could serve as a starting point is described below. More details on the available options can be found in the VirtualUI documentation.
The first consideration is the user account under which the SEM Management Console will be run when accessed via VirtualUI. The default, as mentioned, is to borrow the current console session on the server; it is also possible to use a nominated account (such as a dedicated service account), or if authentication is enabled to use the relevant Windows account for each user’s session. This is configured on the Sessions tab in the Thinfinity VirtualUI Server Manager; the default is for all VirtualUI applications to share one Windows session, which can be either the console user or a nominated account.
Alternatively, selecting the ‘One Browser per Windows Session’ mode (as shown above) allows a nominated account or the VirtualUI user’s credentials to be used instead. Sysgem recommend using this final option for any substantial deployment, as it provides the best isolation between users and also avoids any clash of settings should SEM be configured to save them locally instead of on the Authorization Server.
The second step, which is optional unless the ‘logged-in credentials’ option described above is in use, is to select an authentication method to be used when logging in to VirtualUI. The simplest method is most likely to be Windows Logon authentication, which allows users to log in with their usual Windows credentials; since VirtualUI uses Active Directory objects as the basis for its access controls, this simplifies configuration by allowing you to leverage existing security groups, etc. whereas other authentication types require an additional mapping layer to be maintained.
Authentication types are configured on the Methods subtab under the Authentication tab in the Thinfinity VirtualUI Server Manager; initially the methods list is empty, but clicking the Add button will allow the Windows Logon authentication methods to be enabled. Once one or more authentication methods have been selected, the ‘Allow anonymous access’ checkbox can be cleared to force users to log in before using any VirtualUI application:
In Sysgem’s testing, we have found the ‘Use standard browser authentication dialog’ checkbox to be a useful setting; the normal VirtualUI login form did not always behave as expected, although this may have been fixed by the time of publication.
It is also possible to restrict anonymous access to SEM in particular rather than VirtualUI as a whole; this is configured in the Permissions tab of the SEM application entry, by clearing the ‘Allow anonymous access’ checkbox and then adding one or more users or groups to the list below:
Setting such a configuration will make the SEM icon appear within VirtualUI only for users granted access; it will be hidden from any other users, or anonymous users if they are allowed by the global configuration.
VirtualUI includes built-in support for two-factor authentication (2FA), with multiple 2FA providers available and able to be associated with any selected authentication method. To use this support, first enable one or more 2FA providers on the 2FA subtab under the Authentication tab in the Thinfinity VirtualUI Server Manager, and then select the relevant provider for each authentication method selected on the Methods subtab:
Finally, ensure the 'Use standard browser authentication dialog' checkbox is not ticked, so that VirtualUI's login page can handle 2FA requests as needed. Where required, users will be prompted to configure their 2FA authenticators during their first VirtualUI login.
However, it should also be noted that all releases of SEM 3.0 that support VirtualUI also support SEM's own 2FA extensions, which will apply the same 2FA requirements to all SEM users whether logging in via VirtualUI or directly on a Windows workstation. More information about configuring SEM's built-in two-factory authentication can be found in the related Knowledge Base article.
Although the SysMan Remote Control service can be installed remotely from within the SysMan applications, circumstances might require the service to be installed manually or through a 3rd-party software-distribution. We have provided the means for a manual install through a MSI-installer-package which can be distributed over the machines in question.
How-to:
Note:
The settings applied here can be changed after installation.This article discusses how to register a SysMan Professional client with a SysMan Authorization server.
For any additional information, please consult the SysMan Professional Installation Guide.
A brief introduction: Authorization Server versus Management Console
The SysMan Professional Edition comes with two components:
Note:
Please note that installation keys can only be registered once. A new key needs to be issued for every client registration.Code: Select all
"C:\Program Files (x86)\Sysgem\SysMan Authorization Server\SEM AuthServer.exe" -SS0 SysManCode: Select all
"C:\Program Files\Sysgem\SysMan Authorization Server\SEM AuthServer.exe" -SS0 SysManNote:
The above procedure assumes that the standard security-key (i.e. 'SysMan’) is used. If you have overwritten the standard security key with another, then please apply that key instead.Code: Select all
"C:\Program Files (x86)\Sysgem\SEM User Interface\SEM Client" -u=<authserver>:<port>:<installation key>Code: Select all
"SEM User Interface\SEM Client.exe" -u=10.95.1.114:7240:NXYJ-LHZQ-BWB9-G932-ZP9T-LFR6-F8XYCode: Select all
"C:\Program Files\Sysgem\SEM User Interface\SEM Client" -u=<authserver>:<port>:<installation key>This article discusses Two-Factor Authentication (2FA) support in Sysgem Enterprise Manager (SEM).
2FA support is available in SEM version 3.0, from build 8206 onwards. For technical reasons it is not possible to make 2FA support available in SEM version 2.3 or earlier.
If you are running SEM version 2.3 but wish to add 2FA support to your SEM installation, please contact Sysgem to discuss an upgrade to SEM version 3.0 – in most cases this can be as straightforward as installing a version 2.3 update, but version 3.0 includes other new features you may wish to be aware of when planning an upgrade.
Build 8206 of SEM includes support for two authentication methods:
In both cases users can use smartphone apps such as Google Authenticator to authenticate themselves during login; such apps are configured either by scanning a QR code or by manually entering the authentication details provided by SEM. There is currently no support for enrolling hardware tokens with known key material; if this is a feature that would be of interest in your environment, please contact Sysgem.
Note that not all authenticator apps support HOTP properly – for instance, the Microsoft Authenticator app will silently accept a QR code that specifies HOTP authentication but then handle it as TOTP instead. As a result, Sysgem recommend using TOTP-based authentication unless you have specifically validated HOTP-based authentication in your environment.
In order to make use of 2FA, your SEM Authorization Server and Management Consoles must all be version 3.0 build 8206 or later. You can still use older Management Console builds to log in to the build 8206 Authorization Server, as long as 2FA has not been enabled for the relevant SEM user account; if it has, the login attempt will be rejected.
There is no need to upgrade any SEM Agents, Proxy Servers or application modules to make use of 2FA.
The SEM Authorization Server stores all 2FA-related authentication data in an ODBC database; Sysgem recommend that a SQL Server database be used for this purpose, both so that it can easily be shared between multiple Authorization Servers (e.g. a primary and a disaster-recovery server) and because this data is critical to ensure availability of the SEM application once 2FA has been enabled. However, for evaluation or demonstration purposes, SEM can also create and make use of a simple Microsoft Access database for 2FA details.
Since such ad-hoc databases might escape your organisation’s backup or data security policies, and cannot be shared between Authorization Servers easily, Sysgem do not recommend using this Access database for production systems.
Before SEM’s 2FA support can be used, it must be explicitly enabled on the SEM Authorization Server. This is done using the new Two-Factor Configuration utility, which can be found in the Authorization Server’s installation directory or in the Sysgem folder of the Start Menu on the computer where the Authorization Server is running.
Starting this utility will display the following dialog box:
The General tab will be selected when the utility starts, and allows the global 2FA options to be selected:
Setting the ‘Require Two-Factor Authentication for all logons’ option when there are no users enrolled for 2FA will prevent you from logging in to SEM! In this case, you can clear either the ‘Require’ or ‘Enable’ settings, log in to SEM normally and then re-enable 2FA and enrol a new user, as described in the following section.
The Database tab allows you to configure the authentication database used for 2FA, and will show the following details by default:
Note the error shown in the Status field, indicating that the authentication database does not yet exist. For testing and evaluation purposes the Create button will allow you to create a temporary Access database; once you have confirmed a message reminding you that such configurations are not intended for production use, the Status field will be updated to indicate the availability of the database:
For production use, Sysgem instead recommend using an SQL Server database. The ‘Open ODBC Data Source Administrator’ and ‘Open Services Control Panel’ buttons are provided to help with performing the required configuration, as follows:
Finally, the OTP Authentication tab allows the TOTP and HOTP authentication methods to be configured. You can select which of these are available to users, for instance allowing you to disable HOTP if your users will be using the Microsoft Authenticator app:
Once the Authorization Server has been configured to support 2FA, enrolling users with the available 2FA providers is done through the SEM Management Console. As with any other SEM user management tasks, only users with the Manage Access Control profile permission can alter another user’s settings; this permission is usually granted to the System user, as part of the Full Access profile, so log in to the Management Console as System or another suitably-privileged user and use the Managers -> SEM Users -> Accounts option to display the User Accounts manager. Double-click on a user to open the Modify Account window:
Clicking the Two-Factor Authentication button will open the user’s 2FA settings:
Here we can see that the user is not enrolled with any 2FA providers, so click the Add… button to start the Enrollment Wizard:
Select the 2FA type to enrol with, and click Next. The following screens may vary based on the 2FA type; the examples given here are for TOTP authentication.
Provide a friendly name used to refer to the user’s TOTP authentication token in prompts and click Next.
Scan the QR code with your authenticator app; if your app does not support QR codes or the code is not recognised, you can also follow the link to the manual setup details that should be entered into the authenticator instead:
Once you click Finish in the wizard, you are returned to the user’s 2FA settings; the new authentication method is listed, and will be shown in bold to indicate that it is the default authentication method for the user. Tick the ‘require two-factor authentication’ checkbox to enable 2FA for the user:
Click OK on this dialog, the Modify Account dialog, and the User Accounts manager. You can now start another SEM session and attempt to log in as the newly-enrolled user; you should be prompted to authenticate using the new TOTP token:
In most cases, users should be allowed to enrol themselves with 2FA providers, rather than relying on SEM administrators to enrol them – particularly as the enrolment process requires access to the device and app the user will be using for authentication!
There are two new profile permissions that control what 2FA settings a user can manage on their own behalf; these are ‘Enroll/de-enroll own Two-Factor Authentication methods’ and ‘Enable/disable Two-Factor Authentication for own account’. These permissions will not have been enabled by default after upgrading to build 8206, so use the Managers -> SEM Users -> Profiles option to grant these permissions in the profiles used by the relevant SEM users:
You do not have to grant both permissions; for instance, to specify that certain users must log in using 2FA, grant the them ‘enroll/de-enroll’ permission but not the ‘enable/disable’ permission. This will allow users associated with that profile to control how they authenticate (by setting up their own authentication methods) but not disable 2FA (which you can enable on a per-user basis through the User Accounts manager, or globally through the Two-Factor Configuration utility on the Authorization Server).
When a user has been granted either of these permissions, a new ‘Two-Factor’ button is available in the user’s Tools -> Change Password dialog. This button brings up the same Two-Factor Authentication Settings window available through the Modify Account window, from which a user can make whichever changes their profile settings allow.
SEM allows each user account to be enrolled with any number of 2FA providers; this can be used to provide a fallback authentication method for critical accounts in the event that their usual authenticator device becomes unavailable.
To do this, simply repeat the enrolment process for each additional authentication method; the additional enrolments will appear in the list alongside the default authentication method:
SEM will always prompt for the default authentication method first when logging in. The authentication method list shows this default option in bold. To change it, select the desired default in the list and click Set Default.
When multiple authentication methods are available, the 2FA prompt shown during login will include a link to select an alternative authentication method:
Selecting this link instead of answering the authentication prompt will display a list of available authentication methods; select the desired method in the drop-down and click OK to restart the authentication process using the new authentication method.
Note that currently SEM only requires that user be able to authenticate themselves using any one of their available authentication methods. As Sysgem extend SEM with authentication methods beyond OTP apps, it may become possible to designate certain methods as necessary but not sufficient – e.g. to require both an OTP code and an authentication e-mail address for the System user.
To disable all notifications on the RC Server, set its parameters as written below. Thereafter, restart the
RC Server service to apply the new settings.
Note:
The user sitting at the remote desktop will not be made aware of a session being initiated. Make sure this configuration does not compromise your company-policy in relation to monitoring user’s desktops.Note:
The RC Server connections will still be logged on the remote machine.The Sysgem SysMan Utilities and Remote Control documentation can be downloaded here.
This article is taken from the user guide for the SSyM Dashboard, a new feature that extends SSyM System Manager to provide automatic background monitoring and an at-a-glance status overview of critical systems. It is provided here in the Knowledge Base to allow interested customers to learn about the Dashboard concepts before downloading and trying the SSyM Dashboard for themselves.
Download the SSyM Dashboard module
The current release of the SSyM Dashboard module is 2021-11-16.
The core of the SSyM Dashboard is the new Dashboard display, which provides summary and detail information relating to all systems that have been configured for monitoring. All configuration takes place through this display, but the monitoring itself is handled by the Central Controller which runs as a Service Display — a display running in an unattended SEM session that itself runs as a Windows service on one or more monitoring servers.
Monitoring data is held in a central Dashboard database, and the latest status can be viewed from any SEM Management Console at any time. From the status view, the user can drill down into the standard SSyM monitoring displays (if they are available to the user) to see further real-time information and, where possible and appropriate, take corrective action.
This release of the SSyM Dashboard module is intended to be a stable release for customers interested in learning about or evaluating new functionality that will be added to SSyM System Manager in a future release. We are still working on adding new probe types and refining the Dashboard functionality based on user feedback so we encourage you to experiment with the Dashboard and let us know what you like and dislike about it, and what you'd like to see in future releases.
The Dashboard makes use of various SSyM System Manager displays as data sources; in this release, copies of these displays have been included in the Dashboard module and modified to include the support for reporting Dashboard probe status. You should be aware that the displays in the Dashboard module are not quite identical to the displays found in the current release of SSyM System Manager, so should not be considered interchangable — the displays in the Dashboard module will be used by the Dashboard functionality, but for interactive use you should continue to use SSyM System Manager as before.
(In some cases, the versions of the SSyM displays included in the Dashboard modules also include changes or bug-fixes that are still being tested for inclusion in a future release of the SSyM System Manager module. If you use these displays interactively, please be aware that they may report different values than the standard displays.)
A forthcoming SSyM System Manager release will incorporate the Dashboard and related modifications to existing SSyM displays, at which point the SSyM Dashboard module will be retired. This will not affect the existing Dashboard functionality or configuration.
This section provides a brief introduction to the SSyM Dashboard, guiding you through initial installation and configuration. For more details, full online help is provided within the Dashboard displays; this can be accessed via the Help icon in the SEM Selection Window, display windows or menu dialogs.
The SSyM Dashboard is an automated monitoring system built around the concept of monitoring policies. Each monitoring policy specifies the statistic to be monitored, the interval at which it should be checked, threshold values that indicate when to indicate a warning or alert status, and when (if at all) these warnings and alerts should trigger notification e-mails. For instance, a policy might state ‘monitor disk usage every five minutes; issue a warning if it gets above 90% and an alert if it gets above 95%, but do not send notification e-mails’.
These policies are then applied to agents, whether individually or in groups; where it makes sense, they can also be applied to individual items on an agent, or such items can be excluded from monitoring if needed. To continue our disk usage example, you may wish to apply the policy only to user data volumes and use a stricter one with notification e-mails included for system volumes.
In the past, configuring this type of monitoring manually using SSyM System Manager has involved creating custom alarm and filter definitions which are attached to instances of SSyM displays and then stored as a saved session within SEM; this session can then be configured to start automatically in the background on a monitoring workstation or server. However, this style of monitoring can be somewhat awkward to configure and maintain as monitoring needs evolve; the Dashboard avoids all of this by automatically starting the correct set of monitoring displays using the Central Controller, which runs in the background as a service display. When you reconfigure monitoring policies via the Dashboard display, the Central Controller takes care of stopping or starting displays within moments, so you don’t need to alter or restart any sessions or services for your changes to take effect.
The Central Controller also takes care of co-ordinating activities between multiple instances, making it easy to set up a redundant secondary monitoring system that will automatically take over if the primary system fails for any reason. Since all Dashboard configuration and status information is held centrally, this is completely transparent to the user; the Dashboard displays will continue to show the latest status regardless of which Central Controller is currently active.
The statistics available for monitoring within the Dashboard are known as probes; each policy is associated with a particular probe type, and each probe type comes complete with default threshold and interval settings you can use as a baseline for your monitoring policies. The data for each probe is gathered by standard SEM displays connected to each agent; for the most part, these displays are stock SSyM System Manager displays, although some probes use Dashboard-specific displays that cannot be used interactively. You can also extend your own custom displays to incorporate Dashboard monitoring support; see the relevant section later in this guide for more information.
Installation of the Dashboard starts by importing the SSyM Dashboard module into SEM. This is done using the usual File ► Import and Export ► Import Module menu option; on the Select page, Browse for and load the SSyM Dashboard.txt file containing the module and then click Next to work through the import wizard pages. On the User Access page, select the users (including yourself!) who should have access to the new library and then continue through the rest of the wizard to finish importing the Dashboard.
(Note that this release of the Dashboard does not include a SEM token to control access to configuration menu options, so the Tokens page of the import wizard will be empty. This is currently expected, but will change in future releases.)
Once the module has been imported, you should find the new SSyM Dashboard library in the Selection Window on the left-hand side of the SEM window. Expand the library folder if needed and start the Dashboard display; in the startup window, select the agent on your Authorization Server, or another Windows agent, and click OK. A prompt will appear telling you that the Dashboard has not yet been configured and offering to start the Setup Wizard. Click Yes to begin the setup process.
The Setup Wizard will guide you through configuring the Dashboard database and, if desired, setting up some basic monitoring to get you started. If you choose the ‘Configure basic monitoring’ option you will be prompted to select some agents and probe types to monitor; monitoring policies will be created based on the default settings for each selected probe and then applied to the specified agents. Alternatively, selecting ‘Do not configure any monitoring’ will skip this part of the configuration and allow you to start creating monitoring policies from a blank Dashboard.
Once the wizard has gathered enough information to create the initial Dashboard configuration, it will prompt you to install the Central Controller as a service display (see the following section for more details if you are not familiar with SEM Service Displays) before finally showing a summary of the choices you have made. Confirm they reflect what you want to do and click Apply to complete the setup process. Assuming you elected to configure basic monitoring, and installed and started the service display when prompted, the Dashboard window should start displaying status information after a few moments.
The Central Controller runs as a service display — a SEM display window that runs in the background using a Windows service. This means that some configuration is required before the Dashboard will begin monitoring activities, but although the Dashboard Setup Wizard provides instructions on how to do this it is unable to complete the installation for you.
If you are already running SEM service displays for other purposes, adding the Central Controller should simply be a case of making sure the SSyM Dashboard library is mapped for the SEM user that the service displays are running as and then enabling the Central Controller option in the Service Displays and Unattended Reports dialog box. There is no need to specify any additional configuration beyond enabling the display and optionally customising the refresh interval, which controls how frequently the Central Controller checks for configuration changes (and, where multiples instances are running for failover purposes, whether it should become the active instance).
To enable the Central Controller service display, follow these steps:
Log into SEM as the System account (or another suitably-privileged account) and ensure the SSyM Dashboard library is mapped. If not, use the Tools ► Library Mappings menu option to map it.
Use the Tools ► Service Displays and Scheduled Reports to open the Service Display and Scheduled Report Configuration dialog box.
On the Service Displays tab, select the entry for the Central Controller display in the SSyM Dashboard library. When not yet configured, it will be shown with a dim indicator and the text ‘- not configured -’ in the Configuration column; if a configuration name is shown instead, skip the following step.
Click the Add Configuration button. The default name for the new configuration should be fine, but can be customised if required; click OK to create the configuration.
Click the ‘Enable this configuration’ checkbox (found below the display details). Optionally, click the Schedule button to customise the Central Controller’s refresh interval.
Click OK to close the Service Display and Scheduled Report Configuration dialog box. If the SEM Service Displays service is already installed and started, the Central Controller should start running within a few moments.
If you do not already have any SEM service displays installed, an additional step is required; as well as enabling the Central Controller display as above, you also need to install the SEM Service Displays service on a suitable Windows system. This system should be one that is always running; your SEM Authorization Server may be a good choice to get started. To configure and install the service:
Optionally create a new SEM user to run the service displays under; this will ensure that the service display environment cannot be accidentally changed, for instance by altering library mappings for an account being used both interactively and by the service display host.
If you choose to do this, make sure that the new user uses the same agent definitions as the Dashboard end-users; this might be through mirroring a shared base account’s agent definitions, or if your normal user account has its own set of definitions either mirroring that account or copying the definitions into the new account.
Log into SEM on the workstation or server where you wish to install the service, and use the Tools ► Service Displays and Scheduled Reports menu option to open the Service Display and Scheduled Report Configuration dialog box.
On the Service tab, specify the (SEM) username and password that the service should log in as — this will be the new user account, if one was created above, or an existing user that has access to the SSyM Dashboard module. Ensure the correct Authorization Server details are present and specify the Windows user account under which the service will run, if desired. The diagnostic logging options should be left on ‘No logging’ for normal operation.
Click the Install button at the bottom of the Service tab to install the SEM Service Displays service. You may be prompted to elevate to a Windows account with Administrator privileges if required.
Click the Start button at the bottom of the Service tab to start the SEM Service Displays service. Again, you may receive a UAC prompt if elevation is required.
Once the service has been started, click OK to close the Service Displays and Unattended Reports dialog box, and then use the Tools ► Monitor Unattended Sessions menu option to make sure the service is running correctly. It should be listed in the upper section of the Monitor Unattended Sessions dialog box, with a session name of ‘- Service Displays -’; selecting that item will show the detailed status of the service in the lower section of the dialog box, including the current status of the Central Controller display and any displays it has started.
If the Central Controller display is not listed in the Monitor Unattended Sessions dialog box, first revisit the Service Display and Scheduled Report Configuration dialog and make sure the Central Controller is listed on the Service Displays tab. It should be shown with a lit-up indicator; if the indicator is dimmed, select it and tick the ‘Enable this configuration’ checkbox. You may need to click the Add Configuration button first if the checkbox is not available.
If the Central Controller service display is enabled but still does not start, the service may be failing to start or failing to log in to SEM. In this case it should have logged an error message to the Application event log, which can be viewed using the Windows Event Viewer applet.
If the service display or host service still fails to start, please contact Sysgem or your distributor for assistance.
By default, all SEM databases (including the SSyM Dashboard database) are created as Microsoft Access .mdb files, typically residing on and accessed via the SEM Authorization Server. This allows users to evaluate new SEM functionality without going to the trouble of setting up new production-scale databases (such as SQL Server databases) ahead of time.
Unfortunately a recent critical security update from Microsoft has introduced a memory leak in the Access database driver used by SEM when creating default databases. Although this does not pose a significant problem for lightly-used databases such as the SAcM Logfile or Subscriber databases, the SSyM Dashboard database is accessed considerably more heavily and more frequently; this means that the most-recent (as of the time of this writing in 2018) version of the Access driver can exhaust its resources on the SEM Authorization Server and cause erratic Dashboard behaviour.
Sysgem therefore recommend using SQL Server for the SSyM Dashboard database in order to avoid this problem — in fact, the Dashboard Setup Wizard will display a warning message telling you this if it detects a version of the Access driver known to suffer this problem. To use a SQL Server database instead, perform the following configuration steps:
Configure the SEM Authorization Server service to run as a specified Windows user; this user (the service account) needs to have read/write access to the SEM Authorization Server, SEM OptionsCache and SEM Databases folders under C:\Program Files (x86)\Sysgem (or your SEM installation directory, if different) on your Authorization Server machine.
(Note that you will need to restart the SEM Authorization Server for it to run under the specified Windows user account.)
Create a new SQL Server database to store the Dashboard data. Grant the service account db_ddladmin, db_datareader and db_datawriter roles in the new database.
Log into your Authorization Server machine as the service account, start the SEM Management Console and use the Tools ► ODBC ► Data Source Administrator menu option to open the ODBC Data Sources Control Panel.
On the System DSNs tab, create a new data source using the SQL Server driver. Give the new data source the name SSyM Dashboard, configure it to connect to your SQL Server using Windows authentication, and select your newly-created database as the default database.
Once you have created the DSN and tested connectivity, you can close the ODBC Data Sources window and (if desired) log out of SEM and the Authorization Server.
You can now start the Dashboard Setup Wizard as usual; it should identify the SQL Server DSN and proceed without warning you about the Access driver version.
Optionally, revoke the db_ddladmin role for the SQL Server user now that setup is complete; this role is only required when making schema changes to the database, such as when creating the database structure during installation. It may be required again when upgrading to future Dashboard versions, though!
Please note: this is advanced information included for the interest of developers of custom displays within SEM that they may wish to integrate with the SSyM Dashboard. If you do not develop your own custom displays, this section can be safely ignored.
[This documentation is currently being prepared and will be available shortly.]
Apart from a manual installation or a remote installation triggered from the client, the RC Server can also be installed in unattended mode using the Microsoft Windows Installer Tool MSIEXEC.
MSI-package location
The SysMan RC Server service installation-package is stored on the SysMan RC client-machine (your local dektop, i.e. the machine where you connect from), as SysgemRCServer.msi in the 'Sysgem\SysMan Remote Control' installation folder.
Note:
If the RC-server icon is disabled, and the connection-list is disabled, and confirmation on incoming connections is disabled, then user sitting at the remote desktop will not be made aware of a session being initiated. Make sure this configuration does not compromise your company-policy in relation to monitoring user’s desktops (also see here).Code: Select all
c:\Program Files\Sysgem\SysMan Remote Control>msiexec /i SysManRCServer.msi /passive /promptrestart PASSWORD=sy5m@n SHOWCONNS=1 QUERYCONNECTIONS=0 EDITSETTINGS=1
Code: Select all
c:\Program Files\Sysgem\SysMan Remote Control>msiexec /i SysManRCServer.msi /passive /promptrestart SHOWCONNS=1 QUERYCONNECTIONS=1 EDITSETTINGS=0Code: Select all
c:\Program Files\Sysgem\SysMan Remote Control>msiexec /x SysManRCServer.msi /passive /promptrestartWhen one of our support-engineers asks you to start our Remote Connector, then please follow the instructions below.
Remote Assistance instructions:
The Sysgem Enterprise Manager documentation can be downloaded here.
The SysMan Remote Control Server service can be deployed through Active Directory using Group Policies.
If you're planing to do this, then please consult the procedure below for reference.
Note:
This article is classified as being on experimental basis. Which means the information below is based on internal case-studies performed by our test-department. It might (or might not) lead to future implementations to be embedded in the software later. Comments are very welcome and can be reported at http://support.sysgem.eu. Be aware that the below is not guaranteed to work, nor is it thoroughly tested. Use and implement at your own risk and approval.Code: Select all
msiexec /a <full-path>\SysManRCServer.msiNote:
If the command-window prompt is not in the folder where SysManRCServer.msi resides, then be sure to either include the full-path to the SysManRCServer.msi file (Example).
One click to add, modify and delete user accounts across systems.
On multiple operating systems in your installation (UNIX/Linux, Windows, OpenVMS)
One click to manage and monitor all of your important servers.
On multiple operating systems in your installation (UNIX/Linux, Windows, OpenVMS)
Disseminate distributed file content from a central location.
On multiple operating systems in your installation (UNIX/Linux, Windows, OpenVMS)
Sysgem SysMan and Access Gateway work together.
They provide secure and controlled remote access to Windows workstations over the Internet.
Find answers to common support questions in our Knowledge Base.
If you require support with an issue not listed here, or have any other enquiries, please contact us.
© Sysgem AG, all rights reserved.
Sysgem is a trademark of Sysgem AG. Other brands and products are registered trademarks of their respective holders.
Sysgem AG, Forsterstrasse 67, CH-8044 Zurich, Switzerland
+41 44 586 1060