System Management and Security
This chapter covers the following topics:
System Security Settings Page
The System Security Settings page (System Administration > Security > System Security) provides links to pages that configure the entire Caché instance for security. These pages are:
System-Wide Security Parameters
This section describes security issues that affect an entire Caché instance. This includes the system-wide security parameters and handling sensitive data in memory images.
Caché includes a number of system-wide security parameters. You can configure these on the System Security Settings page (System Administration > Security > System Security > System-wide Security Parameters). These are:
-
Enable audit — Turns auditing on or off. This check box performs the same action as the Enable Auditing and Disable Auditing links on the Auditing page (System Administration > Security > Auditing). For more information on auditing, see the chapter “Auditing.” [Default is off]
-
Enable configuration security — Specifies whether configuration security is on or off, as described in the section “Protecting Caché Configuration Information.” [Default is off]
-
Default security domain — Allows you to choose the instance’s default security domain. For more information on security domains, see the section “Managing Caché Security Domains”. [Default is the domain established during installation]
-
Inactive limit (0–365) — Specifies the maximum number of days that a user account can be inactive, which is defined as the amount of time between successful logins. When this limit is reached, the account is disabled. A value of 0 (zero) means that there is no limit to the number of days between logins. [Default is 0 for minimal-security installations and 90 for normal and locked-down installations]
-
Invalid login limit (0-64) — Specifies the maximum number of successive unsuccessful login attempts. After this limit is reached, either the account is disabled or an escalating time delay is imposed on each attempt; the action depends on the value of the Disable account if login limit reached field. A value of 0 (zero) means that there is no limit to the number of invalid logins. [Default is 5]
-
Disable account if login limit reached — If checked, specifies that reaching the number of invalid logins (specified in the previous field) causes the user account to be disabled.
-
Password Expiration Days (0–99999) — Specifies how frequently passwords expire and, therefore, how frequently users must change their passwords (in days). When initially set, specifies the number of days until passwords expire. A value of 0 (zero) means that the password never expires; however, setting this field to 0 does not affect users for whom the Change Password on Next Login field has been set. [Default is 0]
Caution:This setting affects all accounts for the Caché instance, including those used by Caché itself. Until passwords are updated for these accounts, it may impossible for various operations to proceed and this may lead to unexpected results.
-
Password pattern — Specifies the acceptable format of newly created passwords. See “Password Strength and Password Policies” for more information. [Default for an instance with Minimal and Normal security is 3.32ANP; default for a locked-down instance is 8.32ANP.]
-
Password validation routine — Specifies a user-provided routine (or entry point) for validating a password. See the PasswordValidationRoutine method in the Security.SystemOpens in a new tab class for more information.
-
Role required to connect to this system — If set to an existing role, specifies that a user must be a member of this role (as a login role) in order to log into the system.
If you are using LDAP authentication or LDAP Authorization with OS-Based Authentication, InterSystems strongly recommends that you create a role that is required to connect and that you specify its name in this field. For more information, see the “Setting Up a Role Required for Login” section of the “Using LDAP” chapter.
-
Enable writing to percent globals — Specifies whether write access to percent globals is implicitly granted to all users; if not checked, write access is controlled by normal security mechanisms. For more information on the percent globals and CACHESYS (the database that holds them), see the section “CACHESYS, the Manager’s Database” in the chapter “Assets and Resources.” [Default is controlled by normal security mechanisms.]
-
Allow multiple security domains — Specifies whether there is support for multiple Caché security domains. For more information on security domains, see the section “Managing Caché Security Domains.” [Default is a single domain]
-
Superserver SSL/TLS Support — Specifies if the superserver supports or requires the use of SSL/TLS for client connections.
Important:Before you can configure the superserver to use SSL/TLS, there must be an existing configuration called %SuperServer. For more information about using SSL/TLS with the Caché superserver, see “Configuring the Caché Superserver to Use SSL/TLS.”
Options are:
-
Disabled — The superserver refuses client connections that use SSL/TLS. (That is, it only accepts client connections that do not use SSL/TLS.)
-
Enabled — The superserver accepts but does not require SSL/TLS.
-
Required — The superserver requires client connections to use SSL/TLS.
-
Protecting Sensitive Data in Memory Images
Certain error conditions can cause the contents of a process’s memory to be written to a disk file, known as a “core dump.” This file contains copies of all data that was in use by the process at the time of the dump, including potentially sensitive application and system data. This can be prevented by disallowing core dumps on a system-wide basis. The method for disallowing core dumps varies according to the operating system in use; for details, consult the documentation of your operating system.
Automatic Logout Behavior in the Management Portal
By default, the InterSystems Management Portal logs users out after periods of inactivity. The portal does not prompt users to save their changes prior to the logouts. For example, if an Ensemble user begins to edit a data transformation in the Management Portal and then walks away for a period of time that exceeds the permissible length of inactivity, the portal logs the user out and discards the edits.
The length of inactivity that triggers an automatic logout varies across web applications in an instance. Specifically, the Session Timeout value for each web application determines the trigger. Fifteen seconds after a Management Portal page reaches the Session Timeout threshold, the system refreshes the page, determines that the session has expired, and logs the user out. A page is inactive as long as it does not make any calls to a server. For more information about web applications and their settings, see Applications.
InterSystems recommends that you retain the default automatic logout behavior. However, for Ensemble instances, you can allow users to remain logged in until they actively log out or close their browsers when they are on Ensemble pages in the Management Portal. To do so, use ^EnsPortal as follows:
^EnsPortal("DisableInactivityTimeout","Portal") = 1
This is a per-namespace setting. To modify logout behavior, you must set this value for each namespace individually.
You can reinstate automatic logouts by using ^EnsPortal again:
^EnsPortal("DisableInactivityTimeout","Portal") = 0
Authentication Options
The Authentication/CSP Sessions Options page (System Administration > Security > System Security > Authentication/CSP Options) allows you to enable or disable authentication mechanisms for the entire Caché instance:
-
If an authentication mechanism is disabled for the entire Caché instance, then it is not available for any service.
-
If an authentication mechanism is enabled for the entire Caché instance, then it is available for all the services that support it. To enable the authentication mechanism for a particular service, use the Edit Service page for that property; this page is available by selecting the service from the Services page (System Administration > Security > Services).
Note:Not all services support all mechanisms.
The authentication options are:
-
Allow Unauthenticated access — Users may connect without authenticating. (If login dialog appears, the user can leave the Username and Password fields blank and click OK to log in.)
-
Allow O/S authentication — Caché uses the operating system’s user identity to identify the user.
-
Allow O/S authentication with Delegated authorization — Caché uses the operating system’s user identity to identify the user; it then uses delegated authorization.
-
Allow O/S authentication with LDAP authorization — Caché uses the operating system’s user identity to identify the user; it then uses LDAP authorization.
-
Allow Password authentication — Caché uses its own native tools to authenticate a username and password that are registered with it. This mechanism is also known as Caché login.
-
Allow Delegated authentication — Caché delegates the process of authentication to a user-defined function.
-
Allow Kerberos authentication — Caché performs authentication using Kerberos.
-
Allow LDAP authentication — Caché uses LDAP to authenticate users.
-
Allow LDAP cache credentials authentication — Caché keeps a cached copy of LDAP credentials so that it can authenticate LDAP users if the LDAP database becomes unavailable.
-
Allow creation of Login Cookies — Caché uses cookies that are shared among enabled web applications to authenticate users, so that they do not need to enter a username and password when first using a new application.
-
Login Cookie expire time (secs) — The duration of a login cookie, in seconds. This field is only relevant if Login Cookies are enabled for the instance.
-
Allow Two-factor Time-based One-time Password authentication — Caché provides a verification code via an authentication device or an app that runs on the user’s phone; the user then enters the code to complete the authentication process. If selected, the Authentication/CSP Session Options page displays the fields for configuring two-factor authentication.
-
Allow Two-factor SMS text authentication — Caché provides a security code via a mobile phone text message; the user then enters the code to complete the authentication process. If selected, the Authentication/CSP Session Options page displays the fields for configuring two-factor authentication.
If there are multiple authentication options, Caché uses cascading authentication. For more information on authentication, see the chapter “Authentication.”
The Secure Debug Shell
Caché includes the ability to suspend a routine and enter a shell that supports full debugging capabilities (as described in the “Command-line Routine Debugging” chapter of Using Caché ObjectScript). Caché also includes a secure debug shell, which has the advantage of ensuring that users are prevented from exceeding or circumventing their assigned privileges.
The secure debug shell helps better control access to sensitive data. It is an environment that allows users to perform basic debugging, such as stepping and displaying variables, but does not allow them to do anything that changes the execution path or results of a routine. This protects against access that can lead to issues such as manipulation, malicious role escalation, and the injection of code to run with higher privileges.
The secure debug shell starts when a Break command is executed, a breakpoint or watchpoint is encountered, or an uncaught error is issued.
Within the secure debug shell, the user cannot invoke:
-
Any command that can modify a variable.
-
Any function that can modify a variable.
-
Any command that can call other routines.
-
Any command that affects the flow of the routine or the environment.
For a detailed list of command, function, and object construct restrictions, refer to Secure Debug Shell in the “Command-line Routine Debugging” chapter of Using Caché ObjectScript.
Within the secure debug shell, when a user attempts to invoke a restricted command or function, Caché throws a <COMMAND> or <FUNCTION> error, respectively.
Enabling Use of the Secure Shell
By default, users at the debug prompt maintain their current level of privileges. To enable the secure shell for the debug prompt and thereby restrict the commands that the user may issue, the user must hold the %Secure_Break:Use privilege (the Use permission for the %Secure_Break resource). To give a user this privilege, make the user a member of a role which includes the %Secure_Break:Use privilege, such as the predefined %SecureBreak role.
Password Strength and Password Policies
Caché allows you to specify requirements for user passwords by supplying a string of the form:
X.Y[ANP]
where
-
X is the minimum number of characters in the password.
-
Y is the maximum number of characters in the password.
-
A, N, and P specify whether Alphabetic characters, Numeric characters, and Punctuation characters are permitted in the password.
These rules are based on the ObjectScript pattern matching functionality. This functionality is described in the “Pattern Matching” section of the “Operators and Expressions” chapter of Using Caché ObjectScript.
The value for this parameter does not affect existing passwords.
Suggested Administrator Password Strength
Ideally, administrator passwords should be a random mixture of uppercase and lowercase alphabetic characters, numerals, and punctuation. InterSystems strongly recommends a minimum password length of 12 such random characters.
Protecting Caché Configuration Information
Caché configuration information is stored in a text file outside of Caché. This file is known as a Caché parameter file and often referred to as a cache.cpf file. Because this file can be modified while Caché is not running, Caché controls the ability to start a system with a modified cache.cpf.
To protect your instance against intentional or accidental misconfiguration, check the Configuration Security box to “on”. If Caché startup detects that the Caché parameter file has been modified outside the control of the Management Portal since the last time Caché was started, Caché startup requests a username and password to validate the changes. The username supplied must have %Admin_Manage:Use privileges. If an appropriate username and password cannot be provided, Caché allows the operator to choose as follows:
-
Re-enter the username and password.
-
Start using the last known good configuration.
-
Abort startup.
If the operator chooses option 2, Caché renames the parameter file that was invoked at startup (file.cpf) with the suffix _rejected (file.cpf_rejected). Caché then overwrites the file.cpf with the last known good configuration (_LastGood_.cpf) and starts up using this configuration.
The protections for the cache.cpf file are not a substitute for operating-system–level security. It is recommended that you protect the configuration file by strictly limiting the ability of users to modify it, at the operating-system level.
For more information on the configuration file generally, see the Caché Parameter File Reference.
Managing Caché Security Domains
Caché security domains provide a grouping of users that corresponds to Kerberos realms and Windows domains. If your instance is using Kerberos, its Caché domain corresponds to a Kerberos realm. If you are using a Windows domain, this also corresponds to a Kerberos realm.
While a security domain name often takes the form of an Internet domain name, there is no requirement that it do so. A security domain name can contain any character except “@”.
Single and Multiple Domains
You can configure Caché for either a single-domain or multiple-domain configuration.
For an instance with a single domain:
-
The $USERNAME variable does not include the domain name.
-
System utilities do not show the domain name when displaying usernames.
-
It is prohibited to specify a username from any domain other than the default domain (described in the following section).
For an instance with multiple domains:
-
The $USERNAME variable includes the domain name.
-
System utilities show the domain name when displaying usernames.
In a multiple-domain configuration, a fully-qualified user identifier consists of a username, an at sign (“@”), and a domain name, such as, “info@intersystems.com”.
To specify support for a single domain or multiple domains, use the Allow multiple security domains field of the System-wide Security Parameters page of the Management Portal (System Administration > Security > System Security > System-wide Security Parameters), described in the System-wide Security Parameters section of this chapter.
The Default Security Domain
Each instance has a default security domain. This is the domain assumed for any username where no domain is specified. For example, if the default domain is “intersystems.com”, the user identifiers “info” and “info@intersystems.com” are equivalent. When Caché is installed, it uses the local domain name to provide an initial value for the parameter.
For instances with multiple security domains, you can select a new default security domain using the Default Security Domain field of the System-wide Security Parameters page (System Administration > Security > System Security > System-wide Security Parameters), described in the System-wide Security Parameters section of this chapter.
Listing, Editing, and Creating Domains
The Security Domains page (System Administration > Security > Security Domains) provides a table that lists the existing security domains for a Caché instance.
For each domain, the table has:
-
The domain’s name.
-
The domain’s description.
-
An Edit button, which allows you to edit the domain’s description (but not its name). Since you cannot change a domain’s name, create a new domain with the preferred name and then delete the existing domain.
-
A Delete button, which, after prompting, allows you to remove a domain from the instance.
The page also has a Create New Domain button. Selecting this displays the Edit Domain page which accepts a domain name and an optional domain description. After entering this information, select Save to create the domain.
Security Advisor
To assist system managers in securing a Caché system, Caché includes a Security Advisor. This is a Web page that shows current information related to security in the system configuration. It recommends changes or areas for review, and provides links into other system management Web pages to make the recommended changes.
The Security Advisor provides general recommendations, but does not have any knowledge of an instance’s needs or requirements. It is important to remember that each Caché instance has its own requirements and constraints, so that issues listed in the Security Advisor may not be relevant for your instance; at the same time, the Security Advisor may not list issues that are of high importance for you. For example, the Security Advisor exclusively recommends that services use Kerberos authentication, but, depending on your circumstances, authentication through the operating system, Caché login, or even unauthenticated access may be appropriate.
There are some general features in the Security Advisor:
-
Details button — Each section has a Details button. Selecting this button displays the page for managing that aspect of Caché regulated by the section.
-
Name button — Each named item in each section is a link. Selecting one of these items displays the page for managing that item.
-
Ignore check box — Each named item in each section has an associated Ignore check box. Selecting this grays out the line for the specified item. The line does not appear if Caché is set up according to the Security Advisor’s recommendations, whether or not the Ignore check box is selected.
Auditing
This section displays recommendations on auditing itself and on particular audit events:
-
Auditing should be enabled — Auditing creates a record that can provide forensic information after any notable or unusual system events.
-
Auditing for this event type should be enabled — Auditing particular events can provide more specific information about various topics. Specifically, since the events noted when not enabled are:
-
The DirectMode event — Auditing this event can provide information about connections to Caché that give users significant privileges.
-
The Login event — Auditing this event can provide information questionable logins.
-
The LoginFailure event — Auditing this event can provide information about attempts to gain inappropriate access to the system.
-
Services
This section displays recommendations on Caché services. For each service, depending on its settings, the Security Advisor may address any of the following issues:
-
Ability to set % globals should be turned off — Since % globals often hold system information, allowing users to manipulate these globals can result in serious, pervasive, and unpredictable effects.
-
Unauthenticated should be off — Unauthenticated connections give all users, including the unidentified UnknownUser account, unregulated access to Caché through the service.
-
Service should be disabled unless required — Access through any service monitored by the Security Advisor can provide an undue level of system access.
-
Service should use Kerberos authentication — Access through any other authentication mechanism does not provide the maximum level of security protection.
-
Service should have client IP addresses assigned — By limiting the number of IP addresses from which connections are accepted, Caché may be able to more tightly oversee the connections to it.
-
Service is Public — Public services give all users, including the unidentified UnknownUser account, unregulated access to Caché through the service.
Roles
This section displays recommendations for all roles that hold possibly undue privileges; other roles are not listed. For each role, the Security Advisor may address any of the following issues:
-
This role holds privileges on the Audit database — Read access to the Audit database may expose audited data inappropriately; Write access to the Audit database may allow the inappropriate insertion of data into that database.
-
This role holds the %Admin_Secure privilege — This privilege can allow for the establishing, modifying, and denying access of users to assets; it also allows the modification of other security-related features.
-
This role holds Write privilege on the %CACHESYS database — Write access to the %CACHESYS database may allow the compromise of system code and data.
Users
This section displays recommendations related to users generally and for individual user accounts. In this area, the Security Advisor may address any of the following issues:
-
At least 2 and at most 5 users should have the %All role — Too few users holding %All can lead to access problems in an emergency; too many users holding it can open the system to compromise
-
This user holds the %All role — Explicitly announcing which users hold %All can help eliminate any who hold it unnecessarily.
-
UnknownUser account should not have the %All role — A system cannot be properly secured if anonymous users have all privileges. While this is part of any instance with a Minimal security level, such an instance is not properly secured by design.
-
Account has never been used — Unused accounts provide an attractive point of entry for those attempting to gain unauthorized access.
-
Account appears dormant and should be disabled — Dormant accounts (those that have not been used for over 30 days) provide an attractive point of entry for those attempting to gain unauthorized access.
-
Password should be changed from default password — This is a commonly attempted point of entry for those attempting to gain unauthorized access.
CSP, Privileged Routine, and Client Applications
Each application type has its own section, which makes it simpler to review details for each application type. These sections display recommendations related to access to and privileges granted by applications. In this area, the Security Advisor notes the following issues:
-
Application is Public — Public applications give all users, including the unidentified UnknownUser account, unregulated access to the data associated with the application and actions that the application supports. This is even more notable if the application also grants the %All role, either conditionally or absolutely.
-
Application conditionally grants the %All role — A system cannot be properly secured if users have the possibility of holding all privileges. This is even more notable if the application is also public.
-
Application grants the %All role — A system cannot be properly secured if users have all privileges. This is even more notable if the application is also public.
Effect of Changes
When you make changes to various security settings, the amount of time for these to take effect are as follows:
-
Changes to user properties, such as the roles assigned to the user, are effective with the next login for that user. They have no effect on processes that are already running.
-
Changes to services, such as whether a service is enabled or authentication is required, are effective for future connection attempts. Existing connections are not affected.
-
Changes to role definitions are effective immediately for any subsequent privilege checks. These affect database resources immediately, because they are checked for each database access. For services and applications, they are effective with subsequent connection attempts or application initiations.
The times listed here are the latest times that changes take effect; in some cases, changes may be effective earlier than indicated.
Emergency Access
Caché provides a special emergency access mode that can be used under certain dire circumstances, such as if there is severe damage to security configuration information or if no users with the %Admin_Manage:Use or %Admin_Security:Use privileges are available (that is, if all users are locked out). Although Caché attempts to prevent this situation by ensuring that there is always at least one user with the %All role, that user may not be available or may have forgotten the password.
When Caché is running in emergency access mode, only a single user (called the emergency user) is permitted. This username does not have to be previously defined within Caché. In fact, even if the username is defined in Caché, the emergency user is conceptually a different user. The emergency username and password are only valid for the single invocation of emergency mode.
Other important points about emergency access mode:
-
%Service_Console, %Service_Terminal, and %Service_CSP are the only services enabled.
-
There is only access using Caché login — no other authentication mechanism is supported.
-
For the web applications that control the Portal (/csp/sys and /csp/sys/*), the standard login page (%CSP.Login.cls) is used during emergency access even if there is a custom login page available; this ensures that the emergency user has access to the Portal, since a custom login page may prevent authentication from occurring. For other web applications, if there is a custom login page, then that page is used during emergency login.
-
Two-factor authentication is disabled. This avoids any situation where two-factor authentication might prevent the emergency user from being able to authenticate.
Invoking Emergency Access Mode
To obtain emergency access to an instance of Caché, you must either have root or administrator privileges where the instance is running (if it was installed by root) or be the user who installed the instance (if it was not installed by root). This requirement limits emergency access to users who already have sufficient privileges to perform administrative operations on the instance, such as installing a new instance over the existing one.
Invoking Emergency Access Mode on Windows
To start Caché in emergency access mode:
-
Start a command prompt, running it as an administrator. This can either be:
-
The Windows Command Prompt program. Right-click the Command Prompt choice in the menu and then choose Run as Administrator.
-
The Windows PowerShell. While you can run this as either an administrator or a user without extra privileges, this procedure assumes that you are running as an administrator; to run as a user without extra privileges, use the -verb runas argument when you invoke the command, which is described in PowerShell documentation.
-
-
Go to the bin directory for your Caché installation.
-
In that directory, invoke Caché at the command line using the appropriate switch and passing in the username and password for the emergency user. This depends on the command prompt that you are using:
-
For the Windows Command prompt, the command is:
ccontrol start <instance> /EmergencyId=<username>,<password>
This starts an emergency-mode Caché session with only one allowed user where:
-
<instance> specifies the instance being started in emergency mode
-
<username> is the sole user of the system
-
<password> is that user’s password
-
-
For the Windows PowerShell, the command is:
start-process .\ccontrol.exe -ArgumentList "start <instance> /EmergencyId=<username>,<password>"
This starts an emergency-mode Caché session with only one allowed user where:
-
<instance> specifies the instance being started in emergency mode
-
<username> is the sole user of the system
-
<password> is that user’s password
-
Note:On Windows, unlike other operating systems, the EmergencyId switch is preceded by a slash (“/”).
For example, at the instance MyCache, to start Caché in emergency mode with user Eugenia with the password 52601, the command would be:
ccontrol start MyCache /EmergencyId=Eugenia,52601
The only user who can then log in is the emergency user, using the appropriate password, such as:
Username: Eugenia Password: ***** Warning, bypassing system security, running with elevated privileges
-
Once Caché has started, you can start the Terminal from the Caché cube or run any CSP application. This provides access to the Management Portal and all character-based utilities. Using this access, you can change any settings as necessary and then restart Caché in its normal mode.
Invoking Emergency Access Mode on UNIX®, Linux, and Mac OS
To start Caché in emergency access mode, invoke Caché at the command line using the appropriate switch and passing in the username and password for the emergency user:
./ccontrol start <cache-instance-name> EmergencyId=<username>,<password>
This starts an emergency-mode Caché session with only one allowed user where:
-
<cache-instance-name> specifies the instance being started in emergency mode
-
<username> is the sole user of the system
-
<password> is <username>’s password
If going from one of these operating systems to Windows, remember that on Windows only, the EmergencyId switch is preceded by a slash (“/”).
For example, at the instance MyCache, to start Caché in emergency mode with user Eugenia with the password 5262001, the command would be:
./ccontrol start MyCache EmergencyId=Eugenia,52601
The only user who can then log in is the emergency user, using the appropriate password, such as:
Username: Eugenia
Password: *****
Warning, bypassing system security, running with elevated privileges
Once Caché has started, you can run Terminal or any CSP application. This provides access to the Management Portal and all character-based utilities. Using this access, you can change any settings as necessary and then restart Caché in its normal mode.
Emergency Access Mode Behavior
In emergency access mode, Caché has the following constraints and behaviors:
-
The emergency user is the only permitted user. Any attempt by another user to log in will fail.
-
The emergency user has the %ALL role.
-
Console, Terminal and CSP are the only services that are enabled. All other services are disabled. This does not affect the enabled or disabled status of services when Caché starts in non-emergency mode; only the current (emergency), in-memory information about services is affected.
-
For the enabled services, only authenticated access is permitted. Caché uses its own password authentication for the services, where the emergency access username and password must be used.
-
After emergency access login, Caché attempts to audit all events for the active process; Caché start-up proceeds even if this is not possible. Login failures in emergency access mode are not audited.
-
The emergency user can make changes to the Caché configuration, but these changes are not activated until the next time that Caché is started in normal (not emergency) mode. This is in contrast to the normal operation of Caché, in which configuration changes are primarily activated without restarting Caché.