Skip to main content
Previous sectionNext section

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 InterSystems IRIS® instance for security. These pages are:

System-Wide Security Parameters

This section describes security issues that affect an entire InterSystems IRIS instance. This includes the system-wide security parameters and handling sensitive data in memory images.

InterSystems IRIS 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]

  • Freeze system on audit database error — (Only available when auditing is enabled.) Stops (freezes) the instance if there is an error writing to the audit database. For more information, the “Freezing the System If It Is Impossible to Write to the Audit Database” section in the “Auditing” chapter.

  • Enable configuration security — Specifies whether configuration security is on or off, as described in the section “Protecting InterSystems IRIS 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 InterSystems IRIS 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 InterSystems IRIS instance, including those used by InterSystems IRIS itself. Until passwords are updated for these accounts, it may be 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.System 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 OS-based LDAP authorization, 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 IRISSYS (the database that holds them), see the section “IRISSYS, 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 InterSystems security domains. For more information on security domains, see the section “Managing InterSystems IRIS 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 InterSystems IRIS superserver, see “Configuring the InterSystems IRIS 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.

  • Default signature hash — Specifies the algorithm used by default to create an XML signature hash. For more information on the supported algorithms for creating hashes, see https://www.w3.org/.

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.

Enabling Automatic Refreshes of Management Portal Pages

By default, users can refresh Management Portal pages only by clicking the generated description: segmgmt refresh (Refresh the diagram) icon where it is available. However, InterSystems IRIS enables you to provide users with a mechanism for automatically refreshing Management Portal pages every several seconds. You can modify the ^%SYS global to expose the mechanism from the Terminal as follows:

set ^%SYS("Portal","EnableAutoRefresh") = 1
Copy code to clipboard

If you do so, a set of radio buttons appears on Management Portal pages that can be refreshed, enabling users to turn automatic refreshes on and off. On some pages, users can specify the refresh interval. Importantly, when you set the EnableAutoRefresh node to 1, automatic refreshes are off by default. The following image shows the Classes page when automatic refreshes have been enabled and the refresh interval has been set to 15 seconds:

Classes pahe with automatic refresh every 15 seconds enabled

Important:

An automatic refresh constitutes a call to the InterSystems IRIS server and can prevent automatic logouts if they are enabled. For more information, see Automatic Logout Behavior in the Management Portal.

Automatic Logout Behavior in the Management Portal

Each InterSystems IRIS Management Portal web application has a Session Timeout property that determines the length of time that users can remain inactive before their sessions expire. By default, fifteen seconds after a user’s session expires, the Management Portal refreshes the current page and logs the user out. The Management Portal does not cache pending changes or prompt the user to save pending changes. Unsaved changes are discarded.

Important:

Inactivity is the time between calls to the InterSystems IRIS server. Not all user actions constitute a call to the server. For example, a user clicking Save constitutes a call to the server, but a user typing in a text field does not. Consequently, if a user is editing a data transformation, but does not click Save for longer than Session Timeout threshold, then the user’s session expires and any unsaved changes are discarded.

After an automatic logout, the following scenarios may occur:

  • The login page appears.

  • The Management Portal logs the user out and then immediately logs the user in again because the web application has a Group By Id value that results in automatic authentication. In this case, the current Management Portal page appears refreshed and any pending changes are removed.

You can take the following steps to prevent users from losing work:

  • Remind users to save their work on a regular basis.

  • Extend the Session Timeout value for web applications where users are performing time-intensive configuration tasks such as modifying data transformations. The default Session Timeout value is 15 minutes.

Additionally, while InterSystems recommends that you retain the default automatic logout behavior, you can allow users to remain logged in until they actively log out or close their browsers when they are on Interoperability pages in the Management Portal. To do so, use ^EnsPortal as follows:

^EnsPortal("DisableInactivityTimeout","Portal") = 1
Copy code to clipboard

You can reinstate automatic logouts by using ^EnsPortal again:

^EnsPortal("DisableInactivityTimeout","Portal") = 0
Copy code to clipboard

InterSystems recommends that you consider the possible security implications before you make any changes.

For more information about web applications and their settings, see Applications.

Authentication Options

The Authentication/Web Sessions Options page (System Administration > Security > System Security > Authentication/Web Options) allows you to enable or disable authentication mechanisms for the entire InterSystems IRIS instance:

  • If an authentication mechanism is disabled for the entire InterSystems IRIS instance, then it is not available for any service.

  • If an authentication mechanism is enabled for the entire InterSystems IRIS 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:

If there are multiple supported authentication options, InterSystems IRIS uses cascading authentication.

The Secure Debug Shell

InterSystems IRIS 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 ObjectScript). InterSystems IRIS 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 ObjectScript.

Within the secure debug shell, when a user attempts to invoke a restricted command or function, InterSystems IRIS 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

InterSystems IRIS allows you to specify requirements for user passwords by supplying a string of the form:

X.Y[ANP]
Copy code to clipboard

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 ObjectScript.

Note:

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 InterSystems IRIS Configuration Information

InterSystems IRIS configuration information is stored in a text file outside of InterSystems IRIS. This file is known as a configuration parameter file and often referred to as an iris.cpf file. Because this file can be modified while InterSystems IRIS is not running, InterSystems IRIS controls the ability to start a system with a modified iris.cpf.

To protect your instance against intentional or accidental misconfiguration, check the Configuration Security box to “on”. If InterSystems IRIS startup detects that the configuration parameter file has been modified outside the control of the Management Portal since the last time InterSystems IRIS was started, InterSystems IRIS 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, InterSystems IRIS allows the operator to choose as follows:

  1. Re-enter the username and password.

  2. Start using the last known good configuration.

  3. Abort startup.

If the operator chooses option 2, InterSystems IRIS renames the parameter file that was invoked at startup (file.cpf) with the suffix _rejected (file.cpf_rejected). InterSystems IRIS then overwrites the file.cpf with the last known good configuration (_LastGood_.cpf) and starts up using this configuration.

Note:

The protections for the iris.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 Configuration Parameter File Reference.

Managing InterSystems IRIS Security Domains

InterSystems security domains provide a grouping of users that corresponds to Kerberos realms and Windows domains. If your instance is using Kerberos, its InterSystems IRIS 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 the at sign (@).

Single and Multiple Domains

InterSystems IRIS supports the use of either a single-domain or multiple-domains.

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.

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. This includes the Users page (Security Administration > Security > Users).

  • Users log in with their fully qualified name on their domain, such as documentation@intersystems.com. If there are two accounts that share the initial portion of the fully qualified name and where the domain names differ, then these are stored as two separate user accounts (where each has its own attributes and these attributes can have differing values).

  • You cannot edit usernames.

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 InterSystems IRIS 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 an InterSystems IRIS 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 an InterSystems IRIS system, InterSystems IRIS 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.

Important:

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 InterSystems IRIS 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, Instance Authentication, 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 InterSystems IRIS 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 InterSystems IRIS 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 InterSystems IRIS 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 InterSystems 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 InterSystems IRIS 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, InterSystems IRIS 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 InterSystems IRIS 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 %IRISSYS database — Write access to the %IRISSYS 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.

Web, 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.

Note:

The times listed here are the latest times that changes take effect; in some cases, changes may be effective earlier than indicated.

Emergency Access

InterSystems IRIS 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 InterSystems IRIS 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 InterSystems IRIS 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 InterSystems IRIS. In fact, even if the username is defined in InterSystems IRIS, 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_WebGateway are the only services enabled.

  • There is only access using Instance Authentication — 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 start InterSystems IRIS in emergency access mode, you must have the appropriate operating-system privileges:

  • On Windows systems, the user must be a member of the Administrators group.

  • On UNIX® and MacOS systems, the user must be root or the owner of the instance.

InterSystems IRIS performs authentication by checking operating-system-level characteristics.

Invoking Emergency Access Mode on Windows

To start InterSystems IRIS in emergency access mode:

  1. 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.

  2. Go to the bin directory for your InterSystems IRIS installation.

  3. In that directory, invoke InterSystems IRIS 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:

      iris start <instance> /EmergencyId=<username>,<password>
      Copy code to clipboard

      This starts an emergency-mode InterSystems IRIS 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 .\iris.exe -ArgumentList "start <instance> /EmergencyId=<username>,<password>"
      Copy code to clipboard

      This starts an emergency-mode InterSystems IRIS 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 MyIRIS, to start InterSystems IRIS in emergency mode with user Eugenia with the password 52601, the command would be:

    iris start MyIRIS /EmergencyId=Eugenia,52601
    Copy code to clipboard

    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
    
    Copy code to clipboard

Once InterSystems IRIS has started, you can start the Terminal from the InterSystems IRIS launcher or run any web 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 InterSystems IRIS in its normal mode.

Invoking Emergency Access Mode on UNIX® and Mac OS

To start InterSystems IRIS in emergency access mode, invoke InterSystems IRIS at the command line using the appropriate switch and passing in the username and password for the emergency user:

./iris start <instance-name> EmergencyId=<username>,<password>
Copy code to clipboard

This starts an emergency-mode InterSystems IRIS session with only one allowed user where:

  • <instance-name> specifies the instance being started in emergency mode

  • <username> is the sole user of the system

  • <password> is <username>’s password

Note:

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 MyIRIS, to start InterSystems IRIS in emergency mode with user Eugenia with the password 5262001, the command would be:

./iris start MyIRIS EmergencyId=Eugenia,52601
Copy code to clipboard

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
Copy code to clipboard

Once InterSystems IRIS has started, you can run the Terminal or any web 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 InterSystems IRIS in its normal mode.

Emergency Access Mode Behavior

In emergency access mode, InterSystems IRIS 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 Web Gateway are the only services that are enabled. All other services are disabled. This does not affect the enabled or disabled status of services when InterSystems IRIS 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. InterSystems IRIS uses its own password authentication for the services, where the emergency access username and password must be used.

  • After emergency access login, InterSystems IRIS attempts to audit all events for the active process; InterSystems IRIS 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 InterSystems IRIS configuration, but these changes are not activated until the next time that InterSystems IRIS is started in normal (not emergency) mode. This is in contrast to the normal operation of InterSystems IRIS, in which configuration changes are primarily activated without restarting InterSystems IRIS.