1C:Enterprise 8.3. Administrator guide. File Mode.

Introduction

This book is a guide for administrators of 1C:Enterprise.

Overview

‎Chapter 1 contains system requirements for 1C:Enterprise deployment and operation.

‎Chapter 2 describes installation of 1C:Enterprise.

‎Chapter 3 describes installation of 1C configurations.

‎Chapter 4 describes system startup and customization of the startup window.

‎Chapter 5 contains information on managing the list of infobases.

‎Chapter 6 explains 1C:Enterprise administration capabilities.

‎Chapter 7 describes standalone server starting and managing.

‎Chapter 8 describes how to configure web servers to work with 1C:Enterprise.

‎Chapter 9 describes how to configure web browsers to run the web client.

‎Chapter 10 describes the unauthorized use protection system and its settings.

‎Chapter 11 describes the process of updating the system.

‎Chapter 12 describes the uninstallation process.

‎Chapter 13 describes administration of the mobile application.

The appendices contain various auxiliary information:

• Description of the directory structure that will be created after the installation, and descriptions of some files and directories.

• Description and location of internal files.

• Description of utilities for infobase testing and correcting, integrity monitoring, and infobase conversion, as well as description of the ring utility.

• Description of the command line for starting the 1C:Enterprise client applications and Designer.

• Components and licenses used.

Agreed notations

Keys. Keys such as Enter, Esc, Del, and others are given without quotation marks.

The Arrow keys phrase is used to specify all arrow keys at once. They are individually referred to as Up Arrow, Down Arrow, Right Arrow, and Left Arrow.

Keyboard shortcuts. When a command requires a keyboard shortcut, it will be denoted as Ctrl + F3. All keyboard shortcuts in the guide are specified for PC-compatible computers. On Apple computers, you need to use Cmd instead of Ctrl and Option instead of Alt in the given keyboard shortcuts. So, the keyboard shortcut Ctrl + Alt + Shift + F5 for a PC-compatible computer will look as follows for an Apple computer: Cmd + Option + Shift + F5.

Buttons. Form buttons are given without quotation marks, like OK, Cancel, Delete, and others.

1C:Enterprise language keywords. 1C:Enterprise language keywords are highlighted by specific font and are given as in modules, for example: WorkingDate. This manual contains references to some parts of 1C:Enterprise language description (sections, methods, attributes, and others). For these descriptions, see the application help (the 1C:Enterprise language section).

Menu actions. Menu interactions are described as follows: Menu – Submenu – Submenu – ... – Menu item. For example: "To select the picture scale, click Table – View – Scale" is similar to: "To select the picture scale, use the Scale menu item of the View submenu in the Table menu in the main menu of the application". If any menu, other than the main menu, is referred, it is specified explicitly.

1C:Enterprise modes. Configuration setup and validation (hereinafter referred to as Designer mode), and configuration execution (hereinafter referred to as 1C:Enterprise mode).

In this manual, the "user" refers to a specialist who develops or maintains the configuration.

The following abbreviations and expressions may be used in this document:

C:\ProgramData

C:\Users\Smith\AppData\Roaming

C:\Users\Ivanov\AppData\Local

C:\Program Files

C:\Program Files (x86)

C:\Windows

C:\Users\Smith

All files of the same name that are used simultaneously for Windows OS, Linux OS and macOS, will be mentioned under the same name in this guide, regardless of the OS being used. For example, the 1cestart.cfg file will be stated as is in the guide, as well as on Linux and macOS. However, it will be called 1CEStart.cfg on Windows.

Extensions of executable files are not specified (if any). This means that 1cv8.exe is referred to as 1cv8 in this manual. On Windows, add the .exe extension. On Linux and macOS, do not add anything.

Also, Linux and macOS are case-sensitive, and Windows is not.

Chapter 1. System and hardware requirements

1.1. System requirements

1.1.1. General information

This section contains the minimum characteristic requirements for the computing systems on which 1C:Enterprise is running.

Apple computers support both x86-64 and Apple processors. Apple processors are supported only in translation mode. Translation mode can affect 1C:Enterprise platform performance.

The optimal hardware configuration depends both on the client application type of 1C:Enterprise platform and other factors:

• Installed software

• Size and number of infobases

• Number of connected users

• Used application configuration

• Used configuration patches

• Used configuration extensions

• Used platform features (for example, Data Accelerator) and many other factors

To get the optimal hardware configuration for comfortable operation, do not rely only on the minimum requirements. It is recommended that you assess the hardware in practice. Perform testing in case of deployments in companies with numerous users. Compare the test results with the desired performance and adjust the resulting system and hardware requirements. To calculate the server hardware parameters, we recommend following the procedure: https://its.1c.ru/db/metod8dev#content:5810 (in Russian).

You can find relevant 1C:Enterprise requirements with notes on the website: http://www.v8.1c.ru/requirements/ (in Russian).

1.1.2. Thin client

Minimum requirements for a client computer:

1.1.3. Thick client

1.1.3.1. End user computer

Minimum requirements for a client computer:

1.1.3.2. Developer computer

Minimum requirements for an application developer's computer:

The RAM requirements for thick client and configuration development may vary between configurations.

1.1.4. Web client

The web client requirements are generally defined by the web browser used. Requirements for a web client user's computer:

Progressive web application is supported on a user device if:

• The following web browsers are used:

  • Google Chrome 73 or later.

  • Microsoft Edge 73 or later.

  • Yandex Browser 22 or later.

• Connection to the web server is established over HTTPS. A valid certificate is installed on the web server.

1.1.5. Mobile version

1.2. Power-saving modes

Power-saving modes are disabled on computers running 1C:Enterprise if:

• Online dongle is used.

• Database file is located on a network drive while the infobase is in file mode.

1.3. Supported web servers

1C:Enterprise supports the following web servers:

• Microsoft Internet Information Services (IIS) 5.1, 6.0, 7.0, 7.5, 8.0, 8.5, 10.0.

Web server documentation:

• IIS 6.0: https://technet.microsoft.com/ru-ru/library/cc785089.aspx.

• IIS 7.0: https://technet.microsoft.com/ru-ru/library/cc732976.aspx.

• IIS 7.5: https://technet.microsoft.com/ru-ru/library/cc754281.aspx.

• IIS 8.0, 8.5: https://technet.microsoft.com/ru-ru/library/hh831725.aspx.

• Apache HTTP Server 2.0, 2.2, and 2.4.

You can download the latest web server version at: https://httpd.apache.org/download.cgi. Web server documentation:

• Apache 2.0: https://httpd.apache.org/docs/2.0/.

• Apache 2.2: https://httpd.apache.org/docs/2.2/.

• Apache 2.4: https://httpd.apache.org/docs/2.4/.

To use external data sources in infobase file mode that uses a Linux web server, unixOdbc 2.2.11 or above must be available on the web server.

If the web server is used to access the file mode of the infobase, the computer running the web server and web server extension must meet the following requirements:

• Intel Celeron processor 2700 MHz or higher.

• RAM: 4 GB or more (8 GB recommended).

• Hard drive or solid state drive (approximately 1 GB required for installation).

1.4. Other requirements

1.4.1. General requirements

To use some 1C:Enterprise features, you might need to install Java 1.8 or later on computers with the server cluster. The bitness of Java must match the bitness of 1C:Enterprise server cluster. We recommend that you use the Liberica distribution. Features that require Java to be installed:

• The ring utility and related utilities, for example, the licensing utility (ring license).

• Full-text data search, version 2.

When using client/server mode, additional or other 1C:Enterprise components might require installing Java.

1.4.2. On Linux

To use other functions, the following libraries might be required:

• fontconfig:

  • Library name: libfontconfig.

  • Version: 2.3.0 or later.

  • Purpose:

    • Operation of 1C:Enterprise server in managed mode.

    • Using the Chart, GraphicalSchema, or SpreadsheetDocument objects on the server.

    • Saving to PDF.

• unixOdbc:

  • Library name: libodbc.

  • Version: 2.2.11 or later.

  • Purpose: operations with external data sources.

• Kerberos:

  • Library name: libkrb5.

  • Version: 1.4.2 or later.

  • Purpose: OS authentication.

• GSS-API Kerberos:

  • Library name: libgssapi_krb5.

  • Version: 1.4.2 or later.

  • Purpose: OS authentication.

• Microsoft Core Fonts.

Libraries are imported by 1C:Enterprise as LibraryName.so.X.Y, where:

• LibraryName is one of the values listed above.

• so indicates a library file.

• X.Y are library suffix digits.

Only libraries registered in runtime dynamic linker cache can be imported. To get this information, execute the ldconfig -p command. If several versions of the library are available, the latest one will be imported.

1.4.3. On Windows

The Windows user that starts the client application must have the List folder contents right for the temporary files directory.

To use the software licensing system (see Software Licensing System), enable WMI (Windows Management Instrumentation, https://msdn.microsoft.com/en-us/library/aa394582.aspx).

Some fonts might require restarting the computer when installed. If the font is used by the client application, the client computer needs restarting. If the font is used by the server, the server needs restarting.

When working in Windows 10 via Remote desktop connection, it is recommended that you disable Visual effects of menus and windows in connection settings. This check box is available in additional parameters of the Interaction tab.

Nonvisual 1C:Enterprise access is supported in Windows 7 and above. Nonvisual access requires:

• Microsoft UI Automation.

• NVDA (https://www.nvaccess.org/) screen reader is recommended.

• For Russian speech, install RHVoice speech synthesizer (https://github.com/Olga-Yakovleva/RHVoice).

Nonvisual access is available:

• When working with the managed forms.

• When using Taxi interface with any form item placement functionality.

• In thin and thick clients.

1.5. Restrictions

For file infobase collaboration, all client applications must have the same version. At the same time, the client applications may use any architecture (32- or 64-bit application) and any operating system (Windows or Linux).

Maximum number of concurrent connections per infobase is 1,024.

Online collaboration using file infobases is only supported for network resources that are accessed via SMB protocol (CIFS). These resources can be located on both Windows and Linux computers.

Client application running on macOS does not support network infobases.

Please remember that bitness of add-ins and COM objects (on Windows) must match bitness of the 1C:Enterprise application used (thin or thick client, server, or web server). In other words, if a COM object only has 32-bit version, it cannot be used in the 64-bit version of 1C:Enterprise.

If you want to use 1C:Enterprise on ARM64-based computer systems, keep in mind the following restrictions:

• The utility is not supported on Windows.

• Apple processors are supported only in translation mode.

• Dongles are not supported.

• Automatic update of the client application is not supported.

If you want to use 1C:Enterprise on E2K-based computer systems, keep in mind the following restrictions:

• The utility is not supported on Windows.

• Dongles are not supported.

• Automatic update of the client application is not supported.

1.6. Platform and licensing options

1.6.1. General information

1C:Enterprise platform is available in several distribution packages, and several license types that enable some platform features and restrict others.

Below, you can find distribution package options and license types.

1.6.2. Distribution package options

1C:Enterprise distribution packages:

• Standard version of 1C:Enterprise. Requires a license. Functionality might be restricted by the licenses.

• Training version of 1C:Enterprise (https://1c-dn.com/developer_tools/1c_enterprise_8_platform_training_version/). Does not require a license. The training version has the following restrictions:

  • It cannot be used for actual enterprise accounting purposes.

  • It cannot be used to build distribution packages of mobile applications intended for publication and replication.

  • Data volume is restricted:

    • Maximum number of records in account tables is 2,000.

    • Maximum number of records in main object tables is 2,000.

    • Number of records in object tabular sections is 1,000.

    • Number of records in record sets is 2,000.

    • Number of records from external data sources is 200.

  • Client/server mode is not supported.

  • Infobases are not supported.

  • Local speech recognition is not supported.

  • COM connections are not supported.

  • Passwords and OS authentication are not supported.

  • Printing and saving spreadsheet documents is only supported in Designer mode.

  • Copying multiple spreadsheet document cells is not supported in 1C:Enterprise mode.

  • Training version is slower than the commercial version of 1C:Enterprise.

  • Configuration repository is not supported.

  • Configuration delivery functions are not available.

  • Only one connection can be established per infobase.

  • Separator values are set to separator type defaults.

• 1C:Enterprise. File Management (https://v8.1c.ru/metod/fileworkshop.htm). Does not require a license. This distribution package has the following features and restrictions:

  • 1C:Enterprise infobases are not supported.

  • The following 1C:Enterprise files can be opened and viewed:

    • Spreadsheet documents

    • Text documents

    • Graphical diagrams

    • Geographical schemas

    • HTML documents

1.6.3. License types

1.6.3.1. General information

There are various licenses you may need to use 1C:Enterprise. Only the training version can be used without any license. Licenses are required to operate with various application components. You can find the descriptions of available 1C:Enterprise licenses below.

1.6.3.2. Client license

Purpose: required for using client application in file and client/server mode.

Types:

• CORP client license. Enables all system functionality.

• PROF client license. Allows you to use the system features in accordance with the limitations of the PROF server license.

• 1C:Analytics client license. 1C:Analytics client license enables concurrent operation of multiple users in 1C:Analytics (one session – one user). The number of simultaneous sessions cannot exceed the nominal value of the license. You can use the client license for 1C:Analytics with any server license for 1C:Enterprise.

If the infobase serves no more than 5 concurrent sessions of client applications, technical features and the license allow you to run one session of 1C:Analytics without 1C:Analytics client license.

When you use a PROF-level 1C:Enterprise server license, the 1C:Analytics client license allows you to use the database copy functionality along with Data Accelerator. In this case, you can start Data Accelerator in a single instance.

• Basic license. Restricts the system functionality as follows:

  • Only one user can work with the system at the same time. For more information, see Maintaining the user list.

  • Editing a configuration with Designer is not supported.

  • Client/server mode is not supported.

  • Distributed infobases are not supported.

  • Internet services cannot be provided.

  • Web client mode is not supported.

  • External connection mode is not supported.

  • Extensions are not supported.

1.6.3.3. Server license

Purpose: required for 1C:Enterprise server cluster. This license is required to use client/server mode of 1C:Enterprise. Besides this license, client/server mode also requires client licenses.

1.6.3.4. License extensions

• PROF license extension.

Information: https://www.1c.ru/news/info.jsp?id=25491 (in Russian).

If 1C:Enterprise is purchased before 02/11/2019, you can remove restrictions on simultaneous operation of over 500 user sessions (Designer, external connection, any client application) in one infobase and on the usage of over 12 CPU cores by 1C:Enterprise server cluster processes. Actions depend on the used security system:

• Software license. The update is executed automatically, no additional actions are required.

• HASP security key. You need to receive free special software licenses of the PROF-level license extension on 1C:ITS Portal. Upon activation, the license must be linked to any available dongle for 1C:Enterprise (client or server). You can use the extension license only with a hardware license for which it is received. The instruction on how to update the license is provided with a PIN.

• CORP license extension.

Information: https://www.1c.ru/news/info.jsp?id=25491 (in Russian).

Since 09/10/2019, all CORP hardware license features (HASP dongle) are available only after extending the current CORP hardware license using a special software license. You need to get this license from 1C Licensing Center. Upon activation, the license must be linked to any available dongle for 1C:Enterprise (client or server). You can use the extension license only with a CORP hardware license for which it is received. The instruction on how to get the software license is provided to the user with a PIN. If you use a software license for a CORP license, no additional actions are required.

1.6.3.5. Collaboration system server license

Purpose: required for deploying your own instance of the collaboration system server.

Information: https://1c.ru/news/info.jsp?id=26598 (in Russian).

Features: you can deploy your own instance of the collaboration system server if one of the following tools are available:

• CORP server license.

• 1C:Collaboration server.

1.6.3.6. License for developers (community version)

Purpose: to execute fully-fledged development on 1C:Enterprise platform without purchasing licenses. You cannot use the platform with an activated developer license for commercial purposes.

Information: https://1c.ru/news/info.jsp?id=30506 (in Russian).

Developer license features:

• You can use it only with 1C:Enterprise version 8.3.23 or later.

• The license is available only as a software license.

• You can activate it on one client computer and one server computer at the same time even if these are different computers.

• The license validity period is one week. The license is updated automatically if the Internet connection is available.

• Developer licenses cannot be combined.

• If sessions that use PROF or CORP licenses are connected to the infobase, no more than three client sessions using one developer license can be connected to one infobase at the same time.

• The license is used in the following cases:

  • For a file infobase: if no other license (basic, PROF, or CORP) is found.

  • For a server infobase: if no other license (PROF or CORP) is found. You can use the developer license both as a client license and as a server license.

• Usage statistics are collected and sent to the Update Control Center. Only statistics on using platform features are sent to the Center. Infobase user data is not passed. The statistics are collected from the developer's computer from an application that uses an activated developer license.

The developer license allows you to:

• Ensure concurrent operation of the following sessions in one infobase (licenses are provided by 1C:Enterprise server):

  • No more than three sessions with direct connection.

  • No more than one session connected via a web server.

  • No more than one 1C:Analytics client session.

  • No more than one mobile client session.

• Use the CORP license functionality if no more than 10 licensed sessions run in the infobase.

The developer license does not allow you to:

• Use the license for commercial purposes.

• Access tools that require a feature testing license.

• Bind the license to a dongle.

• Use more than two different developer licenses in one infobase.

• Use more than one production server in a cluster:

  • When you add a production server, an error occurs.

  • If the cluster already contains more than one production server, only one (arbitrary) production server is used.

• Using PROF or CORP client licenses to access a server cluster that uses a developer license as a server license.

1.6.3.7. Feature testing license

Purpose: required to test features in beta testing (feature testing). A feature testing license is an addition to a client or server license of any type.

Information: http://1c.ru/news/info.jsp?id=25182 (in Russian).

Features of the feature testing license:

• License is activated on the computer with:

  • 1C:Enterprise server cluster.

  • Web server extension running with a file infobase where the feature is used.

  • Client application running with a file infobase where the feature is used.

• License may be issued by the server cluster licensing service.

• Number of required feature testing licenses:

  • In client/server mode: equal to or greater than the number of server licenses for the server cluster where testing is executed.

  • In file mode: at least one license.

• License does not grant access to a server cluster or a client application without the respective license (server or client).

• Features available only with a feature testing license are determined upon 1C:Enterprise version release.

• Final licensing requirements of the tested features are determined at the time these features are withdrawn from beta testing.

To obtain a feature testing license, email a request at betaplatform@1c.ru.

1.6.4. CORP license applicability

All 1C:Enterprise features, including the ones available under the CORP license, except for Data Accelerator, are available if not more than 10 client sessions are connected to each infobase of 1C:Enterprise server cluster at the same time. In this case, both server and all the client licenses can be of PROF level. If a further session is connected to any of the server cluster infobases, an error is returned, whenever a server cluster supports features provided by CORP license, and the number of CORP licenses is insufficient.

If 1C:Enterprise uses the features provided by the CORP license, and the number of user sessions in one infobase exceeds 10, then starting a new user session in this infobase is only possible if there is a sufficient number of CORP client and server licenses.

Number of CORP licenses is considered to be sufficient if all the server licenses used by the cluster are CORP level and one of the two conditions is additionally met:

1. Client application has been granted a CORP client license.

2. Client application has been granted a PROF license and at the time of establishing a new client connection, the ratio of licenses used is as follows: UU \<= 1.1 * CL. In the expression:

   • UU. Number of unique users (uniqueness is tracked by username) of the cluster client sessions with any license type, including the starting session.

   • CL. Number of CORP client licenses available for granting by the 1C:Enterprise server regardless of the actual status of the 1C:Enterprise server license granting flag.

Consider an example. A CORP server license and a CORP client license for 50 users are installed on 1C:Enterprise server computer. Such configuration provides for:

• Arbitrary number of client connections if each client connection has a CORP level license.

• Connection of client application with the PROF license to the server will be possible if after connecting the server will maintain sessions of no more than 1.1*50 = 55 unique infobase users. Therefore, a user with PROF license can access an infobase, only if upon connection the number of unique server cluster users (including the session which is started) does not exceed 55.

To prevent the majority of users from getting the denial of service due to an error, only certain users with PROF licenses (out of all users with CORP licenses) can sign in to the CORP-level system. Legally, users with PROF licenses cannot operate in a CORP-level system.

Chapter 2. Installing 1C:Enterprise

2.1. General information

1C:Enterprise is a collection of modules used to develop and use applications (configurations) for enterprise accounting and business activities automation and the configuration or configuration collection.

1C:Enterprise modules are universal and compatible with any configuration (within the scope of the corresponding License Agreement).

A security driver preventing unauthorized access is installed together with 1C:Enterprise.

The installer allows you to install multiple 1C:Enterprise versions on a single computer, select components to install, and select 1C:Enterprise server installation mode.

The 1C:Enterprise launcher maintains the unified infobase list for all platform versions (8.0, 8.1, 8.2, and 8.3).

2.2. Installation options

Install 1C:Enterprise using an installer specific to each supported operating system: Linux OS family (hereinafter referred to as "Linux"), macOS, and Windows OS family (hereinafter referred to as "Windows").

For Windows-based installations, use a standalone installer. Depending on the rights of the user performing the installation and the installation parameters, the installation can be performed in two modes: "for computer" or "for user". For more information on how to select an installation mode, see Specifying installation mode.

1C:Enterprise supports several processor architectures for Linux. There are several ways to install the system. You can use a special installer or the package manager of the used operating system. The difference between these options:

• The installer. A package manager of the operating system is not used in the installer. The installer has a graphical user interface. When using the command-line installer (batch installation), use the startup command-line parameters to select the components to install. The installer is available only for operating systems running on x86/x86-64 processors.

• The package manager. A standard package manager of the used operating system is used for installation. To select components to install, choose preferred installation packages. There is no graphical user interface. This option is available for all supported processors. This is a more common option for Linux network administrators.

For macOS-based installations, a standalone installer is used. This installer does not allow you to select components to be installed.

Before installation, please make sure that your computer is virus-free, the hard drive does not contain any errors, and enough disk space is available for the installation.

See also:

• Installation for Linux.

• Installation for macOS.

• Installation for Windows.

2.3. Installation on Linux

2.3.1. Rules to name distribution files

Note that installation options are not compatible. In other words, if you install 1C:Enterprise using the package manager, delete the system using the package manager. If you install it using the installer, you can delete the system using the appropriate tool available in the directory of a specific version.

File names when using the installer

To install 1C:Enterprise on Linux running on an x86/x86-64 processor, use an installer created based on VMware InstallBuilder. The following installers are available:

• 1C:Enterprise 8. Installs any components. 32-bit and 64-bit versions of the installer are available.

• 1C:Enterprise 8 Thin client. Installs only a thin client and components required to access 1C:Enterprise server. 32-bit and 64-bit versions of the installer are available.

The installers are located in a ZIP archive. ZIP archive and the installer have the same names (accurate to the extension). Archive and installer names look as follows: setup-name-A.B.C.D-arch.ext where:

• name. General installer characteristic:

  • full. Installs all system components.

  • thin. Installs the thin client and server cluster access components.

• A.B.C.D. Full number of 1C:Enterprise version whose installer is used.

• arch. Architecture of 1C:Enterprise version to be installed:

  • i386. x86 processors.

  • x86_64. x86-64 processors.

• ext. File extension.

  • zip. Archive of the installer and accompanying files.

  • run. Installer.

So, if the installer name is setup-full-8.3.24.100-x86_64.run, it is used to install a 64-bit version 8.3.24.100 of 1C:Enterprise, which will allow installing all system components.

All installers offer similar user experience. Therefore, only general information for 1C Enterprise 8 installation is provided below.

The ZIP archive also contains the installAsRoot executable file. The application simplifies the system installation process for an inexperienced user. If you run this application, the following will happen:

• The application checks whether you have superuser rights (root).

• If you do not have them, the acquisition of these rights will be initiated. To get the rights, enter the superuser password in the dialog box opened by the installAsRoot application.

• If the password is correct, the installer with the superuser rights will be started in interactive graphic mode.

For an experienced user, the installAsRoot application startup is similar to the following command-line option:

sudo ./setup-*.run

In this example, "*" refers to the remaining part of the installer name described earlier in this section. If you run installAsRoot in a directory that has several RUN files, the installer whose file name is the first in the search results for files by the "setup-*.run" mask will be started.

File names when using the package manager

When you use a package manager, the 1C:Enterprise distribution package for Linux is provided in several packages. These packages are used to install both client applications and server clusters. Package files have the following names: 1c-enterprise-<version1>-<add-in>_<version2>.<arch>.<extension>, where:

• <add-in>:

  • client. 1C:Enterprise client applications (thick client and thin client).

  • thin-client. 1C:Enterprise thin client (file infobase mode is not supported).

  • common. Common 1C:Enterprise add-ins.

  • server. 1C:Enterprise server add-ins and the integrity monitoring utility.

  • ws. Adapter for publishing a web client and 1C:Enterprise Internet services on Apache HTTP Server of supported versions.

  • crs. Configuration repository server.

  • An add-in name can end with the "-nls" suffix. This means that a package with this name contains additional national resources (in addition to Russian and English localizations) for the respective package. You can find the server add-in in two files: server (the server and resources in Russian and English) and server-nls (additional national resources).

• <version1>. Full version number of 1C:Enterprise package. All version elements are dot-separated. For example, for 1C:Enterprise version 8.3.22.100, version1 of the package name will contain the 8.3.22.100 string.

• <version2>. Full version number of 1C:Enterprise package. The first three number elements are dot-separated. The last (fourth) number element is preceded by a hyphen ("-"). For example, for 1C:Enterprise version 8.3.22.100, version2 of the package name will contain the 8.3.22-100 string.

• <arch>. Processor architecture for which this package is used:

  • aarch64. ARM64 processors (RPM version).

  • amd64. x86-64 processors (DEB version).

  • arm64. ARM64 processors (DEB version).

  • e2k. E2K processors (RPM version).

  • e2k-8c. E2K processors (DEB version).

  • i386. x86 processors.

  • x86_64. x86-64 processors (RPM version).

• <extension>:

  • rpm. RPM package version.

  • deb. DEB package version.

If necessary, the required package file name is generated according to the rules above. If the name of the package you install is required, it is specified based on the add-in name. For example, the name of the common package for DEB version 8.3.22.100 looks as follows: 1c-enterprise-8.3.22.100-common_8.3.22-100-arm64.deb.

2.3.2. Installing using the installer

2.3.2.1. About installer

2.3.2.1.1. General information

To begin the installation, start the previously received installer (*.run file). Before you start the installer, make sure it has the execution access right. The access right must be granted to the current user. If necessary, you can configure the access right for a group and other users. To set the execution right, use the chmod operating system command or a dialog box of file properties in the graphical interface. Setting the right might require superuser rights (root).

You can start the installer either in interactive or batch mode. In this section, you can read about the installation in interactive mode.

The installer is an installation wizard. You can proceed through the wizard pages by clicking Next >. On every page of the wizard, provide information required for 1C:Enterprise installation. The installer details will contain the pages to be ignored if you select the "for user" installation mode.

Before the installer starts, the user will be prompted to select the language in which the installer will generate its interface. The same language will be selected to install the respective interface.

The language list contains only those languages in which user interfaces of 1C:Enterprise applications are implemented.

During the installation, the installer might display a list of packages required for the correct operation of 1C:Enterprise. This list is generated if the installer has not found the packages on the computer. Manually install the missing packages (from the displayed list) using the package manager of your operating system. The installation requires superuser rights (root).

Every wizard step is briefly described below. The examples illustrate installation of the full 64-bit 1C:Enterprise distribution package.

2.3.2.1.2. Welcome screen

1C:Enterprise installation wizard starts with Welcome screen.

2.3.2.1.3. Selecting components

On this page, you need to select components to be installed and an installation directory. The component list depends on what exactly you need to have installed. Some standard installation scenarios are described in a special documentation section.

Select components using the check box next to the component description.

You can install the following components:

2.3.2.1.4. Starting installation

Click Next > to start the installation procedure that:

• Creates required directories.

• Copies files for selected components.

• Creates configuration files.

• Registers server software components.

• Creates shortcuts in the application list to start 1C:Enterprise applications.

The installation procedure is displayed with an indicator. Notes to the indicator describe the actions being executed.

2.3.2.1.5. Installation completion

Once the installation is completed, the installer notifies the user of it.

Click Finish to start the installation process. Before the installation of 1C:Enterprise, the following will be made:

• An attempt to install the add-ins required for 1C:Enterprise operation if these add-ins are absent on the computer or there are versions that do not meet the 1C:Enterprise system requirements.

• An attempt to install True Type fonts from Microsoft Core Fonts for Web. The installation will be performed as follows:

  • The installer searches for the installed package with the required fonts on the current computer.

  • If no fonts are found, the fonts will be installed from the official repository of the used operating system.

  • If the official repository does not have the required fonts, they will be installed from the following sources:

    • http://dfn.dl.sourceforge.net/sourceforge/corefonts/

    • http://downloads.sourceforge.net/corefonts/

    • http://heanet.dl.sourceforge.net/sourceforge/corefonts/

    • http://internode.dl.sourceforge.net/sourceforge/corefonts/

    • http://jaist.dl.sourceforge.net/sourceforge/corefonts/

    • http://kent.dl.sourceforge.net/sourceforge/corefonts/

    • http://nchc.dl.sourceforge.net/sourceforge/corefonts/

    • http://switch.dl.sourceforge.net/sourceforge/corefonts/

    • http://ufpr.dl.sourceforge.net/sourceforge/corefonts/

    • http://voxel.dl.sourceforge.net/sourceforge/corefonts/

The same actions will take place during the batch installation.

Once the installation is completed, 1C:Enterprise is ready for use.

2.3.2.2. Batch installation

Use the installer to install 1C:Enterprise both in interactive mode and batch mode. In this mode, installation can be performed without the window manager, completely in console mode. Batch installation is applied when you update the client application.

Enable batch mode by specifying the --mode unattended command in the installer command line. To specify components to be installed, use the --enable-components command. Components to be installed are listed by comma-separated parameters of this command. The following parameters are available:

Let's consider a simple example. Perform the installation with the following parameters:

• 1C:Enterprise server cluster, administration tools, JRE, and web server operations.

• 1C:Enterprise version 8.3.24.100.

• Install the Russian and English interface languages.

• Perform the installation for a 64-bit operating system.

For these parameters, use the installer for the full version. The installation command line will look as follows:

setup-full-8.3.24.100-x86_64.run --mode unattended --enable-components server,ws,server_admin,liberica_jre,ru

As noted earlier, the installer is based on VMware InstallBuilder. This documentation contains only system commands that are required to install 1C:Enterprise. For more information about other commands, see VMware InstallBuilder user documentation.

2.3.3. Installing using the package manager

Systems running on Linux use a lot of package managers that have different names and used commands. For more information on which commands to use to install the software from files, see the documentation of a package manager that is used to install your operating system.

1C:Enterprise packages depend both on other platform packages (this will be mentioned below) and on various libraries that are assumed to be already installed on the computer. To facilitate resolving such dependencies, the distribution package of client applications includes the v8-install-deps.sh batch file. Run this batch file as an administrator (root). While running, it will install the libraries (and specific library versions) required for the 1C:Enterprise platform operation. After resolving the dependencies, you can install the client application.

During installation, consider the following dependencies between packages:

• common has no dependencies.

• server depends on common.

• ws depends on common.

• crs depends on common, server, and ws.

• client depends on server.

• thin-client has no dependencies. No other 1C:Enterprise packages are required for a thin client. It conflicts with the common package. You can install either thin-client or other packages.

• National resource packages depend on their package.

To install a package, first install all the packages that this package depends on. For example, to install the 1C:Enterprise thick client and Designer, first install the common and server packages, and then install the client package.

See also:

• Dependencies in Linux (see On Linux).

2.4. Installation for macOS

Client application distribution package is stored in the disk image file for macOS (*.dmg files). The installer itself is "inside" the disk image. You cannot choose which components to install. Two distribution delivery options are available:

1. To install thin and thick client applications, and 1C:Enterprise server cluster access components. Hard drive image name is clientosx_A_B_C_D.dmg.
2. To install thin client application and 1C:Enterprise server cluster access components. Hard drive image name is thin.clientosx_A_B_C_D.dmg.

The A_B_C_D text in the image file name (and further, in the installer names) means the full platform version whose installer is located on the disk image file. The file with the installer distribution image for the thin client version 8.3.13.100 will be named thin.clientosx_8_3_13_100.dmg.

You need to know the name of the user with administrative privileges and the password to complete the installation. To start installation:

• Double-click the image file. A new window with contents of the image file opens.

• To install the client application itself, double-click the file named as follows:

  • 1cv8-client-A.B.C.D.pkg. Thin and thick client application installer.

  • 1cv8-thin-client-A.B.C.D.pkg. Thin client application installer.

• The client application installation wizard opens. On the first page, click Next. On the second page, click Install. After you enter credentials of a user with administrative rights, the 1C:Enterprise client application will be installed.

2.5. Installation for Windows

2.5.1. Available installers

The following installers are available:

• 1C:Enterprise 8. Installs any components. 32-bit and 64-bit versions of the installer are available.

• 1C:Enterprise 8 Thin client. Installs only a thin client and components required to access 1C:Enterprise server. 32-bit and 64-bit versions of the installer are available.

• 1C:Enterprise 8 (x86-64) Server. Allows you to install only a 64-bit 1C:Enterprise server. Only 64-bit version of this installer is available.

All installers offer similar user experience. Therefore, only general information for 1C Enterprise 8 installation is provided below.

2.5.2. About installer

2.5.2.1. General information

An installation wizard carries out the installation procedure. You can proceed through the wizard pages by clicking Next >>. To start the wizard, run setup.exe from the directory containing the distribution package you have selected. On every page of the wizard, provide information required for 1C:Enterprise installation. The installer details will contain the pages to be ignored if you select the "for user" installation mode.

When you start setup.exe using the /S parameter, installation is performed in silent mode. In this case, the installation mode will be defined first. Then its parameters will be obtained from the 1cestart.cfg file that matches the defined installation mode. If this file is not available, the default parameters will be used. Then 1C:Enterprise will be installed in the defined installation mode with the defined parameters.

Using the installer, you can specify whether to search a dongle when starting the installed client application. The installer writes the UseHwLicenses parameter to the 1cestart.cfg file of a user on whose behalf 1C:Enterprise is installed. For the installer to be able to modify the configuration file, use any of the following methods:

• Specify the USEHWLICENSES command line option to start setup.exe:

setup.exe USEHWLICENSES=0

• Specify the USEHWLICENSES parameter in the setup.ini file in the CmdLine parameter of the Startup group.

Every wizard step is briefly described below. The examples illustrate installation of the full 64-bit 1C:Enterprise distribution package.

2.5.2.2. Specifying installation mode

To select an installation mode, analyze the following data:

1. Value of the InstallForUsers parameter of the 1cestart.cfg configuration file and the ALLUSERS parameter of the installer startup command line.
2. Access rights of the user installing 1C:Enterprise.

After the analysis, select the installation mode. The "Parameter value" column (in the table below) contains the resulting installation mode value obtained considering priorities. The resulting parameter value is determined as follows:

• Parameter value is not specified (first-time installation). In this case, the parameter value is 0.

• 1cestart.cfg configuration file contains a value, the installer command line is blank. In this case, the parameter value is equal to the value from the 1cestart.cfg configuration file.

• Installer startup command line contains the ALLUSERS parameter. In this case, the parameter value is equal to the value from the command line regardless of the 1cestart.cfg configuration file.

The user is considered to have administrator rights if at least one of the following requirements is met:

• User is a local administrator of the personal computer.

• User is a member of the local administrators group.

• User has the right to install applications (the AlwaysInstallElevated policy).

Installation mode options are shown in the table:

Information to the table:

• C. Installs "for computer" without providing the user with a choice.

• U. Installs "for user" without providing the user with a mode choice.

• D. Opens a dialog box where the user can select an installation mode.

• If the user does not have administrator rights and the installation mode is between 0 and 2 (inclusive), "D" mode is selected for interactive installation and the second mode is used in other cases.

• If a mode that requires an administrator password is selected during the installation and the current user does not know this password, the installation cannot be performed.

Depending on the selected installation mode, different directories will be used in further installer dialog boxes as default directories to install the system:

• Installation "for computer": %PROGRAMFILES% or %PROGRAMFILES(x86)%.

• Installation "for user": %LOCALAPPDATA%\Programs.

To ensure that installation "for user" is successfully completed, Windows must contain an installed Microsoft Visual C++ Re-distributable package included in 1C:Enterprise version to be installed (file: vc_redist.x86.exe or vc_redist.x64.exe). In any case, the installation of this package requires local administrator or network administrator rights.

If the installation mode must be selected by the user after the actions described above, the User text is the actual name of the user that performs the installation.

Once the user confirms their choice in the dialog box, the installation mode is saved to the 1cestart.cfg configuration file.

See also:

• 1cestart.cfg configuration file.

2.5.2.3. Welcome screen

This is the starting window of the 1C:Enterprise installation wizard.

2.5.2.4. Selecting components

On this page, you need to select components to be installed and an installation directory. The component list depends on what exactly you need to have installed. Some standard installation scenarios are described in a special documentation section.

If a component needs to be installed, select it in the list. If a component is not required, do not select it. To select a component, click an icon to the left of its name or press Spacebar. Select the item you need.

Components to be installed or skipped are displayed as shown below:

The following items are numbered:

1. Component that will be installed on the user computer (selected component).
2. Component that will not be installed on the user computer (skipped component).

You can install the following components:

Regardless of the 1C:Enterprise installation directory (the Folder: field and the Edit button), some directories of the installed system will have predefined locations. The installation directory depends on the installation mode as well as the operating system and 1C:Enterprise bitness. The default directories are:

• Installation "for computer":

  • 1C:Enterprise x32 in x64 operating system: %PROGRAMFILES(x86)%\1cv8\A.B.C.D.

  • Otherwise: %PROGRAMFILES%\1cv8\A.B.C.D.

• Installation "for user":

  • 1C:Enterprise x32 in x32 operating system: %LOCALAPPDATA%\Programs\1cv8\A.B.C.D.

  • 1C:Enterprise x32 in x64 operating system: %LOCALAPPDATA%\Programs\1cv8_x86\A.B.C.D.

  • 1C:Enterprise x64 in x64 operating system: %LOCALAPPDATA%\Programs\1cv8_x64\A.B.C.D.

After installation, a local configuration file will be generated. The file will have two specified parameters: InstalledLocation and InstallComponents. The values of these parameters will be set according to settings specified during installation. The location of this configuration file depends on the selected installation mode: "for computer" or "for user".

The integrity monitoring utility is installed by default to the same directory as 1C:Enterprise. Installation directory can be changed, if needed. To change the installation directory, select the Integrity monitoring component and click Edit….

The installation directory of integrity monitoring utility cannot be changed if the component is skipped.

Installation of the integrity monitoring utility is not recorded in the local configuration file. When installing any version of 1C:Enterprise, you need to manually mark this utility for installation.

2.5.2.5. Selecting default interface language

At the next step, the installer prompts you to select the default interface language.

You need to specify one of the interface languages as a default interface language.

After the installation is completed, the conf.cfg file that describes the default interface language is created in the C:\Program Files\1cv8\conf directory.

To use 1C:Enterprise with a non-default interface language, specify the language at startup using the /L command-line parameter.

2.5.2.6. Installing 1C:Enterprise server

If the 1C:Enterprise 8 server component is selected for installation, a wizard page will be available. On this page, you can select the 1C:Enterprise server installation mode and the user to run the server if it is installed as a Windows service.

If 1C:Enterprise is already installed as a Windows service on the computer, the installer will reinstall the service.

2.5.2.7. Installation start

Click Install to start the installation procedure that:

• Creates required directories.

• Copies files for selected components.

• Creates configuration files.

• Registers server software components.

• Creates 1C:Enterprise startup shortcut on the desktop.

• Starts 1C:Enterprise server if you install the server as a Windows service.

In addition, a separate entry will be created for each version in the Install and delete applications component on Windows control panel. Entries must be of the following kind: 1C:Enterprise 8 (A.B.C.D).

2.5.2.8. Installing the protection driver

After the installation is completed, the installation wizard prompts you to install HASP Device Driver to protect you from unauthorized software use.

You have to install the driver if you have a dongle for plugging into a USB port of this computer and:

• User has License Agreement for the use of the 1C:Enterprise main distribution kit.

• User has the 1C:Enterprise client license for at least one workplace.

• User has the 1C:Enterprise server license.

When installing the protection driver, a web-based driver management interface is installed automatically. To minimize risks and increase safety for 1C:Enterprise servers and user workstations, it is recommended that you disable the web-based protection driver interface when installing the driver. To do this, select the Disable 1C:Enterprise 8 hardware license key features that are not used (recommended) check box.

2.5.2.9. Installation completion

If the installation is successful, the final page of the installation wizard opens. On this page, you can decide whether to open a file with information recommended for reading before using this system version (to do it, select the Open Readme file check box). You can also install client application distribution packages to simplify the automated update of these applications on user computers.

To install client application distribution packages, select the checkbox: Store thin client distribution packages in the installation folder to update clients automatically. We recommend that you install it only on computers which support the web server extension on the installation wizard page. The check box becomes available when the following conditions are met:

• Web server extension modules component is selected for installation.

• Directory with 1C:Enterprise installation files contains a file of the following kind: win-mac-clients-distr_A.B.C.D.exe or all-clients-distr_A.B.C.D.exe.

The checkbox state is saved to the InstallComponents parameter of the 1cestart.cfg file (using the COPYTHINCLIENTDST key). Installation of the client application distribution package requires administrator rights.

Click Done to complete the installation. Further behavior (after closing the installer dialog box) depends on the check boxes selected on this page:

• Show Readme opens the readme.htm file in the default interface language.

• Store thin client distribution packages in the installation folder to update clients automatically… starts the installation of client application distribution packages.

See also:

• Automated update of client applications (see Automated client application update on a remote computer).

• 1cestart.cfg configuration file.

2.5.3. Recommendations for component registration

The installer registers some components such as COM connection. The registration method depends on the installation mode.

• Installation "for the computer". COM connection (the V83.COMConnector COM object) and client application (the V83.Application COM object) are registered "for the computer".

• Installation "for the user". COM connection (the V83.COMConnector COM object) and client application (the V83.Application COM object) are registered "for the user".

1C:Enterprise version to which the COM connection is established (using V83.COMConnector) and 1C:Enterprise version from which the COM connection is generated must be identical or differ in the first two digits. In other words, 1C:Enterprise 8.3 can establish a COM connection with 1C:Enterprise 8.2, 8.1, and so on, but 1C:Enterprise 8.3.6 cannot establish a COM connection to 8.3.5. At the same time, 1C:Enterprise 8.3.6.2100 can a establish COM connection with 8.3.6.2100.

If during component registration using regsvr32, The module ... was loaded but the call to DllRegisterServer failed with error code 0x80070005 error message is displayed, it means that the current user does not have sufficient rights to edit the system registry or files in the System32 directory. In this case, you need to register the components on behalf of the user that has administrative rights. When starting regsvr32, use Run as administrator context menu command.

2.6. Typical 1C:Enterprise installation scenarios

2.6.1. On Linux

2.6.1.1. General information

This section contains typical scenarios of installing 1C:Enterprise components on Linux broken down by different installation options. Each installation scenario includes a list of components and packages to install. You will also find installation specifics to consider, if any.

After installation of the client applications, shortcuts for the launcher (1cestart), thin client (1cv8c), and thick client (1cv8) are added to the application menu of the desktop environment. The shortcuts are only created for installed applications. The shortcuts are created in the Finance subcategory of the Office category.

Installation requires superuser (root) rights.

2.6.1.2. Thin and thick client

1C:Enterprise installer

Allow installation of the following components:

• 1C:Enterprise

• 1C:Enterprise – Thin client, file mode

Package manager

Install the following packages:

• common and, if required, the common-nls resources

• server and, if required, the server-nls resources

• client and, if required, the client-nls resources

Result

The following applications can be started:

• Designer

• Thin client

• Thick client

The following infobases can be used:

• File infobase (local version)

• File infobase (network version)

• Client/server mode

• Any infobase with access via web server

2.6.1.3. Thin client

1C:Enterprise installer

Allow installation of the following components:

• 1C:Enterprise – Thin client, file mode

Package manager

Install the following packages:

• thin-client and, if required, the client-nls resources

Result

Thin client can be started.

The following infobases can be used:

• File infobase (local version)

• File infobase (network version)

• Client/server mode

• Any infobase with access via web server

2.6.1.4. Configuration repository server (TCP protocol)

1C:Enterprise installer

Allow installation of the following components:

• 1C:Enterprise configuration repository server

Package manager

Install the following packages:

• common and, if required, the common-nls resources

• server and, if required, the server-nls resources

• crs and, if required, the crs-nls resources

Result

You can start the server of 1C:Enterprise configuration repository over TCP.

2.6.1.5. Configuration repository server (HTTP protocol)

1C:Enterprise installer

Allow installation of the following components:

• Web server extension modules

• 1C:Enterprise configuration repository server

Package manager

Install the following packages:

• common and, if required, the common-nls resources

• server and, if required, the server-nls resources

• ws and, if required, the ws-nls resources

• crs and, if required, the crs-nls resources

Result

You can start the server of 1C:Enterprise configuration repository over HTTP.

2.6.1.6. Enabling web client publication

1C:Enterprise installer

Allow installation of the following components:

• Web server extension modules (in addition to the selected components)

Package manager

Install the following packages in addition to other packages:

• common and, if required, the common-nls resources

• server and, if required, the server-nls resources

• ws and, if required, the ws-nls resources

Result

To publish a web client or a web service, use a dialog box for web server publication in Designer or the webinst utility (for the web client only). For more information, see Setting up web services for 1C:Enterprise.

2.6.1.7. Integrity monitoring utility

1C:Enterprise installer

Allow installation of the following components:

• Integrity monitoring (if necessary, you can change the installation directory)

Package manager

Install the following packages:

• server and, if required, the server-nls resources. To install it to another directory, use package manager parameters of the operating system.

Result

You can use the integrity monitoring utility.

2.6.1.8. Administrative console utility

1C:Enterprise installer

Allow installation of the following components:

• Additional administration functions.

Package manager

Install the following packages:

• client and, if required, the client-nls resources

• server and, if required, the server-nls resources

Result

You can use the administrative console.

2.6.2. On macOS

Client application installer for macOS does not support configurable installation options. All available components are installed.

2.6.3. On Windows

2.6.3.1. General information

This section contains typical examples of 1C:Enterprise components installation on Windows.

For each installation option, a list of components to be installed and specific installation instructions (if any) are provided.

2.6.3.2. Thin and thick client

To install this installation option of 1C:Enterprise, mark the following components for installation:

• 1C:Enterprise

• 1C:Enterprise – Thin client, file mode.

If the local client key is used, install HASP Device Driver. The driver must be installed before the protection key is inserted into the USB port of a computer. If the network protection key is used, there is no need to install the HASP Device Driver. For more information about customizing access to the protection key, see Protection against unauthorized use: features and settings.

The following applications can be started:

• Designer

• Thin client

• Thick client

The following infobases can be used:

• File infobase (local version)

• File infobase (network version)

• Client/server mode

• Any infobase with access via web server

2.6.3.3. Thin client

For this 1C:Enterprise installation option, mark the 1C:Enterprise – Thin client, file mode component for installation.

If the local client key is used, install HASP Device Driver. The driver must be installed before the protection key is inserted into the USB port of a computer. If the network protection key is used, there is no need to install the HASP Device Driver. For more information about customizing access to the protection key, see Protection against unauthorized use: features and settings.

Thin client can be started.

The following infobases can be used:

• File infobase (local version)

• File infobase (network version)

• Client/server mode

• Any infobase with access via web server

2.6.3.4. Thin client – client/server mode

For this 1C:Enterprise installation option, mark the 1C:Enterprise – Thin client component for installation.

If the local client key is used, install HASP Device Driver. The driver must be installed before the protection key is inserted into the USB port of a computer. If the network protection key is used, there is no need to install the HASP Device Driver. For more information about customizing access to the protection key, see Protection against unauthorized use: features and settings.

Thin client can be started.

The following infobases can be used:

• Client/server mode

• Any infobase with access via web server

2.6.3.5. Thick client

To install this installation option of 1C:Enterprise, mark the 1C:Enterprise component for installation.

If the local client key is used, install HASP Device Driver. The driver must be installed before the protection key is inserted into the USB port of a computer. If the network protection key is used, there is no need to install the HASP Device Driver. For more information about customizing access to the protection key, see Protection against unauthorized use: features and settings.

The following applications can be started:

• Designer

• Thick client

The following infobases can be used:

• File infobase (local version)

• File infobase (network version)

• Client/server mode

2.6.3.6. Configuration repository server (TCP protocol)

To install 1C:Enterprise configuration repository server on a computer and use it via TCP, mark 1C:Enterprise configuration repository server component for installation.

2.6.3.7. Configuration repository server (HTTP protocol)

To install 1C:Enterprise configuration repository server on a computer and use it via HTTP, mark the following components for installation:

• Web server extension modules

• 1C:Enterprise configuration repository server

2.6.3.8. Enabling web client or web service publication

To enable publication of web client on the computer used for installation, mark Web server extensions modules component for installation.

To publish web client or web service, use web server publication dialog box or webinst utility (for web client only). For more information, see Setting up web services for 1C:Enterprise.

2.6.3.9. Enabling Designer usage

To enable Designer usage, mark 1C:Enterprise component for installation.

2.6.3.10. Installation with Windows administrative tools

2.6.3.10.1. Installation using group policies

When installing using group policies, specify the language transformation file to select the installation language. File names match Microsoft Windows LCID in decimal format (with .mst extension). Transformation file for the Russian language is called 1049.mst.

Besides, select adminstallrestart.mst transformation file. In this case, 1C:Enterprise will offer to restart the computer and install the newer version in case of client and server version mismatch. Administrators need to make sure that distribution package is added to group policies prior to the installation.

Several 1C:Enterprise versions can be installed using group policies. To install a new version, create a new installation in group policies.

2.6.3.10.2. Installation with logon script

The system can be installed using the script that is executed during user authorization in the domain. The domain administrator starts the script job.

If the user does not have software installation rights, the administrator needs to specify that the installation script is started on behalf of the user that has such rights. For an example of such script, see adminstall.cfg.

The script allows you to install and delete several versions of 1C:Enterprise. To do this, call installOrUninstall procedure with the required parameters (for the script example, see adminstall.cfg).

To install the new version, the administrator only needs to edit the shared network resource paths and specify the product code that can be found in setup.ini file.

Additionally, adminstallrelogon.mst transformation file must be specified. In this case, 1C:Enterprise will offer to finish the current session and install the newer version in case of client and server version mismatch. The administrator needs to ensure that the script is updated and the distribution package with the new version is available on the network resource.

2.6.3.10.3. Version update

When installing the 1C:Enterprise language using administrative tools, the adminstall.cfg file is created in the configuration file directory (see adminstall.cfg).

If the required 1C:Enterprise version is not found on a computer when starting and the user does not have sufficient rights to install the required version, the user will be offered to take action specified in the adminstall.cfg file: restart the computer or sign out and sign in again.

2.6.3.11. Integrity monitoring utility

To install this installation option of 1C:Enterprise, mark the Integrity monitoring component for installation. Edit the installation directory if needed.

2.6.3.12. Administrative console utility

To install this installation option of 1C:Enterprise, mark the Additional administration functions component for installation.

2.7. Recommendations for system deployment

To simplify automated installation of new 1C:Enterprise versions on the user computer (including the initial system installation), the following file structure in a network directory is recommended (an option of a server directory on a computer running Windows is described):

On the figure above:

• \Server\1CEDistr is a directory on Server where files required for the system deployment are located. On a computer running Linux or macOS, the \Server\1CEDistr directory must be mounted on the computer. Using UNC paths on Linux and macOS is not supported.

• 1cestart is the launcher. For initial installation, start the launcher from this network directory. You can start the launcher from the local hard drive if paths to distribution packages are correctly set up in configuration files and the launcher settings allow automatic installation of the new application version.

It is recommended that you import the launcher from the latest 1C:Enterprise version that is installed in a local network.

• ibcommon.v8i is a list of shared infobases (the name can be changed).

• 1cescmn.cfg is a common configuration file. It is recommended that you specify the following parameters in it:

  • CommonInfoBases=FileNameWithTheListOfCommonInfobases.v8i. Set this parameter to display the list of infobases in the launcher.

  • InstallComponents. Use this parameter to specify the components you need to install on user computers.

  • DistributiveLocation. Use this parameter to specify 1C:Enterprise distribution package directory.

• 8.3.18.100 is a directory with the following 1C:Enterprise distribution packages:

  • Win32. Distribution package directory of the 32-bit application version for Windows.

  • Win64. Distribution package directory of the 64-bit application version for Windows.

  • macOS. Distribution package directory of the application version for macOS. The distribution packages are located in the *.dmg files.

  • Lin32. Distribution package directory of the 32-bit application version for Linux. The distribution packages are located in the *.run files.

  • Lin64. Distribution package directory of the 64-bit application version for Linux. The distribution packages are located in the *.run files.

• 8.3.18.150 is a directory with 1C:Enterprise distribution packages. The directory structure is similar to the directory with version 8.3.18.100 (see the previous paragraph).

In this example, the following common configuration file is used to install all components and two languages: Russian and English:

Content of 1cescmn.cfg file:

CommonInfoBases=ibcommon.v8i

DistributiveLocation=\\Server\1CDistr

DistributiveLocation=/Volumes/Server/1CDistr

DistributiveLocation=/mnt/server/1CDistr

InstallComponents=DESIGNERALLCLIENTS=1 SERVER=1 WEBSERVEREXT=1 CONFREPOSSERVER=1 SERVERCLIENT=1 CONVERTER77=1 LANGUAGES=ru

When a new 1C:Enterprise version is released (for example, 8.3.18.200), do the following:

• In the \Server\1CDistr directory, for version 8.3.18.200, create a directory structure similar to the previously created versions.

• Place the distribution package files in the matching directories considering the operating system and the bitness (for Windows).

1C:Enterprise will automatically complete the installation on startup. Remember the following features when using such a deployment scheme:

• On Windows:

  • Launcher always installs 1C:Enterprise into the default folder. To change the installation directory, run the installer for the required version (setup.exe) manually.

  • Only the InstallComponents parameter from the common configuration file is used during installation. Other parameters do not affect the installation process and are not copied from the common configuration file to the local configuration file. In the example above, the following components are used:

InstallComponents=DESIGNERALLCLIENTS=1 SERVER=1 WEBSERVEREXT=1 CONFREPOSSERVER=1 SERVERCLIENT=1 CONVERTER77=1 LANGUAGES=ru

• During installation, the CommonCfgLocation parameter is written to the local configuration file. Its value is the path to the common configuration file, which is located in the deployment directory. In the example above, the path to this file is: \server\1cdistr\1cescmn.cfg. Parameters specified in this file will be used by both the launcher and in the startup dialog box of the client application (see Startup window settings).

• On Linux:

  • Server directory where the installation files are located must be mounted on the client computer in any way possible. On all client computers running Linux, this directory must be mounted at a mount point with the same name. In the example above, the \Server\1CDistr directory is mounted at the /mnt/server/1CDistr mount point. Use forward slashes ("/") to specify the path.

  • InstallComponents parameter of the common configuration file is ignored.

• On macOS:

  • Server directory where the installation files are located must be mounted on the client computer in any way possible. On all Apple client computers, this directory must be mounted at the mount point with the same name. In the example above, the \Server\1CDistr directory is mounted at the /Volumes/Server/1CDistr mount point. Use forward slashes ("/") to specify the path.

  • InstallComponents parameter of the common configuration file is ignored.

If the infobase is accessed via a web server, you can use other delivery methods for a client application distribution package (see Automated client application update on a remote computer).

2.8. Installing and configuring additional software

2.8.1. On Linux:

2.8.1.1. Recommendations for using file infobases

When you use infobases in file mode on a Linux-based computer, please consider the following:

• When you connect a network resource on Linux using the mount.cifs command, do not use the nobrl key (https://www.samba.org/~ab/output/htmldocs/manpages-3/mount.cifs.8.html). \$\$\$remove it\$\$\$

• When you grant access to the infobase directory using Samba, do not specify the locking=no parameter for a resource to be published in the smb.conf file (https://www.samba.org/~ab/output/htmldocs/manpages-3/smb.conf.5.html).

• If multiple users are expected to access a file infobase on the same computer, consider the following:

  • On Linux, the user that started the file creation process is specified as the owner of the created file. Files created in 1C:Enterprise have permission to be read and written only by their owner or the owner group. As a result, when several concurrent users access a file infobase, only the first user can access the created files. To work with the infobase concurrently, all users need to be in the same group and this group needs to be set as the owner of the infobase directory. After this, select the set-group-ID check box for this directory using the chmod g + s ib_dir command, where ib_dir is an infobase directory name. As a result, the group that owns the main infobase directory is assigned as the owner of any files to be created in this directory, instead of the main group of a user who creates the files.

  • On Linux, 1C:Enterprise creates files with explicit 0660 permissions (read/write privileges for the file owner and owner group). Manually setting a value for file creation mode mask (umask) in the environment can only result in clearing some set permissions and toughening file creation rules. Since access permission flags for other users are not set for the platform-created files, you cannot modify them using umask.

  • If the infobase is accessed using a Linux-based web server, add the user on whose behalf Designer is started to the www-data or apache group. Then, make it the owner of the infobase directory and set the set-group-ID flag for this directory. Next, add the umask 0002 string to one of the files: /etc/apache2/envvars, /etc/default/apache2, or /etc/sysconfig/httpd, depending on the distribution package used. Adding this string prevents users from clearing a flag that allows the owning group to write (g-w) to the files created by Apache web server.

If the OS manages services using the systemd service, edit the /etc/systemd/system/apache2.service.d/override.conf or /etc/systemd/system/httpd.service.d/override.conf configuration file of the Apache2 service. For that, run the following command on behalf of the superuser (root): systemctl edit apache2 or systemctl edit httpd and enter information about changing the umask value into the file:

[Service]

UMask=0002

This procedure is also used to configure Linux for shared access to configuration repository. However, the configuration repository directory is used instead of the infobase directory.

2.8.1.2. Installing fonts

To ensure correct 1C:Enterprise behavior on Linux, install the fonts from the Microsoft Core Fonts set. These fonts can be installed using any of these methods:

• Use the fonts package that is included in general distribution package (checked in each distribution package).

• For RPM version of Linux, installation instructions are available at: https://corefonts.sourceforge.net/.

• Manual installation is available as well. To do this:

  • Download all font files from: https://sourceforge.net/projects/corefonts/files/the%20fonts/final/.

  • Unpack the files.

  • Place the font files into the ~/.fonts directory of the user on whose behalf 1C:Enterprise is started. Here, ~ is a home directory of the user.

2.8.1.3. Operating system authentication when using Apache web server

When using Apache web server, operating system authentication can be configured for thin client and web client. This section assumes that Apache web server is already installed on the computer and configured for web client access.

Follow these steps:

• Install mod_auth_kerb authentication module. It is included in most distribution packages. You only need to install the package. For Fedora, this package is called mod_auth_kerb, and for Debian, it is called libapache2-mod-auth-kerb. If your operating system does not include this module, you can download the source code from the project homepage: https://modauthkerb.sourceforge.net/.

• The following installation options are available:

  • Install the module from the OS distribution package. In this case, you only need to restart the web server to activate the module.

  • If you compile and install the module separately (the installation manual is available at: https://modauthkerb.sourceforge.net/install.html), add the string below to the Apache web server configuration file (httpd.conf) and restart Apache:

LoadModule auth_kerb_module /path_to_the_file/mod_auth_kerb.so

To authenticate, the module needs a private Kerberos key for HTTP/Server.domain@DOMAIN. You need to generate this key according to Kerberos authentication setup documentation. Note that for the account associated with the HTTP/Server.domain@DOMAIN name, you need to select the Account is trusted for delegation check box.

For example, let us assume that the file with the key is called HTTP.keytab and it is located in the home directory of usr1cv8 user.

You need to add the following strings to the section describing the virtual directory of the web server:

<Directory "/home/usr1cv8/www/MyApp">

AllowOverride None

Options None

Order allow,deny

Allow from all

SetHandler 1c-application

ManagedApplicationDescriptor /home/usr1cv8/www/MyApp/default.vrd

AuthName "1C:Enterprise web client"

AuthType Kerberos

Krb5Keytab /home/usr1cv8/HTTP.keytab

KrbVerifyKDC off

KrbDelegateBasic off

KrbServiceName HTTP/Server.domain@DOMAIN

KrbSaveCredentials on

KrbMethodK5Passwd off

KrbMethodNegotiate on

Require valid-user

</Directory>

Make sure that the key file path is correct. The user on whose behalf Apache is started must be able to access this file.

2.8.1.4. Installing client application distribution packages

To update client applications on remote computers using a web server extension, install client application distribution packages on the computer running the web server extension.

To do this, follow these steps:

• From https://releases.1c.ru/, download one of the following files:

  • all-clients-distr-A.B.C.D-i386.run

  • all-clients-distr-A.B.C.D-x86_64.run

  • win-mac-clients-distr-A.B.C.D-i386.run

  • win-mac-clients-distr-A.B.C.D-x86_64.run

Select a package from the list according to the version, bitness, and package manager of the target operating system.

• Install the selected package. The installation requires superuser rights (root). You can perform installation in batch mode. In the startup command line of the RUN file, specify the --mode unattended parameter.

• This will create the distr directory in 1C:Enterprise directory. Depending on the installed packages, this directory will contain client application distribution packages for the following operating systems:

  • Win-mac-clients* file is installed for macOS and Windows.

  • All-clients* file is installed for all operating systems that support client application update over HTTP(s).

See also:

• Automated update of client applications using the distr directory (see Setting up the update using the ).

2.8.2. On Windows

2.8.2.1. Nonvisual access for visually impaired users

1. To install the NVDA screen reader that enables nonvisual access to 1C:Enterprise interface, download the software from https://nvda.ru/ (in Russian) or https://www.nvaccess.org/ and install it on a client computer.
2. For interface voice-over, a variety of speech synthesizers can be used. You can download them at https://github.com/nvaccess/nvda/wiki/ExtraVoices. For the Russian language, using RHVoice speech synthesizer is recommended. You can download it from https://github.com/Olga-Yakovleva/RHVoice/wiki.

2.8.2.2. Installing client application distribution packages

To update client applications on remote computers using a web server extension, install client application distribution packages on the computer running the web server extension.

To do this, follow these steps:

• From https://releases.1c.ru/, download the following file:

  • all-clients-distr-A.B.C.D.exe

  • win-mac-clients-distr-A.B.C.D.exe

If you place this file in the directory with the installation files of the respective application version, distribution packages will be installed with the platform.

• Install the selected package. The installation requires administrator rights.

• This will create the distr directory in 1C:Enterprise directory. Depending on the installed packages, this directory will contain client application distribution packages for the following operating systems:

  • Win-mac-clients*.exe file is installed for macOS and Windows.

  • The all-clients*.exe file is installed for all operating systems that support client application update over HTTP(s).

When you install client distribution packages, the program searches for the installation directory of a specific version (with the same number) and installs them in the directory of the found version. If the computer contains several options of a specific version, distribution packages are installed in the first available directory from the following list:

• Installation directory of the 64-bit 1C:Enterprise server.

• Full 1C:Enterprise distribution package (64-bit version).

• Full 1C:Enterprise distribution package (32-bit version).

You can start the file with distribution packages using the /D=<PathToDirectory> command. In this case, distribution packages are installed in the specified directory. The program does not search for installed versions.

There is also a simpler installation method that is described in the section about installing 1C:Enterprise on a computer running Windows.

See also:

• Automated update of client applications using the distr directory.

• 1C:Enterprise installation for Windows.

2.8.3. Configuring Java

Some components of 1C:Enterprise require Java. These components can require different settings of the Java virtual machine. You can find these settings in this section.

Full-text data search, version 2

The settings depend on the Java version:

• Java version is below 17: no settings are required.

• Java version is 17 or later: add the FtsJavaOpts parameter, which must be set to --add-opens java.base/java.lang=ALL-UNNAMED, to the conf.cfg configuration file.

Licensing utility (ring license)

The settings depend on the Java version:

• If Java version is earlier than 1.8 update 151, install JCE.

• If Java version is 1.8 update 151 or later, two options are possible:

  • Set the crypto.policy parameter in the java.security file to unlimited (add the crypto.policy=unlimited line to this configuration file or remove the comment from this line).

  • Install JCE.

• Java version 9 or later: Set the crypto.policy parameter in the java.security file to unlimited (add the crypto.policy=unlimited line to this configuration file or remove the comment from this line).

Depending on the Java version and the Java version in use, the java.security configuration file is located in different places:

• Java 1.8:

  • JDK. %JAVA_HOME%\jre\lib\security.

  • JRE. %JAVA_HOME%\lib\security.

• Java 9 or later: %JAVA_HOME%\conf\security.

See also:

• FtsJavaOpts parameter of the conf.cfg file.

Chapter 3. Installing configurations

3.1. General information on template directories

Infobases are created from the templates. The templates are installed using a dedicated installer created during distribution package generation in Designer. A template is a collection of distribution files, manifest file and accompanying files used to create the infobase.

To use configurations and infobases as templates, install them on the user computer in a particular way. All templates must be stored in subdirectories of a predefined directory, together with manifest files that describe the installed templates.

The system supports multiple template directories that can be located on local disks or on network drives. This allows you to create a unified list of template directories the users can access to install or update configurations.

By default, the template directory is called tmplts. The template directory location depends on the operating system used:

• Windows: %APPDATA%\1C\1cv8\tmplts.

• Linux: ~/.1cv8/1C/1cv8/tmplts.

• macOS: ~/.1cv8/1C/1cv8/tmplts.

Users can change location of the template directory and specify links to other directories (with arbitrary names). For details on how to specify new template directories, see Startup window settings. In this documentation, you can find out how to work with a default template directory. This information will also be applicable to other template directories.

A template directory is divided into provider subdirectories. Each solution provider chooses a subdirectory based on their company name. For example, solutions of 1C Company are stored in the 1C directory. Names of solution subdirectories within a provider subdirectory are not regulated. However, it is recommended to choose subdirectory names based on the corresponding solution names.

Each solution directory contains subdirectories according to versions of the solution. For example, tmplts\1C\Accounting\1.5.7.5.

It is recommended to maintain the naming arrangement to avoid confusion between providers.

The examples of configuration template installation are provided for Windows-based computers.

3.2. Installing configuration templates

To install a configuration, you need to install its template. Download or otherwise obtain an archive with the installation files. Then, uncompress the archive on the computer where you plan to install the template. Then, run the executable file located in a directory with the uncompressed files:

• Windows: the setup.exe file.

• Linux: the setup file.

• macOS: the setup.app distribution package.

After starting the template installer, the installation wizard will be displayed.

Select a directory to install the configuration template. The default path to the template directory is specified as follows:

• ConfigurationTemplatesLocation parameters in file 1cestart.cfg are searched for the local template directory that the user has a permission to write. If 1cestart.cfg contains more than one parameter with such directories, the first directory will be chosen.

• If no local directories are found, a directory will be created at the default location. This directory will be used as the default template directory. Besides, the record about this directory will be specified as the first ConfigurationTemplatesLocation parameter in 1cestart.cfg.

The user can change the proposed default path and choose another directory. Then, installation of the configuration template into the specified directory is attempted. If successful, the directory is specified as the first ConfigurationTemplatesLocation parameter in 1cestart.cfg. \$\$\$remove it\$\$\$

Then, the installer copies the configuration template file into the specified directory.

To skip some steps of configuration template installation, run setup.exe with /s parameter. In this case, only the startup dialog box and configuration template copying progress bar will be displayed. The configuration template directory from the 1cestart.cfg file will be used. If the file does not contain information on template directory location, the default directory will be created. The path to the created directory will be set as default. Besides, the record about this directory will be specified as the first ConfigurationTemplatesLocation parameter in 1cestart.cfg.

3.3. Creating an infobase from a template

To create a specific infobase using an installed template, run 1C:Enterprise, and then click Add….

Select the previously installed template and click Next > to proceed with the installation. Template tree generation can take a while.

If you choose to create an infobase from the launcher, you can use any template version (that is 1C:Enterprise 8.0, 8.1, 8.2, or 8.3). If it is created using the thick client, you can select only templates of the same version as the file to open.

Then, select the infobase name and parameters. After this, the system will create the infobase.

If you are planning to restore an infobase from a dump file (*.dt) or develop a new configuration, select Create an infobase without a configuration… in the Add infobase or folder window.

Chapter 4. Running system components

4.1. General information

4.1.1. On Linux:

When you install 1C:Enterprise, the following application links are created in the window manager menu:

1C:Enterprise A.B.C.D

1C:Enterprise A.B.C.D – Thin client

1C:Enterprise A.B.C.D – Thick client

In the above list:

4.1.2. On macOS

When you install 1C:Enterprise, the following structure is created in the Programs menu:

1C:Enterprise 8 (folder)

1C:Enterprise

A.B.C.D (folder)

1C:Enterprise

1C:Enterprise – Thin client

1C:Enterprise – Thick client

Remove 1C:Enterprise

In the above list:

In this table:

• Specifying the name of an application without specifying a version means the application or file from the version that was installed latest.

4.1.3. On Windows

When you install 1C:Enterprise, the following structure is created in the Start – Programs menu (see example for Windows 10):

1C:Enterprise

1C:Enterprise 8 (folder)

1C:Enterprise (A.B.C.D)

Thin client (A.B.C.D)

Thick client (A.B.C.D)

Designer (A.B.C.D)

ReadMe – Additional information

Register server administration utility (A.B.C.D)

1C:Enterprise server administration

Start server (A.B.C.D)

Install protection driver

Remove protection driver

In the above list:

In this table:

• Specifying the name of an application without specifying a version means the application or file from the version that was installed latest.

• Specifying (A.B.C.D) next to an application name means that a separate menu item is created for each installed version, where A.B.C.D means the full number of the installed version. For example, if both versions 8.3.12.100 and 8.3.12 150 are installed, two menu items will be created, Thin client (8.3.12.100) and Thin client (8.3.12.150).

• If the 64-bit version of 1C:Enterprise is installed, x86-64 will be included in the folder name and names of items in this folder.

• If 1C:Enterprise server is installed in "For user" mode, it cannot be started as a Windows service.

4.2. Operating modes

1C:Enterprise supports the following operating modes:

4.3. Starting client application or Designer

4.3.1. General information

There are several ways to start 1C:Enterprise:

• Launcher (1cestart). Recommended.

• Interactive launcher (1cv8s).

• Executable file for the thick (1cv8) or thin (1cv8c) client of a specific version.

• Web browser (web client only).

To start 1C:Enterprise, the following configuration files are used:

• 1cestart.cfg. Local configuration file.

• 1cestart.cfg. Local configuration file for all users.

• 1cescmn.cfg. Common configuration file (except for Linux).

Each method is described below in more details.

See also:

• 1cestart.cfg

• 1cescmn.cfg.

4.3.2. Launcher

4.3.2.1. General information

For details on the 1cestart file location, see 1cestart.

Launcher starts all types of client applications (thick client, thin client, web client), as well as Designer.

The launcher can be started without parameters or with a reference to a specific infobase.

If the client computer is Windows-based:

• Launcher can also be located on a network resource (no additional software components required). It can be used both for initial installation of 1C:Enterprise and installation of new versions. If the launcher finds a shared configuration file in its directory, a link to this configuration file is saved as a value of the CommonCfgLocation parameter of the local configuration file.

• When you install 1C:Enterprise from the launcher, you might be prompted to restart the operating system.

4.3.2.2. Starting without parameters

If you start the launcher without parameters, the startup procedure is as follows:

• If the launcher is started from a network disk, the launcher searches for a shared configuration file in the launcher directory. If the file is found, the launcher reads the parameters from the file.

• Launcher searches for the 1cestart.cfg local configuration file. The search is performed in the configuration file location directories used both in the "for computer" and "for user" installation modes. If the file is found, the launcher reads the parameters from the file.

• Launcher searches for installed 1C:Enterprise versions using the data read from InstalledLocation parameters of the configuration files. If this parameter is not specified in configuration files, the launcher closes and an error message is displayed.

• Latest installed 1C:Enterprise version is determined.

• Launcher determines the latest version available for installation in directories read from DistributiveLocation parameters of the configuration files.

• If a later version available for installation is found, the new version is automatically installed with parameters read from InstallComponents parameters of the configuration files. If this parameter is undefined, thin client, thick client, and 1C:Enterprise server access components are installed.

The required installation mode depends on the rights of the current user (see Specifying installation mode).

• Interactive launcher is started from the directory of the 1C:Enterprise version with the max number. The /AppAutoCheckVersion parameter is specified for the startup.

4.3.2.3. Starting with an infobase specified

If you start the launcher with an infobase name specified in the /IBName parameter, the startup procedure is as follows:

• Data is read from local (1cestart.cfg) and shared (1cescmn.cfg) configuration files.

• Common list of infobases is created from the local infobase list (the ibases.v8i file) and CommonInfoBases parameters of the configuration files.

• If the specified infobase name is not found in this list, the launcher closes and an error message is displayed.

• If the infobase name is found, the client is started with startup parameters determined by infobase properties. The following parameters are determined by the infobase properties:

  • Client type

  • Version number required

  • Bitness of the client application in use

  • Other parameters stored in infobase properties

• The /AppAutoCheckVersion parameter is specified for the startup.

4.3.3. Interactive launcher

4.3.3.1. General information

Launcher starts all types of client applications (thick client, thin client, web client), as well as Designer and 1C:Enterprise Development Tools.

You can click 1C:Enterprise to start a client application for the current infobase. You can click Designer to access the infobase in Designer if the infobase access method allows it. If the infobase is published via a web server, you cannot access it in Designer or click the button. You can click 1C:EDT to start 1C:Enterprise Development Tools for the current infobase in the list. You can manage the button availability in the startup window settings (for details, see Startup window settings). If 1C:Enterprise Development Tools is not installed on the current computer, you will be prompted to install this tool. You can start 1C:Enterprise Development Tools only interactively from the interactive launcher form.

The interactive launcher uses some 1C:Enterprise components, so starting a client application that matches version of the interactive launcher is faster than starting an arbitrary client application. You can start the interactive launcher both interactively and using the launcher (see Launcher).

After the first startup, the interactive launcher generates a common list of infobases and writes it to the ibases.v8i file. This list includes infobases for all 1C:Enterprise versions. When transferring lists of infobases for 1C:Enterprise 8.0 and 8.1, user confirmation is required. Further automatic updates of infobase lists are not supported. During the first startup, paths to configuration template directories of previous versions are determined and written to the ConfigurationTemplatesLocation parameter of the 1cestart.cfg file. The 1cestart.cfg file depends on where the interactive launcher was started from.

The interactive launcher can be started without parameters or with a reference to a specific infobase.

4.3.3.2. Starting without parameters

If you start the interactive launcher without parameters, you are prompted to select an infobase (see Maintaining the infobase list).

After the infobase is selected, the interactive launcher follows this procedure:

• If the interactive launcher is started from the launcher or in interactive mode (with or without the /AppAutoCheckVersion+ parameter):

  • 1C:Enterprise version required to start the infobase is determined and the executable files of this version are found (see Specifying run mode).

  • If the required 1C:Enterprise version is not installed and cannot be installed on the computer, the launcher closes and an error message is displayed.

  • Name of client to be started and other startup parameters are determined. The client is started with the specified parameters (including /AppAutoCheckVersion parameter) from the directory of the required 1C:Enterprise version.

  • If the version directory does not contain the required client, the launcher closes and an error message is displayed.

• If the interactive launcher is started from the directory of a specific version with /AppAutoCheckVersion- parameter specified:

  • Executable files of the client must match 1C:Enterprise version whose interactive launcher was started.

  • If the auto client type selection is enabled for the infobase, the thin client is started and the /AppAutoCheckMode parameter is passed to it (see Specifying run mode).

4.3.3.3. Starting with parameters

Starting the interactive launcher with an infobase specified (using the /IBName parameter) is identical to starting the regular launcher.

4.3.4. Infobase connection methods

There are several ways to deploy an infobase and to connect to it. To specify a method for a specific infobase, go to the infobase adding dialog box (see Adding infobases):

• Infobase is located on a local computer or a computer in a local network.

It is used by the thin and thick client in file mode.

When the thin client runs in file mode on the computer where the thin client was started, a specialized environment is set. In this specialized environment:

• Server components required for the system operation are loaded.

• Application configuration is loaded.

• Other actions needed for normal infobase operation are performed.

Interaction between the thin client and the specialized environment is organized over the same protocols that are used when working in client/server mode or via the web server. Thus, the specialized environment operates as a server for the thin client. The environment is not a separate OS process; instead, it runs as a part of the thin client process.

• The infobase is located on the 1C:Enterprise server.

It is used by the thin and thick clients in client/server mode.

• The infobase is located on a web server.

It is used by the thin client and web client in file mode and client/server mode.

To connect to the infobase via the web server, install and configure the web server properly.

When connecting to the infobase via the web server, specify the URL as an infobase connection string. For example, http://MyServer/DemoBase.

4.3.5. Selecting an infobase

The next step of 1C:Enterprise startup is infobase selection. For this, use the 1C:Enterprise launch window.

The Infobases list contains the list of infobases. Each item in this list points to a directory where 1C:Enterprise infobase files are stored (for file mode) or to a server and server infobase (for client/server mode).

Select any infobase from this list. To select the infobase, double-click its name.

To manage the 1C:Enterprise infobase list, use the Change, Add, and Remove buttons. You can also use shortcuts: F2, Ins, and Del. For the details on the purpose of these buttons, see: Maintaining the infobase list.

The window is resizable. Size and location of the window are memorized after the session ends.

When all 1C:Enterprise startup parameters are specified, click 1C:Enterprise to run 1C:Enterprise, or Designer to run Designer. Click Exit to cancel the 1C:Enterprise startup.

The Go to link command is used to run the client application when the external URL of the application object is available. After clicking this hyperlink, a dialog box opens where you can type in the URL and click Go to. For more information on the actions performed when running the client application using an external URL, see Auxiliary parameters.

As an alternative to selecting an infobase from the list (see Maintaining the infobase list), you can run 1C:Enterprise using the .v8i file and specifying the infobase parameters in the startup command line of the client application (see Startup command-line options of 1C:Enterprise). In this mode, you can use infobases that are not included in the infobase list. When accessing an infobase not included in the local infobase list, remember that the configuration data will not be cached for this infobase. As a result, many operations will be considerably slower. To avoid this slowdown, add the infobase to the infobase list.

4.3.6. Selecting and using the client application

4.3.6.1. General information

In this section, you will learn how to choose a client application to run (and its bitness), as well as the system behavior when client application versions mismatch in client/server and file infobase modes. The section describes commands of the command line for client application startup. For details on these commands, see General startup commands.

4.3.6.2. Client for a specific 1C:Enterprise version

A specific client (thin or thick) can be started in two ways:

• By selecting the respective menu item (depends on the client operating system used). The client application type will be determined based on the words "thin client" or "thick client" in the menu item name.

• By running the executable file of the required client (depends on the client operating system used).

  • To start a thin client of a particular version, start the 1cv8c file.

  • To start a thick client of a particular version, start the 1cv8 file.

• When starting a file infobase, installation of the latest version of a client application is attempted first (using DistributiveLocation parameter of the configuration files), and then the infobase is opened using the latest version installed on the computer. To disable installation of new versions, use /AppAutoCheckVersion- command-line option of the client application startup. To enable or disable installation of a new version, use the Automatically install a new version checkbox in the dialog box of startup window settings (see Startup window settings) or the /AppAutoInstallLastVersion command-line option of the client application startup (see General startup commands).

If the client is started without the /AppAutoCheckMode parameter, it is attempted to start the infobase using the selected client of a specific version without picking the client application type.

4.3.6.3. Determining application bitness and using applications of different bitness

You can select client application bitness only if the computer runs 64-bit Windows. If your computer runs Linux, use the application whose bitness matches the operating system bitness. If the computer runs macOS, only 64-bit version of the applications is available.

Several versions of the client application with different bitness can be installed on the client computer. In some situations, you might need to specify not only the version of the client application but also its bitness for a specific infobase. You can specify client bitness for each infobase if necessary.

To specify bitness of a client application, you can use (in descending priority order):

1. /AppArch startup command line parameter

2. Infobase property

3. Interactive launcher property

All these options allow you to specify one of 4 client bitness options:

1. 32 (x86). Gives priority to the 32-bit version of a client application. 64-bit versions of the client application will be ignored, even if there are newer versions among them.

2. 64 (x86-64). Gives priority to the 64-bit version of a client application. 32-bit versions of the client application will be ignored, even if there are newer versions among them.

3. 32 (x86) priority. Gives priority to the 32-bit version of a client application. However, if a 64-bit version has a later release date, it will be used instead.

4. 64 (x64) priority. Gives priority to the 64-bit version of a client application. However, if a 32-bit version has a later release date, it will be used instead.

5. Automatically. Bitness of a client application is not explicitly specified. In this case, 32 (x86) priority will be used.

Consider that the system performance does not depend on the bitness (operating system and processor) of client applications or a server cluster (for client/server mode). It means that the infobase can be simultaneously operated by client applications with different bitness, on different processors, and in different operating systems. In client/server mode, cluster server bitness can differ from client application bitness, operating system, and processor. Application bitness and the operating system it is intended for are important when:

• COM connection is used (only for Windows).

• Add-ins are used. An add-in must include an add-in file whose characteristics match the application where you plan to use the add-in. An add-ins contains a manifest that describes which startup options the add-in developer built this add-in for. For details on the add-in manifest, see 1C:ITS portal (https://its.1c.ru/db/metod8dev#content:3221:hdoc). For all environments that support add-ins.

See also:

• Startup window settings (see Startup window settings).

• Command-line options (see General startup commands).

• 1cestart.cfg.

• 1cescmn.cfg.

• *.v8i

4.3.6.4. Client/server version mismatch

When in client/server mode, the client application version might differ from the server version. In this case, 1C:Enterprise cannot run. The client and server versions must match exactly.

In case of client and server version mismatch, the client application (thin or thick client) searches for and installs the version that matches the server version. The search for distribution packages of the client application is performed in the following order:

• 1C:Enterprise installation directory (specified in InstalledLocation property of 1cestart.cfg and 1cescmn.cfg files).

• Directories specified as locations of distribution packages of new versions (DistributiveLocation property of 1cestart.cfg and 1cescmn.cfg files, as well as CommonCfgLocation property of 1cestart.cfg file).

• URL that is returned in the server version mismatch exception (the PublishDistributiveLocation parameter of the conf.cfg file and the pubdst attribute of the ws element in the default.vrd file).

• Internet services used to obtain client application distribution packages.

Please keep in mind that:

• Thin client is used to search for and get the distribution package using the Internet services only if you connect to the infobase via HTTP.

• Thin client is used to get the distribution package from the URL specified in the client and server version mismatch exception in any client/server connection.

• If the infobase list (*.v8i file) includes a version that is not available for installation, the latest version available on the computer is used to open the infobase. In this case, the path to distribution package of the required client version can be received from the 1C:Enterprise server.

4.3.6.5. FIle mode version mismatch

When in file mode, all client applications working with an infobase at the same time must have the same version. The required version is determined by the version of the client application that established first connection to 1Cv8.1CD file of the infobase. First connection is a connection that was established when no other client applications were connected to the infobase.

4.3.7. Web client

4.3.7.1. General information

To run the web client, start the browser and type in an infobase URL. Make sure the browser is set up properly. For setting details, see Configuring web browsers to operate in the web client. You can open one infobase (the same URL) on different tabs of a web browser.

4.3.7.2. Language and regional settings

You can select the language of web client interface using one of the following methods (in ascending priority):

• Preferred language settings in your web browser

• Command-line parameter L

When you choose an interface language:

• Locale language is chosen while processing the query to a resource that corresponds to the infobase (for example, http://localhost/demo):

  • If URL contains the L parameter, the value of this parameter is read. For example: http://localhost/demo?l=en to specify English for the localization. If the language is not chosen after reading the parameter, the Accept-Language header is read.

  • If the URL does not have any parameters, the Accept-Language standard HTTP header that contains information on the preferred languages set in the browser is read.

• Language is chosen based on the locales available on the server:

  • If an exact match is not found (for example, the option specifies en_US language, which is not available), the language name is truncated and a new search is performed (the search for en).

• If no matching language is found, the default English (en) language is used.

  • The selected language is added to the base application URL (in the example, the result is http://localhost/demo/en), and the web browser is automatically redirected to this new URL.

Regional settings of a web client session affecting how certain values are displayed (for example, Day and Date) can be specified using the following methods (in ascending priority):

• Preferred language settings in your web browser

• Command-line parameter VL

The regional settings of a session are configured in the following way:

• If the URL contains VL parameter, the regional settings matching the locale code in this parameter are used. For example: http://localhost/demo?vl=en to specify regional session settings for the English language. If the parameter contains an invalid locale code, the web client closes and an error message is displayed.

• If the URL does not have any parameters, the Accept-Language standard HTTP header that contains information on the preferred languages set in the browser is read.

4.3.7.3. Authentication with a POST request

In some situations, you may need to run 1C:Enterprise without the standard user authentication window. This option might be necessary if you need to make authentication in 1C:Enterprise using a dedicated form (for example, integrated into a website) or if infobase user credentials are stored in a separate database.

To meet these requirements, you can authenticate a web client session using POST request to infobase resource: e1cib/start. In this case, the startup process follows this procedure:

1. POST request is made to authenticate the client.

2. If the authentication is successful, the session is created on behalf of the user specified in the POST request.

3. Web client is started and the following parameters from the POST request are passed to the web client command line: LowClientConnectionSpeed, LaunchParameter, LocaleCode, and Zone.

4. Web client connects to the session authenticated in step 2.

The request contains the following parameters:

Usrrequired

Username.

Pwdnot required

User password.

The default value is empty string.

LowClientConnectionSpeedoptional

Connection speed.

Values:

• on. Low connection speed.

• off. Normal connection speed (default).

LaunchParameteroptional

Parameters to be passed to the application. It is similar to the C parameter of the web client command line.

The default value is empty string.

SystemLanguageoptional

Interface language. If not set, to set the interface language and regional settings, see Language and regional settings.

LocaleCodeoptional

Interface language. If not set, to set the interface language and regional settings, see Language and regional settings.

Zoneoptional

Separator values.

AuthFailHandlingoptional

Determines the system behavior in case of authentication error. Values:

• error. Returns error code 402 and an error message.

• start. Runs web client with the 1C:Enterprise authentication request.

• redirect. Redirects to URL passed in the AuthFailRedirectURL parameter.

The default value is error.

AuthFailRedirectURLoptional

Contains the URL to follow in case of authentication error, if the AuthFailHandling parameter is set to redirect. This URL must be absolute.

Example:

This HTML page illustrates a native authentication form of an infobase located at http://localhost/demoapp.

<HTML xmlns="http://www.w3.org/1999/xhtml"><HEAD>

<META http-equiv="Content-Type" content="text/html; charset=utf-8" />

<BODY>

<FORM action="http://localhost/demoapp/e1cib/start" method="post">

User: <INPUT id="usr" name="usr" /><BR />

Password: <INPUT id="pwd" type="password" value="" name="pwd" />

<BR />Low speed: <INPUT id="lowclientconnectionspeed" type="checkbox" name="lowclientconnectionspeed" /><BR />

Startup parameter: <INPUT id="launchparameter" name="launchparameter" /><BR />

Interface language: <SELECT id="systemlanguage" name="systemlanguage">

<OPTION value="ru" selected="">Russian</OPTION>

<OPTION value="en">English</OPTION>

</SELECT><BR />

Session localization code: <SELECT id="localecode" name="localecode">

<OPTION value="ru" selected="">Russian</OPTION>

<OPTION value="en">English</OPTION>

</SELECT><BR />

Data area: <INPUT id="zone" name="zone" />

<INPUT id="authfailhandling" type="hidden" value="error" name="authfailhandling" />

<P><INPUT type="submit" value="ОК" /> </P>

</FORM>

</BODY>

</HTML>

As a result, the following authentication form will be displayed:

4.3.8. Infobase users

4.3.8.1. User authentication

If a list of users allowed to access the infobase (to create or edit this list, use Designer) is available, the user authentication dialog box will be opened. At the top of the dialog box, under the 1C logo, there is a name of the infobase that the user is trying to access. This name is displayed if the authentication dialog box opens from the launcher, to whose infobase list the current database is added. If you access the infobase using a web client or by specifying access parameters in the command line of the client application startup, "1C:Enterprise" is displayed under the 1C logo.

There are several ways to specify a username in this dialog box:

• Click the User field and choose a name from a list. You can use this method if there are users that can be displayed in the choice list in the settings.

• Type the username in the User field if the list is very long or the Show in list option is not enabled in the user settings (see Adding new users).

Once at least one username is specified in the authentication dialog box, after successful authentication, this name will be added to the list of recent users. This list contains up to 4 usernames.

If a password is set for the user, enter the password in the Password field. Then, click Sign in to complete the user authentication and proceed. To close the authentication window (and refuse to connect to the infobase), click the X button in the upper-right corner of the dialog box.

The button on the right side of the password field allows you to see the password in clear text.

Click the button to see the password in clear text not covered by *. In this case, the button changes its image, as is evident from the figure below.

If you click the button in the password input field several times, you can switch between the password view modes: hidden – displayed. When you open the user authentication dialog box, the password is entered in mask mode.

If you select the Remember checkbox in the authentication dialog box, the next time you authenticate to the specified infobase on this computer, the user authentication attempt will not be performed. Instead, the user whose name that was specified in the dialog box before the checkbox was selected will be signed in (in the example on the figure, this will be Administrator (JohnSmith)).

If self-service password recovery is enabled in the infobase, the Forgot your password? hyperlink will be displayed in the dialog box.

Clicking the hyperlink will run the user's password recovery. For more information on how to set up and use this feature, see Password recovery.

If several authentication types are configured for the infobase, the authentication dialog box displays all the configured authentication types.

The authentication types are displayed at the bottom of the dialog box (Sing in via...). QR code authentication is displayed separately. If this feature is enabled, the Sign in using QR code hyperlink is displayed under the Sign in button. The authentication dialog box displays the following authentication types: standard authentication, email authentication, QR code authentication, OpenID authentication, and OpenID Connect authentication. You can set up and use several OpenID Connect authentication providers (they all will be displayed). Active authentication (whose parameters are displayed at the top of the dialog box) is highlighted with an underscore under the authentication picture.

For the authentication dialog box to display the authentication types available to the user, the following conditions must be met:

• Configure an authentication type for this infobase.

• Enable the authentication type selection for this infobase.

To configure all the above settings, use the default.vrd configuration publication setup file. To set up the OpenID and OpenID Connect authentication, use the <openid> and <openidconnect> elements. To specify the location of mobile applications that can be used to sign in by QR code, use the <mobileApps> element. To display a particular authentication type, as well as to specify the order of the configured authentication types in the authentication dialog box, use the <authentication> element. Note that hiding the authentication type in the <authentication> element has a higher priority than the settings in other sections of the default.vrd file. If OpenID authentication is configured in the default.vrd file (and the provider is available to the client application) but disabled in the <authentication> element, you cannot select the OpenID authentication in the authentication dialog box of this infobase. Note that enabling the display of any authentication type (the <authentication> element) will not automatically configure this authentication type.

If a picture is specified in the OpenID Connect authentication settings for the provider (the image field of the provider description), the provider will be displayed with this picture in the authentication dialog box. The value of the title field of the provider description will be displayed for the OpenID Connect provider as a tooltip.

If an access error occurs (no free license, prohibition from the external session management service, or exclusive infobase/area access error) during authentication when starting the client application (thin client, web client, mobile client, thick client, or Designer), the following happens:

1. If an authenticated user has no other sessions in the current infobase/area, an error notification appears. Client application does not start.

2. If an authenticated user has other sessions in the infobase/area after the respective client applications started on the same computer were closed, the sessions end automatically and another authentication attempt is made.

3. If there are sessions in the infobase/area, but the client applications are still running, or they were started on another computer, a dialog box with a list of sessions appears, and the system prompts you to close all or some of the sessions. If you agree, the system attempts to close the selected sessions and authenticate again.

See also:

• default.vrd file details.

4.3.8.2. Authentication when accessing infobase data

4.3.8.2.1. General information

Before getting access to infobase data, the client application must specify who will access data and check whether this user is authenticated. You can use the 1C:Enterprise client application or any other software that can get access to data via external application interfaces as a client application. You can get access to data using the file infobase or the 1C:Enterprise server (over TCP/IP) or using the web server (over HTTP(s)). Client application can be authenticated as follows:

1. With a username and password (authentication using 1C:Enterprise tools, standard authentication). With this authentication method, you can use two-factor authentication if it is set up on the 1C:Enterprise side. For more information about two-factor authentication, see Two-factor authentication. For more information about authentication using 1C:Enterprise tools, see 1C:Enterprise authentication.

2. With operating system authentication. For more information, see Operating system.

3. With OpenID and OpenID Connect protocols. OpenID providers can use various kinds of two-factor authentication. It depends on the provider settings.

4. With a special access token.

5. QR code authentication. For more information, see Using QR code.

6. Email authentication. For more information, see By email.

Depending on how you access 1C:Enterprise data, you can use different authentication kinds.

In terms of authentication kinds and participating system components, the easiest way to access data is to directly access the file infobase or the 1C:Enterprise server cluster. In this case, access only the infobase without secondary servers.

During the direct connection, you can use the following authentication kinds:

• OS authentication.

• Authentication using 1C:Enterprise tools.

• Email authentication (for interactive authentication only).

If you connect over HTTP(s), the following is used during the connection:

• Proxy server. This is a server that acts as an intermediary between the client application and the target server. Let us assume that the proxy server is in computer networks of the client application.

• Web server. This is a server that grants access to the infobase or the 1C:Enterprise server cluster over HTTP(s). Let us assume that the web server is located in the same computer network as the server cluster or infobase.

You can transfer data between the proxy server and the web server via the Intranet and Internet. The proxy server is optional for getting access.

It is also worth mentioning that HTTPS or secure connection is supported. This protocol is not directly related to authentication but, with secure connection, you can be sure that the client and the server are truly the subjects they pretend to be. In this section, you can find a brief description of secure connection. The secure connection is established between the client application and the web server where the 1C:Enterprise infobase is published and only if HTTPS is supported by the web server for the required infobase. To specify that the client application must use secure connection, do the following:

• When you use the web client, all actions are performed by the browser. Install root certificates to the computer. With the certificates, you can check the web server certificate.

• When you use the thin client, use the launcher to set up certificates. During the setup, you can specify how to check the web server certificate and which certificate will be used by the client application.

• When you operate from 1C:Enterprise language, establish secure connection using the OpenSSLSecureConnection object. The parameters of this object are similar to the launcher settings.

So, the following items are involved in the authentication process: a client application located on a client device, a proxy server, a web server, and the 1C:Enterprise server cluster or the web server extension for the file infobase.

The figure shows the main authentication options. You can combine these options. For example, you can connect your device to the web server that operates with the file infobase. The client application initiates authentication process and ensures that all participants get data required to complete each step of the process. The following authentication options are numbered:

1. Authentication on the proxy server.

   • For authentication, you can use:

     • Authentication using 1C:Enterprise tools.

     • OS authentication.

   • Specify the parameters for authentication on the proxy server:

     • In the settings to access the infobase in the launcher.

     • Using the /Proxy command-line option for the client application startup.

     • Using the InternetProxy object if you access data programmatically.

     • Using the inetcfg.xml configuration file.

2. Authentication on the web server.

   • For authentication, you can use:

     • Authentication using 1C:Enterprise tools.

     • OS authentication.

   • Specify the parameters for authentication on the web server:

     • Using the /WSA, /WSN, and /WSP command-line options for the client application startup.

     • Using the InternetProxy object if you access data programmatically.

   • You can also use secure connection (HTTPS).

3. Authentication in the infobase.

   • For authentication, you can use:

     • Access token.

     • OS authentication.

     • Authentication using various OpenID protocol options.

     • QR code.

     • Username and password.

     • Email authentication (interactive login only).

   • Specify authentication parameters for the infobase as follows:

     • Access token:

       • Using the /AccessToken command-line option for the client application startup.

       • Using the AccessToken parameter of the infobase connection string.

       • Using the Authorization: Bearer header of the HTTP infobase request.

     • OS authentication:

       • Using the /WA command-line option for the client application startup. You can enable or disable this authentication method.

       • Using the UseOSAuthentication parameter of the HTTPConnection or WSDefinitions object constructor.

     • Authentication using OpenID:

       • Using the /OIDA command-line option for the client application startup. You can enable or disable this authentication method. Authentication parameters are determined by the publication settings of the infobase you want to access.

       • Using the Authorization: Bearer header of the HTTP infobase request.

     • Using the username and password:

       • Using the /N and /P command-line options for the client application startup.

       • Using the parameters of the infobase connection string.

       • Using the Authorization: Basic header of the HTTP infobase request.

     • Email authentication:

       • Using the /EmailAuth command-line option for the client application startup.

See also:

• Startup command-line options (see Authentication settings).

• Authentication kinds in 1C:Enterprise (see Authentication types).

• Integration methods in 1C:Enterprise.

4.3.8.2.2. Interactive authentication

4.3.8.2.2.1. Authentication on the web server

When you access the infobase manually, authentication on the web server is performed as follows:

• Thin client:

  • If the /WSA- parameter is specified, a web server requests a username and password for authentication.

  • If the correct /WSN and /WSP parameters are set, a specified user is authenticated on the web server.

  • If the /WSN parameter is not specified, OS authentication is performed. If authentication fails, a username and password are requested.

  • If the /WSN parameter is specified and the /WSP parameter is not set or is set incorrectly, a web server requests a username and password for authentication.

• Web client:

  • The browser manages this process.

See also:

• Startup command-line options (see Authentication settings).

• Authentication kinds in 1C:Enterprise (see Authentication types).

4.3.8.2.2.2. Authentication in the infobase

If you connect to the server/infobase (thin and thick clients) directly or if you connect to the infobase via the web server (thin client or web client), authentication in the infobase is as follows:

During the interactive authentication, the following takes place:

1. If possible, authentication using the saved authentication token is performed.
2. If possible, JWT authentication is performed.

If authentication fails, other authentication methods cannot be used.

26. If possible, OS authentication is performed.

If authentication fails or the /WA- command is specified, further attempts to use other authentication methods are made.

27. Authentication with a username and password is performed (if one or both authentication parameters are specified in the command line):

    • If the /N and /P parameters are set, a specified user is authenticated.

    • If the /N parameter is not set, a username and password are requested.

    • If the /P parameter is not set or is set incorrectly, an authentication attempt is made (an empty password is used for authentication). If authentication fails, a username and password are requested (authentication window).

    • If the authentication attempt fails and the /N parameter is specified, in the authentication window that opens, the /N parameter value will be specified in the username field.

28. The user selects the required authentication method in the dialog box and attempts to authenticate using this method. To set up the authentication dialog box, use the default.vrd publication description file (the <authentication> element). If any authentication type is disabled in the default.vrd file, you will not be able to select this authentication type in the dialog box, even if other settings are correct. If the /OIDA- option is specified in the command line, the OpenID authentication will not be available for selection.

See also:

• Startup command-line options (see Authentication settings).

• Authentication kinds in 1C:Enterprise (see Authentication types).

4.3.8.2.3. Authentication when accessing the infobase programmatically

4.3.8.2.3.1. Authentication on the web server

When you access the infobase programmatically, set up authentication on the web server using the HTTPConnection or WSDefinitions object depending on the service kind you use:

• Authentication on the web server is determined by the UserName, Password, and UseOSAuthentication parameters of the HTTPConnection and WSDefinitions object constructors:

  • The UseOSAuthentication parameter is set to True:

    • OS authentication is enabled in the web server settings:

      • OS is authenticated.

      • If the UserName and Password parameters are specified, their values are used for authentication over NTLM and Kerberos protocols. Specify the UserName as DOMAIN\user or user@domain.

      • If the UserName and Password parameters are not specified, the parameters of a user on whose behalf the current session is running will be used.

    • OS authentication is disabled in the web server settings:

      • Authentication on the web server is not performed.

      • To access the infobase, UserName and Password will be used.

  • The UseOSAuthentication parameter is set to False:

    • If UserName and Password are specified, use the username and password for authentication.

    • Do not specify the infobase username and password that are specified in the infobase URL. In some cases, it can lead to errors that are hard to find.

See also:

• Authentication kinds in 1C:Enterprise (see Authentication types).

• Integration methods in 1C:Enterprise.

4.3.8.2.3.2. Authentication in the infobase

Once you authenticate on the web server, the web server extension tries to authenticate in the infobase:

• If the Authorization: Bearer HTTP request header is specified, an attempt to authenticate using an access token is made. If the attempt fails, you will not be able to access the infobase.

• If the Authorization: Basic HTTP request header is specified, an attempt to authenticate using a username and password is made.

• If standard headers are not used, the web server extension tries to get a username and password from the infobase connection string from the default.vrd file. If parameters are determined, internal request headers are used to transfer the parameters.

• If a username and password are not determined, an attempt to use OS authentication is made. If OS authentication fails, you will not be able to access the infobase.

See also:

• Authentication kinds in 1C:Enterprise (see Authentication types).

• Integration methods in 1C:Enterprise.

4.3.9. Using certificates

4.3.9.1. General information

When sending information over public communication channels (Internet), protecting this information from interception and spoofing is particularly important. This chapter examines the issue of establishing secure connections in a 1C:Enterprise-based system.

Let us review the general procedure of establishing a secure connection. It is based upon Public Key Infrastructure (PKI) that associates public keys with respective user identities using a certification authority.

A simple example illustrates how PKI operates. Let us assume that any person can contact a certificate issuer to check validity of any certificate issued by it.

Let us further assume that a Policeman meets a Stranger and wants to verify that the person they just met is indeed the Stranger. To do this, the Policeman asks the Stranger to show their ID. Before showing the ID, the Stranger wants to make sure that the person in front of them is indeed the Policeman. They ask the Policeman for their badge, call the Police HQ, and ask them to check the badge number to verify that the person in front of them is the Policeman. After the authentication, the Stranger shows their ID to the Policeman. The ID has a unique number. It also says it is issued by the Ministry of Documents. The Policeman contacts the Ministry of Documents and asks them to check the ID number to verify that the person in front of them is the Stranger.

However, if the Stranger travels to another country, the above authentication algorithm will not work, because the Policeman in another country knows nothing about the Ministry of Documents. Therefore, the Stranger will be detained until another method to determine their identity is found.

Now, let us translate this into terms of PKI objects and network infrastructure. 1C:Enterprise client application acts as a Stranger. Web server used by the client application to access the infobase acts as a Policeman. Ministry of Documents and Police HQ are Certification authorities. Certificates used to establish the HTTPS connection serve as Stranger's ID and Policeman's badge.

Let us go through the procedure once again, now in the correct terms. When a client application attempts to connect to the web server, the client application verifies the server certificate. The verification is performed via certification authority specified in the web server certificate if the certification authority is in the list of root certification authorities on the computer with the client application. If verification is successful, the client application provides its client certificate to web server for verification. The server verifies the certificate using its list of root certification authorities. If the verification is successful, the client application and the web server establish a secure HTTPS connection. The client application then encrypts data sent to the server and decrypts data received from the server using the server's public key, while the server encrypts and decrypts data using its private key. The client application and the web server use different private keys unknown to the other party.

This is a general description of establishing a secure connection. The next section contains a more detailed description.

4.3.9.2. Methods for establishing a secure connection

A secure connection can be established between the thin client or web client and the web server used to access the infobase. Depending on certificate availability at client or server, several methods can be used to establish a secure connection. These methods are described below. Please keep in mind that all HTTPS connections are encrypted.

Terms used in the table:

• Certificate. Indicates that a certificate is available (Certificate+) or unavailable (Certificate-):

  • Server certificate for a server.

  • Client certificate for a client.

• Root. Indicates that a certificate authority (CA) list to verify the presented certificate is available (Root+) or unavailable (Root-). CA list must allow verification of certificates presented by the client application or web server.

When using a web client, availability of a certificate or a root certificate list is determined by certificates installed in the certificate storage used by the web browser.

For the thin client, you can specify the certificate (and lists of root certificates) using the startup command-line parameters or infobase startup parameters (see Infobase startup parameters).

4.3.9.3. Certificate sources and formats

The following storages can be used as sources of certificates:

• System certificate store for macOS and Windows.

• Certificate storage on Linux is located in the /etc/ssl/certs directory. All certificates located in this directory are considered as trusted.

Some Linux distribution packages also support the following directories for root certificate storages:

• Debian, Mint, Ubuntu: the /etc/ssl/certs/ca-certificates.crt directory.

• CentOS, Fedora, RedHat: the /etc/ssl/certs/ca-bundle.trusted.crt or /etc/pki/tls/certs/ca-bundle.crt directory.

• Alt Linux: the /etc/share/ca-certificates/ca-bundle.crt directory.

• File certificates for Linux, macOS, and Windows.

Available file certificate formats:

• PEM (base-64 encoded X.509). Encrypted keys and certificates under the X.509 standard in text format. Certificate and key data is encoded using base 64 encoding. Private certificate keys are protected with passwords. This certificate file format is used by default by Apache web server, among others. If the private key of the client certificate is stored in a separate file, the content of this file must be added to the client certificate file.

• P12/PFX (PKCS#12). Encrypted keys and certificates under the PKCS#12 standard. The file can be protected with a password. This is the primary format for exporting and importing the system certificate storages in Windows. It is used, for example, by Microsoft Internet Information Services web server. The client certificate file must contain its private key.

File extension determines format of the file:

• .p12, .pfx: P12 file format.

• *.pem: PEM file format.

• The default file format is PEM.

4.3.9.4. Self-signed certificates

4.3.9.4.1. General information

When you use the TLS protocol for connection, make sure that the client and server have a corresponding certificate. The server must have a certificate that is used for server authentication. The client must have a certificate that is used for client authentication. The certificates must be verified by trusted certificate authorities. If you establish secure connection for infobases, the certificates you use must be issued by trusted certificate authorities. The certificates must comply with various regulations of national legislation or national regulatory authorities.

To test or deploy any infrastructure in the enterprise Intranet, you might not need to use certificates issued by trusted certificate authorities for various reasons (cost, issuing certificates can take too long, and other). In this case, you can use self-signed certificates. Self-signed certificates are similar to certificates issued by trusted certificate authorities. Advantages of self-signed certificates:

• You can create as many certificates as you want.

• You do not need to pay for creating certificates.

Disadvantages of self-signed certificates:

• Your certificate authority is not supported in the third-party software.

• Third parties do not trust your certificate.

• You cannot revoke certificates.

• There is a high risk to lose data that is transferred via the connection secured by self-signed certificates.

Despite all the disadvantages, it is better to use self-signed certificates for testing and internal enterprise systems if the risks above can be ignored when using self-signed certificates.

4.3.9.4.2. Creating certificates

4.3.9.4.2.1. General information

In this section, you can find out how to create the following set of certificates:

• Certificate of the root certificate authority.

• Server certificate.

• Client certificate.

Below, you can see the examples of how to create certificates using the OpenSSL and Java packages. The result will be the same. Two different packages were used to make the examples clearer. In the example, the certificate will be created for the server.com domain. When you create certificates, specify the following parameters:

• For root certificates

  • Country Name: RU

  • State or Province Name: Moscow

  • Locality Name: Moscow

  • Organization Name: Company

  • Organizational Unit Name: Department

  • Common Name: Root CA

  • Email Address: admin@company.site

• For server certificates:

  • Country Name: RU

  • State or Province Name: Moscow

  • Locality Name: Moscow

  • Organization Name: Company

  • Organizational Unit Name: Department

  • Common Name: server.com

  • Email Address: admin@company.site

Specify these parameters in the console when you create a certificate.

The examples given in this section demonstrate how to create certificates. They are not complete and exhaustive. For more information on how to create certificates, read the documentation for the respective software.

4.3.9.4.2.2. Creating a certificate of the root certificate authority

In this section, we will show how to create a certificate that will be used to authorize the server certificate.

Using OpenSSL:

openssl req -x509 -days 3652 -newkey rsa:2048 -keyout root-ca.key -out root-ca.crt

Using Java:

keytool -genkey -alias root-ca -keyalg RSA -keystore root-ca.jks -keysize 2048 -startdate 2023/01/01 -validity 3652

In the examples:

• Certificate is valid for 10 years.

• Certificate validity period will start:

  • For OpenSSL: when the certificate is generated.

  • For Java: from the date specified in the -startdate parameter.

• When you create a certificate, enter the certificate parameters in the console.

Both utilities will request a password that encrypts the private key of the root certificate authority.

To get a certificate file from JKS (when using Java), use the following command:

Using Java:

keytool -exportcert -rfc -keystore root-ca.jks -alias root-ca -file root-ca.crt

As a result, the following will be created:

• For OpenSSL:

  • The root-ca.key file. Private key of the root certificate.

  • The root-ca.crt file. Root certificate.

• For Java:

  • The root-ca.jks file. File of the Java certificate store (Java KeyStore).

  • The root-ca.crt file. Root certificate.

4.3.9.4.2.3. Creating server certificates

When you use the root certificate, create a certificate of our server. The steps are different for OpenSSL and Java.

First, let us take a look at how to use OpenSSL.

Create the server.ext file that will be located in the directory with the certificates. The file must contain the following information:

authorityKeyIdentifier=keyid,issuer

basicConstraints=CA:FALSE

subjectAltName = @alt_names

[alt_names]

DNS.1 = server.com

Then:

openssl req -newkey rsa:2048 -keyout server.key -out server.csr

openssl x509 -req -CAkey root-ca.key -CA root-ca.crt -in server.csr -out server.crt -CAcreateserial -days 365 -extfile server.ext

In this example:

• The first command creates a private key of the server certificate (server.key) and the certificate request file. When the private key is being generated, enter the key parameters in the command line.

• The second command creates a certificate for the server that will be authorized by the root certificate created in the previous step.

• The validity period of the certificate is 365 days. The period starts from the creation date.

Using Java:

keytool -genkey -alias server.com -keyalg RSA -keystore server.jks -keysize 2048

keytool -certreq -keystore server.jks -alias server.com -ext san=dns:server.com -file server.csr

keytool -gencert -rfc -infile server.csr -outfile server.crt -keystore root-ca.jks -alias root-ca -ext honored=all -startdate 2023/01/01 -validity 365

In this example:

• The first command creates a private key of the server certificate and locates it in the server.jks storage. When the private key is being generated, enter the key parameters in the command line.

• The second command creates a certificate request for the server.com server.

• The third command creates a certificate for the server that will be authorized by the root certificate created in the previous step.

• The validity period of the certificate is 365 days. The period starts from the date specified in the -startdate parameter.

To get the private key of the server (the OpenSSL package is required):

keytool -importkeystore -srckeystore server.jks -destkeystore server.p12 -deststoretype PKCS12

openssl pkcs12 -in server.p12 -nocerts -nodes -out server.key

As a result, the private key of the server (server.key) and the test server certificate (server.crt) will be generated.

4.3.9.4.2.4. Creating client certificates

The creation of client certificates is similar to the creation of server certificates. The steps are different for OpenSSL and Java.

First, let us take a look at how to use OpenSSL.

Create the client.ext file that will be located in the directory with the certificates. The file must contain the following information:

authorityKeyIdentifier=keyid,issuer

basicConstraints=CA:FALSE

Then:

Using OpenSSL:

openssl req -newkey rsa:2048 -keyout client.key -out client.csr

openssl x509 -req -CAkey root-ca.key -CA root-ca.crt -in client.csr -out client.crt -CAcreateserial -days 365 -extfile client.ext

In this example:

• The first command creates a private key of the client certificate (client.key) and the certificate request file. When the private key is being generated, enter the key parameters in the command line.

• The second command creates a certificate for the client that will be authorized by the root certificate (to find out how to create a certificate, see Creating a certificate of the root certificate authority).

• The validity period of the certificate is 365 days. The period starts from the creation date.

Using Java:

keytool -genkey -alias client -keyalg RSA -keystore client.jks -keysize 2048

keytool -certreq -keystore client.jks -alias client -file client.csr

keytool -gencert -rfc -infile client.csr -outfile client.crt -keystore root-ca.jks -alias root-ca -ext honored=all -startdate 2023/01/01 -validity 365

In this example:

• The first command creates a private key of the client certificate and locates it in the client.jks storage. When the private key is being generated, enter the key parameters in the command line.

• The second command creates a certificate request for the client.

• The third command creates a certificate for the client that will be authorized by the root certificate (to find out how to create a certificate, see Creating a certificate of the root certificate authority).

• The validity period of the certificate is 365 days. The period starts from the date specified in the -startdate parameter.

4.3.9.4.3. Using self-signed certificates

4.3.9.4.3.1. General information

The certificate contains the public key of the respective object and additional information (certificate validity period and other). You can install the certificate to your computer. This is a public information.

4.3.9.4.3.2. Installing self-signed certificates to the web server

Install self-signed certificates to the web server according to the documentation of the used web server.

4.3.9.4.3.3. For web client

If you access the infobase via the secure connection using the web client, indicate to the browser on the computer that a self-signed certificate of the certificate authority (root-ca.crt) can be used to verify the server certificate. To do this, import the certificate to the personal certificate store of the computer from which you access the infobase.

4.3.9.4.3.4. For thin client

If the infobase is published on the web server to which a self-signed certificate is installed, do the following for the thin client to connect to the infobase:

• As a path to the infobase, specify a URL on the web server that uses HTTPS.

• In additional connection settings:

  • In the Select client certificate group, specify the Certificate file value and select the client.crt file. To establish the secure connection between the thin client and the web server where the infobase is published, do not specify this certificate.

  • In the Select server certificate validation method group, specify the CA certificate file value and select the root-ca.crt file.

4.3.9.4.3.5. For mobile client

If the infobase is published on the web server to which a self-signed certificate is installed, in the mobile application builder, do the following for the mobile client to connect to the infobase:

• Open the Certificates for HTTPS list and import the client.crt and root-ca.crt certificates to the list. For the second certificate, select the To verify the server certificate check box.

• When you set up the application list, in the Web server address field, specify a URL on the web server that uses HTTPS.

• In the Server certificate validation method field, select Specified certificate. In the Server certificate field, select the element that corresponds to the root-ca.crt file.

• In the Client certificate field, select the certificate that corresponds to the client.crt file. To establish the secure connection between the mobile client and the web server where the infobase is published, do not specify this certificate.

4.3.9.4.3.6. For collaboration system

To make sure that the collaboration system server uses the secure connection (the WSS protocol), set up the collaboration server accordingly (https://its.1c.ru/db/csdoc/bookmark/cs/TI000000020). Set the full path to the server.jks file as the value of <cs_keystore_path>.

4.4. Restarting 1C:Enterprise

In some cases, the client application cannot get access to the infobase. 1C:Enterprise notifies the user of it and prompts to retry the infobase connection in 60 seconds. It happens when:

• You try to start Designer when it is already started for this infobase.

• Exclusive mode is enabled for the infobase.

• Versions of 1C:Enterprise client and server do not match.

• 1C:Enterprise server is not found.

• Database server is not found.

• Connection to the infobase is prohibited:

  • Session start is locked using the client application startup command line, the cluster console, or the SetSessionLock() 1C:Enterprise language method.

  • External session management service.

If you cannot connect to the infobase, a dialog box with related information is displayed, and the user is prompted to retry starting 1C:Enterprise in 1 minute or close the 1C:Enterprise launcher.

In this dialog box, the situation description can be displayed both as a simple text and as a formatted text. 1C:Enterprise attempts to display the situation description as a formatted string when:

• Exclusive mode is enabled for the infobase. The situation description is displayed as a formatted string if the message text is set to a value of the FormattedString type when you set exclusive mode.

• Session start is locked using the SetSessionLock() method. The situation description is displayed as a formatted string if the SessionsLock.Message parameter is set to a value of the FormattedString type. For more information on the session start lock, see Manually, for all.

• Session start is forbidden by the external session management service. The situation description is displayed as a formatted string if the external session management service returns the ErrorDescription parameter. The parameter value is received from the value of the FormattedString type using the XDTOSerializer.XMLString() expression.

A text message is considered a formatted string if the following expression is executed: String(XDTOSerializer.XMLValue(Type("FormattedString"), Text)) <> Text, where Text is a string passed by third party applications (the external session management service, the cluster console, the rac utility, and so on).

If you load the infobase from a DT file in Designer, you will be prompted to restart Designer after the infobase is loaded.

When a critical error occurs in 1C:Enterprise mode, you are prompted to restart the client application with the same parameters as used by the client application that is abnormally terminated.

Chapter 5. Maintaining the infobase list

5.1. General information

The 1C:Enterprise startup window includes the following controls for infobase list management: add new infobases and infobase folders, move infobases between folders, edit infobase properties, and delete unnecessary infobases from the list.

The list of infobases is presented as a list (by default) or a tree. You can change the list display mode in the dialog box of 1C:Enterprise startup settings.

Fig. 25. Starting 1C:Enterprise

5.2. Adding infobases

5.2.1. Adding new infobases

5.2.1.1. General information

To add a new infobase to the list, click Add…. A dialog box will be displayed.

Select Create infobase to create an infobase based on the template, or create an empty infobase.

Click Next>. A dialog box will be displayed.

If you choose to create an infobase from a template, select the source template from the list.

Click Next> to specify the infobase name and location type.

Type in the infobase name. This name will be displayed in your infobase list. Maximum infobase name length is 255 characters. You are free to provide a long descriptive name for your infobase. The infobase name must be unique in the infobase list.

5.2.1.2. Creating an infobase in file mode

To create an infobase in file mode, select the infobase location type.

Specify the directory where the infobase will be located. If a non-existent directory is specified, it will be created automatically when 1C:Enterprise starts.

Click Select to open the standard dialog box for selecting an existing directory.

If you choose to create an empty infobase, select the infobase language in the Language field. Language rules will regulate storing and sorting of data in the infobase. If you have selected a template, the language field might not be displayed.

Click Next > to open the page for setting the startup parameters (see Infobase startup parameters).

If an empty infobase was created and configuration files are not found in the specified directory, the window for selecting the infobase creation mode will also be displayed when you select 1C:Enterprise run mode. If you choose to create an infobase from a template, the infobase is created based on this template.

You can create a database in different version formats: 8.2.14 and 8.3.8. By default, the database is created in 8.3.8 version format. To change the default format, use the conf.cfg file. To convert the 1Cv8.1CD file into different formats, use the cnvdbfl utility.

5.2.1.3. Creating an infobase in client/server mode

5.2.1.3.1. General information

To create an infobase in client/server mode, select the type of infobase location as shown in fig. 30.

An infobase in client/server mode is described by two parameters:

• Address of 1C:Enterprise server cluster

• Infobase name

As noted above, the 1C:Enterprise server cluster address consists of the main server name and the number of the network port used by the cluster manager (for example, Test_Server:1541). If the cluster manager uses the default network port (1541), you can skip it and specify the server name only. The infobase name is unique within the 1C:Enterprise server cluster.

The infobase name in a cluster is not case-sensitive (it is also true for all technical operations, including functionality assignment rules).

Information characteristics entered in this window and required for infobase creation depend on the DBMS used. Requirements by DBMS are provided in the following sections.

5.2.1.3.2. Microsoft SQL Server

• DBMS type: Microsoft SQL Server.

• Database server: server name. It can be specified based on the computer name if a single instance of the server is installed on the computer or based on the name of the specific instance if multiple server instances are installed on the computer. For example, Server/instance.

If 1C:Enterprise server, Microsoft SQL Server, and Native Client for the Microsoft SQL Server are installed on the same computer, you can use the SHARED MEMORY protocol to establish connection between the servers. To do this, add lpc: prefix before the Microsoft SQL Server name. The DBMS server name will look as follows: lpc:Server/instance.

• Database name: the database name begins with a Latin letter or an underscore (). The database name may contain Latin letters, digits, as well as and $ characters. Maximum length of the name is 63 characters. No spaces are allowed in the name. The database name cannot match any reserved word of server database query language.

• Database user: name of the database server user on whose behalf the database is accessed. To be able to edit structure of the selected database, the user must be the database server administrator (sa) or database owner. In the latter case, the user must have permission to read master database as well as full access to tempdb database. Moreover, the user must have the fixed server role assigned (processadmin or sysadmin).

If the database username and password are not specified in the connection settings, the server cluster will connect to the DBMS using OS authentication. A user on whose behalf a specific instance of the working process (rphost) that accesses the DBMS is running will be authenticated.

• User password: password of the user on whose behalf the database is accessed.

• Date offset: 0 or 2000. Determines the number of years that is added to dates when storing them to Microsoft SQL Server database and subtracted when retrieving the dates. This parameter depends on the specifics of date storing procedure implemented in Microsoft SQL Server. DATETIME type used in Microsoft SQL Server allows you to store dates from January 1, 1753, to December 31, 9999. If you need to store the dates that are earlier than that, set Date offset to 2000. If you do not expect to store such dates, set Date offset to 0. This value cannot be changed after the infobase is created.

5.2.1.3.3. PostgreSQL

• DBMS type: PostrgeSQL.

• Database server: server instance name. If you specify a network port that differs from the default port, specify it using the port keyword: <instance_name> port=<port_number>;. For example: localhost port=6432;.

• Database name: the database name begins with a Unicode 3.2 character or an underscore (). The database name can contain Unicode 3.2 characters, an underscore (), and a dollar sign ($). Maximum length of the name is 63 characters. No spaces are allowed in the name. The database name cannot match any reserved word of server database query language.

• Database user: name of the database server user on whose behalf the database is accessed. The specified user must have the SUPERUSER rights only when the infobase is created. Once the infobase is created, you can revoke the SUPERUSER right from the database server user. For example, for dbuser, the command will look as: alter user dbuser with nosuperuser;.

5.2.1.3.4. IBM Db2

• DBMS type: IBM Db2.

• Database server: server instance name. If any non-default database server instances are installed on the computer, specify the name of the installed IBM DB2 instance after a slash. Example: computer/db2name.

• Database name: the database name must be unique within its location in the directory. In the DB2 database manager for Linux, this location is a directory, and in Windows, this is a logical drive. The database name must begin with a Latin letter. Further, it can contain Latin letters and digits. Maximum length of the name is 8 characters.

• Database user: name of the database server user on whose behalf the database is accessed. The user needs to have the CREATEDB or SUPERUSER privileges, or to be the database owner. Maximum length of the username is 8 characters.

After creating a new infobase, we recommend that you configure the database settings using Configuration Advisor:

• IBM Db2 v9.5:\ https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_9.5.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html.

• IBM Db2 v9.7:\ https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_9.7.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html.

• IBM Db2 v10.1:\ https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_10.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html.

• IBM Db2 v11.1:\ https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_11.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html.

5.2.1.3.5. Oracle Database

• DBMS type: Oracle Database.

• Database server: server instance name. When creating an infobase, specify TNS name as the database server name. Enter the database server name in format //DB_server_name/service_name (or similar).

• Database name: database in 1C:Enterprise terms matches data schema in Oracle Database terms. When you create an infobase in 1C:Enterprise, an infobase user and their data schema are created in Oracle Database. Name of the data schema must only contain the Latin letters, digits, and underscore(_). The database name must begin with a Latin letter. Maximum name length is 30 characters.

• Database user: when creating an infobase in 1C:Enterprise, specify the user on whose behalf the database will be accessed. Specify a user that has DBA rights (for example, SYSTEM) if the data schema is created by the system. Starting from version 12.2, this user must be granted the CREATE ANY TABLE and EXECUTE ANY PROCEDURE privileges. Specify another user if the data schema is already created by the Oracle Database administrator. This can be the user whose data schema is used for 1C:Enterprise, meaning the Database name and Database user can be identical.

Notes on rightsrequired

If an existing data schema is used, the user on whose behalf the database will be accessed does not need the DBA right. The user may have the following rights instead of DBA:

• CREATE SESSION

• CREATE PROCEDURE

• CREATE TRIGGER

• CREATE SEQUENCE

• CREATE TABLE

Instead of granting each right to the user, you can assign the following roles to them:

• CONNECT

• RESOURCE

If you plan to terminate sessions from the management console of the 1C:Enterprise server cluster, the user on whose behalf the database is accessed needs the ALTER SYSTEM access right.

Besides, the following tablespace quotas must be granted to the user: V81C_DATA, V81C_INDEX, V81C_LOB, and V81C_INDEX_BIG (if available).

To grant access rights, you can use the following example:

create user <username> identified "<password>"

grant create session to <username>

grant create table to <username>

grant create trigger to <username>

grant create sequence to <username>

grant create procedure to <username>

grant alter system to <username>

alter user <username> quota UNLIMITED on v81c_data

alter user <username> quota UNLIMITED on v81c_index

alter user <username> quota UNLIMITED on v81c_lob

Notes on password expiration

When using Oracle Database 11 with the default settings, the password expires in 180 days. An error might occur after 180 days: Database server is not found. A DBMS error: ORA-28002: password validity period expires in 7 days. In this case, change the password using DBMS functionality:

• Run the SQL*Plus utility.

• Connect to the database.

• Execute the ALTER USER <UserName> IDENTIFIED BY <Password> command.

\$\$\$remove it\$\$\$ Remember that 1C:Enterprise server stores passwords in the settings file and the next authentication attempt will use the old password. To avoid this, you can specify the old password when executing ALTER USER command, meaning the password will not be changed but only prolonged.

To disable password expiration, refer to documentation for the relevant version of Oracle Database.

5.2.1.3.6. General parameters

The form shown on fig. 31 contains a number of parameters that are not directly related to any DBMS. This section contains the description of these parameters:

• User password: password of the user (specified in the Database user field) on whose behalf the database is accessed.

• If the Create database if none present check box is selected, the database will be created if the specified database server does not contain the database with the specified name. If this check box is not selected, the database will not be created.

• Value of Language (Country) parameter is selected from the list and determines the set of regional settings that will be applied to the infobase. Later, it can be changed in Designer. If an infobase is created based on a template that includes the infobase dump file (*.dt), the Language parameter is not displayed because the language information is already present in the infobase dump file.

• If the Disable execution of scheduled jobs check box is selected, execution of scheduled jobs will be disabled in the created infobase. If this check box is not selected, any scheduled jobs will be started immediately upon establishing server connection.

• The Deny local speech recognition checkbox allows you to disable speech recognition in the client/server infobase.

5.2.1.3.7. Creating a database

If all parameters are specified correctly, the following actions are performed:

• Attempt to connect to the specified database on the specified database server using the specified user parameters is made.

• If the database is unavailable and the Create database if none present check box is selected, an attempt to create the database is made. When creating an infobase in Oracle Database, the user is created with the same username and password. When the user is created, their account is locked. When connecting to the Oracle Database, the 1C:Enterprise server uses username and password specified during creation of the infobase.

• If an existing 1C:Enterprise infobase is found in the database, an attempt to connect to this infobase is made. If no such infobase is detected, a new infobase is created. If a template was specified in parameters while creating the new infobase, the template will be applied upon initialization.

For more information on the page for specifying infobase startup parameters, see Infobase startup parameters.

5.2.1.3.8. Simultaneous use of a database by several infobases

When creating an infobase on the 1C:Enterprise server, the same database can be assigned for several infobases. However, the structure of internal cluster data implies that one set of internal data corresponds to one database. Simultaneous use of several internal data instances with one database breaks their logical integrity.

When several infobases use the same database simultaneously, the following is disabled:

• Infobase locks (in particular, running two instances of Designer may lead to irreparable configuration damage).

• Object locks.

• Lock manager.

• Getting current timestamps.

• Other tools that use separated data stored by the cluster manager.

Simultaneous data modification in such conditions might lead to irreparable data damage. When several infobases read the same data simultaneously, results might be unreliable for all infobases if at least one infobase modifies or locks the data in any way.

That is why it is not recommended that you use one database with several infobases.

At the same time, simultaneous connection of several infobases to one database might be useful for configuration debugging and error analysis in configuration and platform. That is why connecting several infobases to one database is not directly prohibited in 1C:Enterprise. However, when you use this feature, do it with a clear understanding of the above features and restrictions.

5.2.2. Adding an existing infobase

5.2.2.1. General information

If you choose to add an existing infobase, you can add any infobase located on a local computer, in the local network, on the 1C:Enterprise server, or the web server to the list (for a thin client and a web client only, see Web server-based infobase).

After clicking Next >, the dialog box for specifying the infobase name, its location type, and parameters is displayed.

Type in the infobase name. This name will be displayed in your infobase list. Maximum infobase name length is 255 characters. You are free to provide a long descriptive name for your infobase.

In the dialog box, you need also to select and specify parameters for accessing the infobase.

You can select the infobase type manually or have it automatically detected from your clipboard content. If the clipboard contains a path to infobase directory (paths to infobases in file mode must not include quotation marks) or URL for web server access, 1C:Enterprise attempts to automatically identify the infobase location type as soon as the infobase adding dialog box is opened. If the attempt is successful, the Select infobase location type radio button will be set and the infobase parameters will be filled. The same applies if you paste the content of the clipboard to the infobase name field and press Tab.

5.2.2.2. File mode

In the dialog box, select the This computer or LAN computer infobase location type. Then, select the directory where the infobase is located. If a non-existent directory is specified, it will be created automatically when 1C:Enterprise starts.

Click Select to open the standard dialog box for choosing the infobase directory.

For more information on the page for specifying infobase startup parameters, see Infobase startup parameters.

5.2.2.3. Client/server mode

In the infobase adding dialog box, select the 1C:Enterprise server infobase location type.

Specify the following data in the fields:

• 1C:Enterprise server cluster address. The cluster address is the address of the main cluster server with the specified number of cluster manager process network port (by default, 1541).

• Infobase name.

No checks are made to make sure that the infobase with the specified parameters is available.

If the infobase with the specified parameters is not found during Designer startup, the user will be prompted to create a new infobase. If the user confirms, Designer displays the Create an infobase or folder form.

In this form, enter the parameters for creating the new infobase.

For more information on the page for specifying infobase startup parameters, see Infobase startup parameters.

5.2.2.4. Web server-based infobase

To add an existing infobase located on web server, run the 1C:Enterprise thin client (1cv8c file).

In the infobase adding dialog box, select the Web server infobase location type.

If you need to specify additional parameters for web server connection, such as proxy server parameters and web server authentication method, click Additional… under the Infobase address line.

The Select web server authentication method parameter allows you to select the authentication method:

• Select automatically. Attempts to log on using operating system authentication. If the attempt failed, request login/password in an explicit way.

• Prompt for username and password. Always prompts for the username and password for web server authentication.

For more information on the page for specifying infobase startup parameters, see Infobase startup parameters.

The Development management address parameter specifies the address of the server that can perform various administrative commands. It can be either an address of Designer running in agent mode or an address of a standalone server that services the published infobase. Specify an address as follows: host:port.

See also:

• Designer in agent mode (see Running Designer in agent mode).

• Standalone server (see Standalone server).

5.2.3. Infobase startup parameters

On this page, you can specify the infobase startup parameters.

Authentication method can take the following values:

• Select automatically. Attempts to log on using operating system authentication. If the attempt fails, prompts for the username and password.

• Prompt for username and password. Always prompts for the username and password for authentication.

The Connection speed parameter determines the expected speed of connection to the infobase or 1C:Enterprise server. The parameter can take values:

• Select on startup. Select connection speed manually every time you start the infobase using the Slow connection check box in the 1C:Enterprise startup window. If a specific value is specified in the infobase properties (Standard or Low), the Low connection speed checkbox in the 1C:Enterprise startup dialog box cannot be changed and shows the value specified in the infobase properties.

• Normal. Standard connection speed. Normal operation.

• Low. Low connection speed. For more information on using 1C:Enterprise 8.3 in this mode, see 1C:Enterprise 8.3 Developer Guide. \$\$\$remove it\$\$\$

The Slow connection check box in the 1C:Enterprise startup dialog box of the thin client is available for editing if the infobase list has at least one infobase with 1C:Enterprise version 8.2 and later and the Connection speed parameter set to Select on startup. In other situations, the check box displays the connection speed specified in infobase properties and its state cannot be changed.

In the Additional startup options field, specify command-line options for the executable file. For more information about command-line parameters, see 1C:Enterprise help (1C:Enterprise 8 startup and startup parameters section). The L and VL parameters specified in this field will only be effective if you start the infobase using the interactive launcher (see Interactive launcher).

The Default run mode parameter defines which client will be used to access the infobase:

• Select automatically. In this mode, the client application type is determined based on the Default run mode configuration property and the Run mode user property.

• Thin client. Thin client will be used for startup.

• Web client. Web client will be used for startup. This type of client is available only if the infobase is accessed via the web server.

• Thick client. Thick client will be used for startup. This type of client is unavailable if the infobase is accessed via web server.

In the 1C:Enterprise version field, specify the 1C:Enterprise version to be used for infobase access. Moreover, you can set it to 8.1 or 8.0. In this case, 1C:Enterprise 8.1 or 8.0 installed on the computer will be used to access the infobase. You do not need to specify the version then.

The Bitness field allows you to specify bitness of the client application to be used with this infobase. This field is only available if infobase properties are edited on 64-bit Windows. For details on how to select the client application bitness, see Determining application bitness.

5.2.4. Certificate settings

If you add an infobase located on the web server (see Web server-based infobase) and HTTPS is specified in the Infobase address field (for example, instead of http://localhost/DemoMA, the address is https://localhost/DemoMA), when clicking Additional…, the page with certificate settings becomes available together with additional web server access parameters.

On this page, you can specify the source location for client certificates and verification method for server certificates. Let us review these parameter groups in detail:

• Select client certificate. Selects the location of the client certificate:

  • Do not provide certificate. Connection can be established only to web servers that do not require a client certificate.

  • Certificate file. Allows you to select a file with a client certificate and its private key. If the file is protected with a password, the user will be offered to enter the password when establishing connection.

  • Windows certificate/Linux certificate/macOS certificate. Client certificate is received from the system certificate store in the operating system used (Windows or macOS) or the dedicated Linux directory. If the system has several client certificates suitable for the connection to establish, you can tell the system what to do:

    • Select last used certificate. User is prompted to select a certificate using the system dialog box for certificate selection. Further, this certificate will be selected automatically.

    • Always prompt to select certificate. User is prompted to select a certificate using the system dialog box for certificate selection regardless of whether any certificates were selected earlier. The selected certificate can be automatically selected in the future if the Select last used certificate option is selected.

    • Select certificate automatically. Suitable certificate is selected and used automatically. The certificate selection dialog box is not displayed.

• Select server certificate validation method. Indicates how to verify the certificates provided by the web server:

  • Do not validate server certificates. Web server certificate is not verified and the certification authority's (CA) certificates are not used.

  • CA certificate file. Allows you to choose a file where CA certificates are stored. If the file is protected with a password, the user will be offered to enter the password when establishing connection.

  • Windows certificate store/Linux certificate store/macOS certificate store. Specifies that CA certificates need to be received from the certificate store in the operating system used (Windows or macOS) or the dedicated Linux directory.

See also:

• Using certificates

• Self-signed certificates.

5.3. Infobase editing

To change the name or directory of an infobase from the list, select the infobase name and click Edit. The infobase properties are edited in a dialog box similar to the dialog box used to add an existing infobase (see Adding an existing infobase).

5.4. Deleting infobases from list

To delete an infobase from the infobase list, select its name in the list and click Delete. The selected infobase will be deleted from the list.

When removing the infobase from the list, the infobase service directories located in the following directories are also deleted:

• Windows: %APPDATA%\1C\1cv8 and %LOCALAPPDATA%\1C\1cv8.

• Linux: ~/.1cv8/1C/1cv8.

• macOS: ~/.1cv8/1C/1cv8.

5.5. Order of infobases in the list

If sorting by name is not enabled in the startup dialog box settings (see section below), you can change the order of infobases in the list using the mouse or context menu commands.

To move an infobase up or down in the list, click and drag it up or down. As you drag the infobase, an outline of its new position is displayed.

Then, release the mouse button.

You can also change the order in the infobase list using the context menu commands: Move up (Ctrl + Shift + Up arrow) and Move down (Ctrl + Shift + Down arrow). When you attempt to move up an infobase at the top of the list, it is moved to the bottom of the list; and vice versa.

You can also use the Sort ascending and Sort descending commands to order the infobase list.

If tree view is enabled in the startup dialog box settings (see Startup window settings), please be informed that while dragging an infobase:

• If the outline is displayed on a folder, the dragged infobase will be placed at the end of that folder.

• To place an infobase or folder to a specific position within a folder, expand the folder first.

5.6. Maintaining the hierarchical infobase list

This section describes operations for creating and reorganizing the infobase list with tree view.

5.6.1. Adding an infobase folder

It is recommended that you create an infobase list when you use multiple infobases of the same type or when you use so many infobases it is hard to find the one you need.

Folders can be created if the Display as a tree mode is enabled in startup dialog box settings.

When this mode is enabled, the infobase list is displayed as a tree with the Infobases root folder. This folder cannot be changed or deleted.

To add an infobase folder, select the folder where you want to create the new folder, and click Add. This opens the add mode selection dialog box.

Select the Create a new folder mode and click Next >.

Specify the folder name (the / character is not allowed) and click Finish. The created folder is placed in the specified infobase folder (at the end of the folder if sorting by name is not enabled).

5.6.2. Editing infobase folders

To change the infobase folder name, select the folder in the tree and click Change. The Edit folder window opens. It contains the name of the selected infobase folder.

Enter the new folder name (the / character is not allowed) and click Finish.

5.6.3. Deleting infobase folders

To delete an infobase folder from the list, select it in the list and click Remove. The selected folder will be deleted from the infobase list.

5.7. Startup window settings

Click Settings in the startup dialog box. This opens the startup settings dialog box.

This dialog box is used to change settings from the interactive launcher. When changing settings from the thick client (1cv8), the settings window does not include the Versions used field. When changing settings from the thin client (1cv8c), the Configuration and update templates directories field is excluded.

If the Display as a tree check box is selected, the infobase list will be displayed as a tree.

If the Sort by name check box is selected, the infobase list is sorted by name.

If the Show recently selected infobases checkbox is selected, in the Remember recently selected infobases field, the number of recently used infobases is specified.

The list of recently used infobases is displayed at the top of the infobase list. Names of the recently used infobases are highlighted in bold font. This list is displayed in historical order, meaning that the infobase used most recently is at the top of the list. List sorting by name does not affect the order of recently used infobases. You cannot move these infobases up or down. To edit or delete an infobase, click it in the infobase list.

The list of directories with configuration and update templates is specified in the Configuration template and update directories field. For example, this list might include a directory containing templates for the entire company, or a local template directory.

The Lists of shared infobases field contains editable lists of shared infobases. When starting 1C:Enterprise, infobases from the shared infobase lists are automatically added to the general infobase list. If the local configuration file has the CommonCfgLocation parameter set, the infobases specified in the CommonInfoBases parameters (if any) of the shared configuration file (1cescmn.cfg) will be added to the main infobase list. Infobases obtained via Internet services will also be added to the infobase list. For details on Internet services for getting the list of shared infobases, see Internet service for getting the list of shared infobases.

Paths to the template directory or the list of shared infobases are displayed in the settings window only when these paths are specified in parameters of the 1cestart.cfg local configuration file. If these paths are specified in the shared configuration file (1cescmn.cfg), they are not displayed in the settings window.

The Used versions field contains the detailed list of 1C:Enterprise versions available. This list is used when the user needs to work with the infobases using a 1C:Enterprise version that is different from the latest version installed on a computer. For example, when matching string 8.3=8.3.24.100 is specified, the infobase properties will display version 8.3, and version 8.3.24.100 will be used to open the infobase instead of the latest version. The Bitness column allows you to specify the bitness of the client application that will be used for startup. For details on how to select the client application bitness, see Determining application bitness.

The Use hardware license (dongle) parameter searches for a dongle when starting the client application. Changes made to this parameter take effect at the beginning of the next session, changing the value of the UseHwLicenses parameter in the 1cestart.cfg file.

The Automated installation of the new version parameter controls auto installation of new versions. Changing this checkbox affects the AppAutoInstallLastVersion parameter in the 1cestart.cfg file.

The Allow 1C:Enterprise Development Tools parameter controls the visibility of the 1C:EDT button, clicking on which starts 1C:Enterprise Development Tools for the current infobase.

Click Delete unused versions to open the dialog box that allows you to set up automatic deletion of outdated versions (for details, see Deleting versions automatically).

In the dialog box:

• Select/clear the Automatically delete unused versions check box to enable or disable this feature.

• Select the Delete later versions parameter to set the criteria of version obsolescence.

• In the Never delete versions table, you can specify versions that cannot be automatically deleted.

5.8. Shared infobase lists

Lists of shared infobases are stored in files with v8i extension. They contain links to shared infobases.

Set the location of shared infobase lists in the CommonInfoBases parameter of configuration files. Lists of shared infobases have the same format as the main infobase list.

A list of shared infobases can be generated manually or by saving existing infobase links to a file. To save an infobase link, execute the Save reference into file context menu command in the infobase list.

The list of shared infobases can be used to start 1C:Enterprise. When opening a file with the v8i extension, 1C:Enterprise will be started and the startup dialog box will contain the links from the list of shared infobases.

You can also specify an Internet service address that will provide a list of shared infobases when it is unavailable on the local network. For example, an infobase can be used over the Internet (connection via web server). For details on Internet services for getting the list of shared infobases, see Internet service for getting the list of shared infobases.

When the list of shared infobases is obtained for the first time, this list is placed at the root of the list or within a folder in this list. When the list is obtained again, the infobase information is updated but location of the shared infobase in the user list remains the same. If the user moves the shared infobase to another folder in the list and obtains the list of shared infobases again, position of the shared infobase in the list does not change.

Chapter 6. Infobase administration

6.1. General information

When working with 1C:Enterprise, you might need to perform system administration duties, such as:

• Maintaining the user list

• Assigning user rights

• Creating backups

• Generating technological log for error analysis

Designer includes a variety of administrative tools designed to perform the above tasks.

In 1C:Enterprise, you can create a list of users authorized to use the application. This list is used for user authorization when signing in. Consider that the list of 1C:Enterprise users is not included in the application. This list is created individually by a company that uses the application.

A password for signing in can be set for each user. The password is used to verify user rights to operate 1C:Enterprise.

Creating backups is another example of a crucial administrative task. To ensure data recovery with minimum losses in case of database damage, the backup procedure must be performed on a regular basis. \$\$\$remove it\$\$\$ The greater amount of data changes daily, the more frequent backup is required.

This chapter covers the 1C:Enterprise administration activities that can be performed in Designer.

6.2. Maintaining the user list

6.2.1. General information

To open the user list, click Administration - Users.

The window with the user list includes a toolbar and a tabular field with two columns:

• Name column contains the list of users allowed to sign in to 1C:Enterprise 8.

• Full name column contains full names of the users.

Users with access passwords are marked with the lock icons (for example, Seller in fig. 45).

Users with no role or authentication defined are marked with question mark icons (for example, Sales manager in fig. 45).

In the Actions menu, you can add or delete users, configure the list appearance (filters, column content and order, sorting), or export the list to a spreadsheet or text document.

You can change the infobase user property using 1C:Enterprise language. To do it, use the InfobaseUsers global context property and an object of the InfobaseUser type.

6.2.2. Adding new users

To add a new user, in the User list window, click Actions - Add. The window for editing user parameters appears.

On the Main tab, the name and full name of the user are displayed.

We do not recommend that you use the : character in user names. Uniqueness if infobase users is determined by a combination of three fields: name, full name, and OS username (if OS authentication is enabled). Uniqueness is determined by the first 64 characters of the Name field, the first 128 characters of the Full name field, and the first 128 characters of the User field provided that OS authentication is enabled. It is recommended that you do not exceed the 64 characters limit for the Name field.

If you fill in the Email address field, you will be able to use email authentication (described further). Besides, the Email address and User cannot recover the password fields refer to the user password recovery functionality. If the Email address field value is not specified, this user cannot recover their password by email, only via the website. Every infobase user must have a unique email (regardless of the character case). The email must not exceed 128 characters. If the User cannot recover the password check box is selected, the password can be recovered by the system administrator only.

You need to assign an authentication method to the user. For more information about the authentication types supported by 1C:Enterprise, see Authentication types.

Each Authentication… checkbox (1C:Enterprise authentication, OS authentication, OpenID authentication, OpenID Connect authentication, Access token authentication, QR code authentication, and Email authentication) indicates whether a corresponding authentication method is enabled (for more information about authentication methods, see Authentication types). These check boxes do not affect the order of authentication attempts. When assigning authentication types, please remember:

• When no Authentication… check boxes are selected, the user will not be able to sign in to the application.

• To attempt authentication using the OpenID, OpenID Connect, or QR code, configure the infobase publication on a web server in a certain way (see OpenID ).

• A user will not be able to sign in to the application if they are authenticated using the OS, OpenID, OpenID Connect, or QR code authentication, but the checkbox allowing this authentication type is cleared.

• To disable OS or OpenID authentication, you can also use the client application startup command-line parameters.

To enable the operating system authentication, select the OS authentication checkbox, and then map the operating system user and the infobase user. To do this, specify the operating system user in the User field. It becomes available after selecting the OS authentication checkbox. The value of the User field will be used to search for the infobase user that matches the current operating system user. Specify the operating system user as follows: \domain_name\username. The operating system username cannot exceed 128 characters.

To enable email authentication, select the Email authentication checkbox and specify the user's email address in the Email address field.

If the User cannot change password check box is selected, the user cannot change their password (this option only applies to 1C:Enterprise authentication).

If the Show in list check box is selected, the user is displayed in the user selection list when connecting to the 1C:Enterprise infobase. If 1C:Enterprise authentication is disabled for the user, the Show in list check box becomes unavailable and the user is not displayed in the user selection list when connecting to the infobase.

The Unsafe operation protection checkbox specifies whether protection from unsafe operations is enabled for this user.

On the Other tab, available roles and the language are displayed. If multiple roles are defined in the configuration, you can assign several roles to the user. Besides, you can select the 1C:Enterprise run mode for the user. When using Auto value, the run mode specified in the Run mode configuration property is used. When a user requires a special run mode, you can assign it here. For example, when a user works in managed application mode, set the Run mode field to Managed application.

The Assignment rule key property allocates user connections to production servers.

You do not have to fill all fields in the dialog box for editing user properties. You can do it later.

If user separation is enabled, the data separation tab is also displayed in the user parameters.

On this tab, all available separators (not all common attributes) are displayed. For each separator, you can specify a value and usage upon user authentication. If the check box to the left of the separator name is selected, the value of the selected separator applies to the current user. The value itself is specified in the input field to the right of the separator name. If the separator value is set for the user (not only the value but also the usage flag), changing the User separation and Authentication separation separator properties affects visibility and availability of this user for selection and authentication purposes.

6.2.3. Copying users

Cloning an existing user is a fast and easy method of creating a new user. When you clone a user, you do not have to create the user from scratch. You simply copy the user and then edit their properties.

To clone a user, select the user from the user list and click Actions - Copy.

Name of the user might be transformed while cloning to ensure uniqueness. All other properties of the cloned user are identical to the source user (except the password).

6.2.4. Setting password

To avoid signing in to 1C:Enterprise under another username, a personal password can be set for each user allowed to sign in. Just like a username, the password confirms user rights to access 1C:Enterprise.

Enter the password in the password entry field. The password must comply with the password policy set for the infobase or the user. You can view the password policy set for the user only using 1C:Enterprise language. Password length must not exceed 255 characters. The password you enter is displayed as a string of asterisks.

If the user does not want to create their own password, they can use the built-in password generator. To do this, they need to click the Generate password hyperlink. The password generated this way corresponds to the state of infobase parameters. Parameters of system-generated passwords depend on the minimum password length specified in the infobase parameters:

• The minimum length is set to less than 7 characters. In this case, the password consists of lowercase Latin letters only.

• The minimum length is set to 7 or more characters. In this case, the password consists of digits, lowercase and uppercase Latin letters. The password meets the password complexity settings regardless of the respective infobase parameter state.

• The minimum password length is not controlled and is set to 0. In this case, the password is complex and 7 characters long. The password consists of digits, lowercase and uppercase Latin letters.

The Password confirmation field availability depends on how the value in the Password field is generated:

• The user generates the password. In this case, they can specify the set password in the Password confirmation field again. If the passwords do not match, the following warning is displayed once you click OK: Password and password confirmation do not match. The password is not set.

• The password is generated using the built-in password generator. In this case, the Password confirmation field is unavailable. The system will automatically put the new password there. If the user is not satisfied with the generated password, they can generate a new one by clicking Generate password again (the number of clicks is unlimited).

If the user changes the password, it can be viewed until the user clicks OK. For this purpose, there is a button on the right side of the Password and Password confirmation fields. The password display mode is changed by repeated clicking. The password is displayed in real or disguised characters. Once the password is set and the form is opened again, you cannot see the password. The password entry field displays Password is set, but does not show the password.

To clear the password, in the Password or Password confirmation field, press Shift + F4. If the password is generated by the system, it will be cleared in both input fields. If the password is created manually by the user, it will be cleared in the current input field.

To cancel the password change, click Cancel. Please understand that clicking Cancel cancels both the password change and any other changes you might have made in this dialog box.

There are several ways to recover the forgotten password:

• Set a new password. This requires administrative access to the user list.

• Recover the password. This procedure must be configured in the infobase, and the user must be allowed to perform this action.

Users with passwords are marked with the lock icon in the user list.

See also:

• Infobase parameters.

6.2.5. Password policy

6.2.5.1. General information

Depending on the infobase and the user access level, requirements for complexity, uniqueness, and lifetime of the password might change. For example, some users can use simple passwords with a certain number of characters, but other users require complex passwords with a certain lifetime.

For this purpose, 1C:Enterprise provides password policies. A password policy is a set of requirements aimed at enhancing the infobase security by establishing requirements for user passwords.

You can set a password policy both for the entire infobase and for specific users. If you configure a password policy for the entire infobase, use the dialog box for editing infobase parameters. This dialog box uses the Password requirements group that contains a set of parameters. The same set of parameters will be used to access the application using 1C:Enterprise language. In this case, the UserPasswordPolicy object is used.

6.2.5.2. Password policy parameters

The user password policy is described by a certain set of parameters. You can change these parameters both interactively and via the UserPasswordPolicy object from 1C:Enterprise language. Therefore, the property name of this object is given for each parameter in parentheses.

Password complexity check (PasswordStrengthCheck)

When this parameter is enabled, user passwords must meet the following requirements:

• The minimum password length must be greater than or equal to 7 or the Minimum password length property if its value is greater than 7.

• Password must include characters from at least three of the following groups:

  • Uppercase letters

  • Lowercase letters

  • Digits

  • Special characters

• Password must not match the username.

• Password must not be an alphabetical sequence of characters.

Enabling these restrictions for infobase user passwords does not affect the existing passwords. Restrictions will be applied only after the current password is changed or a new infobase user is added. However, password verification is performed according to the current infobase settings. In particular, this means case-sensitivity check is enabled for passwords when Password complexity check is enabled.

For example, if the user password is PaSs and the Password complexity check parameter is disabled, the user can enter their password as pass, PASS, or PasS, and still be able to sign in. After enabling Password complexity check parameter, the user cannot sign in until they enter the case-sensitive password PaSs.

Password compromise check (PasswordCompromiseCheck)

This parameter indicates that passwords in this infobase will be checked not only for complexity (if the corresponding parameter is set), but also for the possibility of specifying them. There may be various reasons for this, for example, the password has been compromised many times, or it does not comply with the corporate stop word list.

You can set up the password compromise check parameters in the Additional authentication settings dialog box or using 1C:Enterprise language.

Minimum password length (PasswordMinLength)

Defines the minimum length of a user password. If Password complexity check is enabled, the minimum length of the user password is 7 characters. However, you can use 1C:Enterprise language to set any password length, even if this property is set in the password policy settings.

Action if passwords violate requirements on authentication ActionOnPasswordRequirementsViolationOnAuthentication

If a password does not match the current system or user password policy, the administrator can choose what action the platform will take in this case. Possible options (the value of the ActionOnThePasswordRequirementsViolationOnAuthentication system enumeration):

• None. Do nothing.

• SuggestPasswordChange. Inform the user that the password does not comply with the current policy and prompt to change the password (a form opens). The event is logged. You can continue working without changing the password.

• RequirePasswordChange. Inform the user that the password does not comply with the current policy and prompt to change the password (a form opens). The event is logged. You cannot continue without changing the password. If the user is not allowed to change the password, an exception is generated and the user cannot authenticate in the infobase.

Maximum user password lifetime (PasswordMaxEffectivePeriod)

Defines a period after which you need to change the password. The "period" denotes a time interval from the moment the current password is set. The specified time interval is set in seconds.

If you set the parameter to 0, it will not result in any actions.

Minimum user password lifetime (PasswordMinEffectivePeriod)

Defines a period before which you will not be able to change the password. The "period" denotes a time interval from the moment the current password is set. The specified time interval is set in seconds.

If you set the parameter to 0, it will not result in any actions.

Password expiration notification period (PasswordExpirationNotificationPeriod)

The parameter specifies a time interval before the current password expiration when the application starts notifying the user that they need to change the password. The specified time interval is set in seconds.

If you set the parameter to 0, it will not result in any actions.

Deny password reuse among recent ones (PasswordReuseLimit)

With this parameter, you can specify how many recent passwords the application will use when verifying the uniqueness of the new password. For example, if the parameter value is set to 5, the new password must not match any of the last 5 passwords of this user.

If you set the parameter to 0, it will not result in any actions.

6.2.6. Additional authentication settings

6.2.6.1. General information

1C:Enterprise allows you to manage some parameters of the authentication dialog box, configure parameters for restoring a forgotten user password, configure password compromise check, and some other parameters. You can do it in the Additional authentication settings dialog box in Main menu – Administration – Additional authentication settings.

6.2.6.2. Authentication

On the Authentication tab, you can configure the authentication feature.

Additional information

Select the Show the "Need help?" link checkbox to set the value of the Link address property. In this field, enter a URL to follow when clicking the question mark icon in the authentication dialog box. The parameters of the data area for which the authentication dialog box is opened will be added to this hyperlink before navigation. Data area parameters are set in the same way as the Z command-line option of the client application startup. The resulting URL will be as follows: URL?Z= "separator values".

Saving authentication group

The Allow saving authentication checkbox enables the Remember checkbox in the authentication dialog box. Using this checkbox, you can remember the authentication parameters entered and do not enter the username and password for some time. To set the time during which the authentication parameters will be saved, use the Saved authentication lifetime (seconds) parameter. You can also set these parameters using the default.vrd infobase publication file. The settings set in the default.vrd file have priority over the settings in the Additional authentication settings dialog box.

When authentication is saved, the password that the user used for authentication is not saved on the computer (this is not secure). Instead of the password, a special token is stored, which is limited by lifetime and depends on the password. When the password changes, the token becomes invalid.

If there is a danger of unauthorized access to the infobase using a compromised secure access token, we recommend that you, firstly, replace passwords for all users whose secure access tokens are compromised or suspected of compromise, and secondly, prohibit the authentication method that the compromised users used. The second method will lead to users with up-to-date (not compromised access data) passwords/saved access tokens not being able to access the infobase. Choose the solution depending on the size of the alleged compromise, the access level of compromised users, and other information security parameters in the company.

To "forget" the saved user authentication, change this user's password in Designer or using the administrative application tools. On all devices where the user saved authentication using the checkbox in the authentication dialog, they will need to authenticate with a new password.

We do not recommend that you enable both saving authentication and idle session termination (see Idle session termination) if idle session termination is enabled to minimize the risk of unauthorized data access. In this case, forced session termination will not protect against unauthorized access, as an attacker can still get access to the infobase using saved authentication credentials.

The enabled Save authentication by default checkbox allows you to configure the user authentication dialog box so that the authentication method successfully used by the user becomes the default method for the next authentication attempt in the application.

See also:

• default.vrd file.

6.2.6.3. Email authentication

On the Email authentication tab, you can enable/disable and configure the email authentication feature.

To enable email authentication, select the Use email authentication checkbox. If the feature is enabled and configured, select email authentication in the user selection dialog box.

The fields for entering the user's email address will appear on the form.

Enter the email address in the field with the Email address hint. If there is a user with such email in the system, an email with a verification code will be sent to them.

By entering the verification code in the next dialog box, the user is authenticated in the infobase.

The verification code sent by email is managed by a set of parameters that are configured on the tab:

• Code length. Specifies the length of the user authentication verification code.

• Maximum number of failed attempts to enter the code. Specifies how many times the user can make mistakes when entering the confirmation code. Once the maximum number of attempts is exceeded, the received code becomes invalid. The user will need to request a new authentication verification code.

• Lock duration of confirmation code update request. Interval between two consecutive requests of the user authentication verification code.

• Verification code validity period. Defines the validity period for the sent authentication verification code. If expired, request a new authentication verification code.

• Verification code alphabet. Contains a set of characters for the verification code generation. The string can be empty or contain from 10 to 256 various characters. If the string is empty, the alphabet consists of decimal digits from 0 to 9 (including).

• Use standard sending service. Allows you to send a verification code via the standard 1C:Enterprise email service. In this case, you cannot change the email sender, subject, format, and content. Emails will always be sent from <authentication@1c.com> with the Login verification code subject.

If this check box is cleared, you can configure parameters for sending verification code messages. Specify these parameters in the Sender parameters group.

Sender parameters group

In this group, you can specify verification code message parameters and parameters of an email server used to send them.

The Fill in from password recovery settings hyperlink allows you to fill in the mail server settings with the same settings as specified for the mail server used to recover the user's password.

Specify sending parameters using the following parameters:

• SMTP server address. Allows you to specify an SMTP server address.

• SMTP user and SMTP password. Contain the username and the password required for authentication on the SMTP server.

• SMTP port. Network port used for SMTP:

  • Port 465 for secure connections (used by default).

  • Port 25 for unsecure connections.

• Use SSL. Specifies that SSL must be used to connect to the SMTP server.

Email parameters are specified using the following parameters:

• Sender name. Text to be displayed in the email message as the email author (the From field).

• Message header. Text to be specified in the message header (the Subject field).

• Message text. Opens the HTML document editor to write a message. You can use the following pseudo-variables to specify email parts that change:

  • ApplicationPeresentation. Presentation of the configuration used in the current infobase.

  • UserName. Username.

  • UserPresentation. Full user name.

  • VerificationCode. Authentication verification code.

The variable values must begin with "&", for example: Good afternoon, &UserPresentation!.

You can also set up email authentication using 1C:Enterprise language. For this purpose, you can use the AdditionalAuthenticationSettings global context property.

See also:

• Setting up email authentication using 1C:Enterprise language.

6.2.6.4. Password recovery

The Password recovery tab contains parameters that are used to configure the user's password recovery.

1C:Enterprise offers several ways to recover a forgotten user password. There are several settings that control this functionality. Some of them are located in the infobase user properties and the others are contained in the settings dialog box:

• User settings:

  • Email address. Email address to which the code required to set a new password will be sent.

  • User cannot recover the password. If you select this check box, you will not be able to recover your password by email. You will be able to do it only with the help of the infobase administrator.

The option to recover a password by navigating to a URL (for example, to a website) depends on the logic of this page.

• The password recovery settings are located on the Password recovery tab of the Additional authentication settings dialog box.

You can recover the password using either a web page or a recovery code sent by email. You cannot select both password recovery methods at a time.

For OpenID authentication, the password is changed on the side of the authentication provider because it performs authentication. Once the password is changed, the user navigates to the provider authentication form. In this case, the password recovery method depends on capabilities provided by the OpenID provider used.

The Follow the URL check box enables password recovery by opening a web browser page whose address is specified in the Link address property of the setup dialog box. The parameters of the data area for which the authentication dialog box is opened will be added to this hyperlink before navigation. Data area parameters are set in the same way as the Z command-line option of the client application startup. The resulting URL will be as follows: URL?Z= "separator values". Implement the whole password recovery logic on the page whose address is specified in the settings.

Select the Send the code to the email check box to enable password recovery by sending a code to the user email address. In this case, the following dialog box is opened:

If the email address specified in the dialog box exists, the confirmation code will be sent to this address and the following dialog box will be shown:

This dialog box specifies the address the email was sent to. It also prompts the user to enter a confirmation code from this email and a new password. When you specify a new password, the application checks whether the password meets the password policy requirements that are set for the user who recovers the password or for the infobase (if no policy is specified for the user or a policy with this name does not exist in the infobase). To use a system-generated password, click Generate password. Such password will meet all the established requirements for user passwords. For more information about the system-generated password, see Setting password.

If the specified email address does not match any user, a diagnostic message will be displayed. If the user is not allowed to recover their password, an error will be displayed after entering the email address.

The dialog box with additional authentication settings also contains the following parameters:

• Code length. Specifies the length of the confirmation code to set a new password.

• Maximum number of failed attempts to enter the code. Specifies how many times the user can make mistakes when entering the confirmation code. Once the maximum number of attempts is exceeded, the received code becomes invalid. The user will need to request a new password recovery code.

• Lock duration of confirmation code update request. Interval between two consecutive requests to change a password verification code.

• Verification code validity period. Defines the validity period for the sent password recovery code. If expired, request a new password recovery code.

• Use standard sending service. Allows you to send a verification code via the standard 1C:Enterprise email service. In this case, you cannot change the email sender, subject, format, and content. Emails will be always sent from <recoverypassword@1c.com >.

If this check box is cleared, you can configure parameters for sending verification code messages. Specify these parameters in the Sender parameters group.

Sender parameters group

In this group, you can specify verification code message parameters and parameters of an email server used to send them.

Specify sending parameters using the following parameters:

• SMTP server address. Allows you to specify an SMTP server address.

• SMTP user and SMTP password. Contain the username and the password required for authentication on the SMTP server.

• SMTP port. Network port used for SMTP:

  • Port 465 for secure connections (used by default).

  • Port 25 for unsecure connections.

• Use SSL. Specifies that SSL must be used to connect to the SMTP server.

Email parameters are specified using the following parameters:

• Sender name. Text to be displayed in the email message as the email author (the From field).

• Message header. Text to be specified in the message header (the Subject field).

• Message text. Opens the HTML document editor to write a message. You can use the following pseudo-variables to specify email parts that change:

  • ApplicationPeresentation. Presentation of the configuration used in the current infobase.

  • UserName. Username.

  • UserPresentation. Full user name.

  • VerificationCode. Confirmation code to change the password.

The variable values must begin with "&", for example: Good afternoon, &UserPresentation!.

You can also set up password recovery using 1C:Enterprise language. For this purpose, you can use the AdditionalAuthenticationSettings global context property.

6.2.6.5. Password compromise check

You can configure the password compromise check feature on the Password compromise check tab.

When users change or set passwords on their own, they tend to choose simple, well-known, or easily guessable passwords. To prevent this, 1C:Enterprise provides a password compromise check feature.

Password compromise check is configured in different places:

• The data sources for check feature are configured on the Password compromise check tab of the Additional authentication settings dialog box.

• The need for the check and the actions to perform are configured in the infobase parameters and in the password policies assigned to specific users.

There are three compromise check channels available. Each of them is enabled separately (all the channels are used simultaneously):

• Standard platform list.

• Custom list of unwanted passwords.

• External password compromise check service.

If the Use standard password compromise check list checkbox is selected, the platform will perform a password compromise check using a built-in list, which is updated when the platform version changes. In this case, the password information will remain in the infobase.

If the Use specified password compromise check list checkbox is selected, the list of unwanted passwords, which you can set for each infobase, will be used for the check. You can set the list either using 1C:Enterprise language or the Password compromise check list group commands. The Import from file command allows importing a list of unwanted passwords from a file. The Clear command clears the list of imported compromised passwords. The size of the custom list of unwanted passwords cannot exceed 100,000 entries.

The Use password compromise check service checkbox allows you to specify that a specialized HTTP service will be used for password compromise check. The Service address field allows you to enter the address of such service. The Service request timeout field allows you to specify what timeout will be set for a request to this service (in other words, the maximum time the platform will spend on a request to the password compromise check service). If the request to the service exceeds the set timeout, the platform considers the request was completed with an error. If the Ignore service errors checkbox is selected, error information is only logged, and operations continue as if the external password compromise check service is missing. If the checkbox is cleared, the error is displayed to the user and the password being checked is considered compromised.

To access the password compromise check service, use the GET request of the <URL>/abcde type, where:

• <URL> is the value specified in the Service address field.

• abcde are the first 5 characters of the SHA-1 hash value of the password being checked (the hash "prefix").

If the service finds hashes starting with the specified prefix, all found hashes are returned to the calling side. Then, the calling side searches for the remaining hash characters in the result of service work. If other characters are found, the password is in the list of compromised ones. So, the service does not know the full hash of the password being checked and cannot restore the password using the passed hash. You can write such service using the 1C:Enterprise platform. In this case, you can fill in the base used for password checks centrally. What's more, you can include words that are prohibited (even though these words can pass the universal password compromise check) as passwords in the company that implemented this service.

As a public password compromise check service, you can use, for example, the "Have I Been Pwned" service (https://haveibeenpwned.com/), which offers an HTTP interface with the https://api.pwnedpasswords.com/range/ address. You can find the description of this interface here: https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange. The 1C:Enterprise platform expects the password compromise check service to function exactly as described in the given link.

The password compromise check (provided that this feature is enabled and configured correctly) is performed when:

• Writing a value of the InfoBaseUser type.

• Editing or creating a user in Designer.

• Changing the password when restoring the user password.

• Changing the password during the authentication process.

  • The password has expired.

  • The password compromise was revealed.

The check is performed if the password has passed other checks in accordance with the current password policy. If any check is disabled, it is skipped. It does not cancel the remaining checks.

See also:

• Infobase parameters (see Infobase parameters).

• Operations with the password compromise check list.

6.2.7. Deleting users

To delete a user, select them in the user list and click Actions - Delete in the User list window.

To confirm user deletion, click Yes when prompted.

6.2.8. Editing user properties

To edit user parameters, click Administration – Users in the Designer menu. Select the user in the list and click Actions – Change in the User list window.

In the User window, you can change parameters of the selected user.

6.2.9. Applying filters

To streamline viewing of the user list, you can use filters. In the user list, click Actions – Set filter…

The list can be filtered based on the role, language, run mode, or user authentication type. If separators (common attributes with Data separation property set to Separate) are enabled, you can also filter users by separators.

6.2.10. Authentication types

6.2.10.1. General information

Authentication is a procedure that verifies whether the provided ID (name) belongs to the user. 1C:Enterprise supports multiple authentication types, which are described in further sections. Not that authentication differs from authorization. Authorization is granting rights to a certain person or group of persons to perform certain actions, as well as confirming these rights when trying to perform this action.

6.2.10.2. 1C:Enterprise authentication (standard authentication)

The user can be authenticated by 1C:Enterprise by providing their username and password (typed in authentication dialog box, passed as command-line parameters, or passed in the infobase connection string for an external connection or automation server). In this case, username and password verification is performed by 1C:Enterprise.

6.2.10.3. Operating system

The user can be authenticated implicitly using the operating system functionality. To enable this authentication type, you need to match the 1C:Enterprise user to an operating system user. On startup, 1C:Enterprise prompts the operating system for information on the currently authenticated OS user. For this purpose, Windows uses the SSPI interface and Linux uses GSS-API. Then, the system checks whether the given operating system user is mapped to a 1C:Enterprise user. If the matching user is found, the 1C:Enterprise user is authenticated and the authentication dialog box is not displayed.

Specify the operating system user as follows: \domain_name\username. The username contains Latin letters only. The format of domain name and username might depend on settings of the domain controller and its accounts. Correct name of the operating system user can be found in the records of CONN event in the technological log. Look for Txt property that starts with Srvr: DstUserName2. For example, the 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) event means that you must specify the OS username in the infobase user description as follows: \d1.d2\user1.

When forced 1C:Enterprise authentication is required, specify /WA- command-line parameter in the startup command line of the client application. The /WA+ command-line parameter forces OS authentication (enabled by default).

See also:

• Technological log (see Technological log).

6.2.10.4. Using OpenID

OpenID (https://openid.net/) is a protocol that allows a user to authenticate in many unrelated resources, systems, and other using a single account. 1C:Enterprise uses a protocol based on OpenID 2.0 under Direct Identity model.

The general procedure is as follows:

• User attempts to sign in to 1C:Enterprise.

• 1C:Enterprise identifies that OpenID authentication is enabled for the infobase using the default.vrd publication file.

• Authentication request is sent to OpenID provider. OpenID provider must be able to receive requests from the address of the infobase publication.

• If an interactive action is needed (for example, the first authentication for this user ID is performed, or the user authentication data has expired), the provider informs 1C:Enterprise that username and password are required. 1C:Enterprise performs the interactive action and returns the requested data to the OpenID provider.

User authentication data is stored in cookie files located in web browser storage. Thin client uses own storage.

• If the provider authenticates the user, a flag is returned to 1C:Enterprise indicating that the user is authenticated.

OpenID authentication only works when the infobase is accessed over HTTP or HTTPS. This means that OpenID authentication is only available for web client, mobile client, and thin client connected to the infobase via the web server. Upon OpenID authentication, there might be cross-domain requests if you use a thin client or Mozilla Firefox, Google Chrome, and Safari.

An OpenID provider can be a 1C:Enterprise infobase published on a server in a special way, or an information system that has OpenID Authentication 2.0 and extension of this protocol implemented on the 1C:Enterprise platform. The address of the OpenID provider is specified in the default.vrd file (<rely> element) when publishing an infobase that is an OpenID provider's client.

It is important to understand that the key field used to match the 1C:Enterprise infobase user and OpenID provider user is a value specified in the Name property of the infobase user. In other words, a user can sign in to the infobase if the Name property in the infobase contains an ID returned by the OpenID provider. For description of an ID to be returned, refer to documentation of the OpenID provider used.

User password is set at the OpenID provider. If a 1C:Enterprise infobase acts as the OpenID provider, the password is set in this infobase. The password set in the infobase that operates as the OpenID provider's client is ignored during OpenID authentication. If a third-party OpenID provider is used, the password is set by this provider. After the user password is changed in the OpenID provider user storage, the 1C:Enterprise follows the following rules:

• User is considered authenticated in any currently running sessions until these sessions are terminated.

• When creating a new session, the user is prompted for the password even if the user authentication data has not expired yet.

When forced OpenID authentication is required, specify /OIDA+ command-line parameter (enabled by default) in the startup command line of the client application. The /OIDA– command-line option is used to forcibly disable the OpenID authentication.

For more information on how to set up OpenID authentication in a web server, see OpenID authentication support settings.

Currently, when authenticating using OpenID, users are not shown a window with a request to change the password in the following cases:

• When the password has expired.

• When the password is about to expire.

• If the password does not meet the requirements during authentication (when the password strength check is enabled).

This is because OpenID authentication does not support these features.

See also:

• OpenID Authentication 2.0 (see https://openid.net/specs/openid-authentication-2_0.html).

• Additional requirements for an OpenID provider (see Requirements for external OpenID providers).

6.2.10.5. Using OpenID Connect

OpenID Connect (https://openid.net/connect/) is a protocol that is an extension of the OAuth 2.0 authorization protocol. OpenID Connect allows 1C:Enterprise to verify user identities based on the authentication by the third-party provider. This protocol is applicable when using thin, mobile or web client. 1C:Enterprise cannot be the OpenID Connect provider. Third-party providers are used for this purpose. OpenID Connect protocol support also means the option to use the Unified System for Identification and Authentication (USIA).

To map 1C:Enterprise users and authentication provider users, the following data is used:

• On the authentication provider side, the email address as a key parameter is used by default. When setting up access to the OpenID Connect provider, you can specify an authentication token field to be used as a key field.

• On 1C:Enterprise side, the key parameter is located in the Name property of the infobase user by default. You can set the OSUser or Email property, as well as a value from the UserMatchingKeys collection as a key field.

If the UserMatchingKeys collection is used for mapping, you can fill it using 1C:Enterprise language only. The code can be as follows:

IBUser = InfobaseUsers.Find(UserCode);

IBUser.UserMatchingKeys.Insert("googleIV", "user-name@google.com");

IBUser.Write()

The UserMatchingKeys collection element is used if the provider list in the default.vrd file contains a description of a provider whose name property is equal to the googleIV value. The user who is identified by the UserCode variable value will be used upon session startup if the mapping field value from the token returned by the OpenID Connect provider is user-name@google.com. See the googleIV provider details in the example for the openidconnect.providers element of the default.vrd file.

OpenID Connect authentication (including USIA) is supported in a separated infobase. Separator values will be used to correctly identify the authenticated user. However, for separator values to be used in the system, you may need to additionally set up the default.vrd file (the redirect_uri parameter in the provider description).

So far as a mobile client is concerned, authentication is provided using a web browser supported by a mobile device:

• Android: Google Chrome.

• iOS: version 9.0 or later.

If your mobile device is not in compliance with the requirements above, you might need to authenticate again on the side of OpenID Connect provider in a mobile client. To start forced authentication when you sign in next time, run Log out command in the mobile client.

See also:

• OpenID Connect operations.

• default.vrd file details.

6.2.10.6. Using JWT

Token is a tool to authenticate a user or a separate session in the application. JSON Web Token (JWT) is a standard for access token creation based on JSON format. JWT is described in the RFC 7519 standard (https://datatracker.ietf.org/doc/html/rfc7519). JWT is used for user authentication in client/server applications.

JWT authentication is available only in infobases that are published on the web server. To specify JWT, use the AccessToken command of the client application startup command-line.

A published infobase must be configured in a certain way. To set up a publication, use the default.vrd file.

To authenticate in the selected infobase using JWT:

1. Publish the infobase on the web server.

2. Specify the Access token authentication property.

3. In the default.vrd file of the published infobase, generate the accessTokenAuthentication element with the correct parameters. Note that:

   • If you search for a user by the field whose name is different from the infobase user, specify the authenticationUserPropertyName attribute value of the issuer element.

   • The name attribute of the issuer element.

   • The accessTokenRecipientName subordinate element must contain a unique application name that will be used during JWT generation.

4. Using the AccessToken object, create an access token for each user. In this token:

   • Set the value of the Issuer property to the name attribute value of the issuer element. The iss payload claim will be generated.

   • Add the value that is specified in the accessTokenRecipientName element of the default.vrd file to the list of recipients. The aud payload claim will be generated.

   • Depending on the value specified in the default.vrd file in the authenticationUserPropertyName attribute of the issuer element, the UserMatchingKey property must contain the value of the key field for the required user. The sub payload claim will be generated.

   • Fill the rest of the token parameters and get its string presentation.

5. Pass the token string value to a specific user to specify as a value of the AccessToken parameter when starting the client application.

See also:

• JWT operation description.

• default.vrd file.

6.2.10.7. Using QR code

When using a QR code, the following bundle is used: a mobile application (mobile client) in which the user is authenticated and another client application that the same user wants to use to access the same infobase. It works as follows: if the user wants to authenticate in the infobase, they use a mobile application to scan the QR code displayed in the client application. To successfully perform the operation, the user trying to sign-in in another client application must already be authenticated in the same infobase in the mobile application.

This authentication is possible only if the infobase is published on a web server and configured in the required way. To set up a publication, use the default.vrd file.

QR code authentication is divided into two steps:

• The required mobile application is missing on the mobile device.

• The required mobile application is installed on the mobile device.

Let's look at each of these steps in more detail:

• The required mobile application is missing on the mobile device:

  • The user tries to sign in the infobase and selects the QR code authentication in the authentication dialog box.

  • The client application displays a QR code that needs to be scanned by a mobile device.

  • The user uses any available QR code scanning application to scan the QR code. After that, they follow the URL encoded in the code.

  • After following the link, the application displays links to mobile applications that can be used to access this infobase on different mobile operating systems. To configure the list of applications, use the <mobileApps> element in the default.vrd file.

  • The user selects and installs the required mobile application.

  • The user proceeds to the step when the required mobile application is installed on the mobile device.

• The required mobile application is installed on the mobile device:

  • The user uses the mobile application to access the required infobase.

  • The user wants to access the same infobase from another device. To do this, they start the client application on another device and select the QR code authentication in the authentication dialog box.

  • In the mobile application, the user selects Main menu – Settings and service – Sign in on another device and scans the QR code provided by the infobase on another device.

  • The infobase authenticates a new user session.

In this case, that authentication is confirmed by owning a mobile device with a mobile application in which the user is authenticated.

See also:

• default.vrd file.

6.2.10.8. By email

Email authentication is a type of password-free authentication. To authenticate via email, select this type of authentication in the user selection dialog box and then enter the email address specified when the user was created. The system will send an email message containing a verification code to the specified address.

Enter the verification code into the form that will open after the system sends an email with the code. If the code is entered correctly, the user is authenticated.

For email authentication to work, perform two actions:

• You can configure such authentication in the Additional authentication settings dialog box.

• Enable email authentication for the user.

Please note that email authentication is not supported for parameterized launch mode and when disabling startup dialog boxes during client application launch.

See also:

• User profile settings.

• User selection dialog box.

• Additional authentication settings.

6.2.10.9. Two-factor authentication

6.2.10.9.1. General information

The platform can perform user authentication independently, or it can use the results of authentication performed by another resource that it trusts (operating system or OpenID provider). In any case, the user enters a username and a password. If the correct username/password pair is entered, the platform considers that the user is identified and grants them access to the application.

This conventional scheme is simple and convenient, but has one significant drawback. You need to remember the password, and it must be short and simple for that. But such password is easy to hack. For a password to be difficult to hack, it must be long and complex. But such password is not easy to remember. For this reason, in reality it all comes down to people using simple and the same passwords for different resources.

Two-factor authentication is a method that allows you, on the one hand, to complicate access to user data for hackers, and, on the other hand, it is a solution that mitigates the disadvantages of classic password protection to some extent.

Two-factor authentication requires the user to have two of the three possible types of authentication data:

• Something they know and remember. This is the username and password.

• Something they own. This can be a user cell phone or email.

• Something inherent to them. This can be a physical feature of the user, such as a fingerprint, a portrait, or an iris pattern.

The point of two-factor authentication is that the user must double-confirm their identity to get access to the application. Moreover, they need to do that in different ways. For example, entering the username and password will be the first authentication factor and entering the code sent to the cell phone will be the second authentication factor.

The verification of the first authentication factor is performed by 1C:Enterprise platform itself, and a third-party service, which is called the second factor provider, is used to process the second authentication factor.

Second factor provider (also called "provider" in this section) is an HTTP service that provides API for performing certain actions. A 1C:Enterprise infobase can act as the second factor provider if a set of HTTP services for forwarding messages and performing authentication is implemented in the infobase. It can be a third-party service that sends SMS or e-mail messages, it can be a service that generates codes of the second authentication factor or a service that interacts with the user through its own mobile application, and so on. All that matters is that the provider can be accessed via HTTP requests.

You can use the two-factor authentication only for authentication with 1C:Enterprise tools (standard authentication) in any infobase mode and for any client application.

See also:

• 1C:Enterprise authentication (see 1C:Enterprise authentication).

6.2.10.9.2. Options for using the second factor

So, the standard 1C:Enterprise authentication (the first factor) is as follows:

• The user starts the client application. The client application asks the user for the first authentication factor: the username and password. The user enters the username and password, and the client application sends them to the server.

• Server checks the username and password for correctness.

• If the data entered is correct, the server checks that the user needs only one authentication factor to use the application. If the second factor is not used, it is considered that the user is fully identified and can start operations. This is a common authentication scenario.

If two-factor authentication is set for the user, the first two steps are performed as before: the user enters the username and password, and the 1C:Enterprise server checks this data.

The use of the second factor can be performed in two ways:

• 1C:Enterprise server itself generates a second factor and checks if the user correctly entered the value of this factor. The provider only performs the transport function. It transmits the second factor value to the user. In this case, both 1C:Enterprise server and the user know the channel used to transmit the second factor value.

The procedure is as follows:

• 1C:Enterprise server informs the application that the user needs to specify a second authentication factor.

• Application displays the second factor input form.

• 1C:Enterprise server generates and sends the value of the second factor (for example, a certain number) to the user. The user must enter this value in the form opened by the application. The second factor value can be sent to the user by e-mail or SMS.

• User receives the second factor data and enters it in the dialog box opened by the application. The application sends the second factor data to 1C:Enterprise server.

• 1C:Enterprise server verifies that the entered data matches the data generated and sent to the user by the server.

• If the second factor value transmitted by the application and the one generated by the 1C:Enterprise server match, the user is identified and granted access to the application.

• 1C:Enterprise server uses a third-party service that sends the result of applying the second factor by the user to 1C:Enterprise server. In this case, 1C:Enterprise server has no information on the type of the used second factor. The method for transmitting the second factor is also determined by the selected second factor provider. The 1C:Enterprise server only has information that there is a trusted service that in response to the requirement to use the second authentication factor informs whether the second factor is applied successfully or not.

The procedure is as follows:

• 1C:Enterprise server informs the client application that the user must authenticate the second factor on the provider side.

• Client application shows the form to the user, where the user must perform a certain action after being authenticated by the second factor provider.

• Server sends an HTTP request to the provider with a request to authenticate the user.

• Provider begins the authentication procedure. The authentication method is at the discretion of the provider.

• After the authentication procedure is completed, the user reports this to the client application.

• Client application passes this information to 1C:Enterprise server, which requests the second factor provider for authentication results.

• Provider reports the authentication result to the server. If authentication is successful, the user is considered identified and they are granted access to the application.

Each method reviewed in this section has a certain support from the 1C:Enterprise application. Setting of the second authentication factor is reviewed in the next section.

6.2.10.9.3. Second factor setting

Setting of using the second factor in 1C:Enterprise is divided into several parts:

• Configuring templates of requests that are sent to providers.

• Binding a request template to an infobase user.

• Requests parameterization.

Let's take a closer look at each part.

To describe the HTTP request to be sent to the provider, the SecondAuthenticationFactorSettingTemplate object is used. One of the options of the second authentication factor is selected while setting the template parameters. If it is necessary to implement the first option of the second authentication factor (1C:Enterprise server generates, sends and checks the second factor value), the AuthenticationHTTPRequest and the AuthenticationHTTPRequestMethod properties are used. The first property contains description of the HTTP request (an object of the HTTPRequest type), and the second parameter allows you to specify which HTTP method will be used to request the second authentication factor to the provider.

If it is necessary to implement the second authentication option (the 1C:Enterprise server only initiates authentication in the second factor provider and receives its result), the parameters reviewed above remain. They are used for the second authentication factor. To check the authentication result, use the following additional properties: AuthenticationResultVerificationHTTPRequest and AuthenticationResultVerificationHTTPRequestMethod.

Each template has its own name (property of the same name), which allows you to identify the template when performing further actions.

When creating an HTTP request for setting any property, keep in mind the following features:

• HTTP method is specified as a string. This is because the HTTP specification allows usage of custom verbs (methods).

• Request text may contain parameters. A parameter is a text starting with the "&" character. For example, you can use the & user_name parameter to specify a username. These parameters will be replaced with real values at the time of sending the request (will be reviewed below). The reason for this decision is the assumption that the HTTP requests of the second authentication factor for different users will be almost the same. Differences will be observed only in some information that is specific to a particular user. For example, a conditional request to send a text message with the second factor code looks as follows: http://provider.example.com/sendsms/&phone_number. When sending a request, replace the &phone_number parameter with the user's actual phone number.

The platform provides the predefined &secret variable, which contains the value of the second factor generated by the platform.

Having all the information, let's look at an example of creating a template for working with the second factor according to the first option (the platform generates, sends, provides input and verification of the second factor):

Request = New HTTPRequest;

Request.Resource Address = "&addr";

Request: SetBodyFromString ("Enter the & secret value. Do not tell this value to anyone!", "utf-8");

Provider = SecondAuthenticationFactorSettingsTemplates.CreateTemplate();

Provider.AuthenticationHTTPRequest = Request;

Provider.AuthenticationHTTPRequestMethod = "POST";

Provider.Name = "Request - response";

Provider.Record();

The first three strings form the HTTP request that will be used by the platform. The remaining strings create the template of the second factor provider, which will send the request using the POST method and have the Request - response name.

If it is necessary to create a template for the second factor provider used according to the second option (all actions are performed by the provider, the platform only initiates the operation start and requests the authentication result), then the above example is to be changed in such a way that:

• Authentication request meets the requirements of the provider used.

• Request to check the authentication results is created and set in the template. This request will be made after the user "informs" the client application that they passed authentication at the provider.

After saving one or several templates for providers, you can assign one of the templates to the user. Keep in mind that you can assign multiple templates to one user and specify how they will be processed.

To set up user settings, two properties of the InfobaseUser object are used:

• SecondAuthenticationFactorSetting. Here you need to assign an array of objects of the SecondAuthenticationFactorSetting type.

• SecondAuthenticationFactorSettingsProcessing. Describes what the platform will do if several second factor providers are specified and the first (in the traversal order) provider returns an error.

After specifying the above properties, the object describing the infobase user is to be recorded.

The last point to consider is where the platform will get the values that will replace the variables in HTTP requests. For this, let's have a look at the SecondAuthenticationFactorSetting object. This object contains two fields:

• SettingTemplateName. In this field, specify the name of the template of the second factor provider setting, which was specified in the Name property when setting the provider template.

• Parameters. You need to assign a match to this property. The map must contain as many items as there are parameters in the template of the second factor provider setting (excluding the &secret parameter). A parameter name (without the "&" character) acts as a map item key, and a variable value is a value.

Now we have all the information we need to indicate to the infobase user that two-factor authentication is required when signing in to the infobase.

ProviderParameters = New Map;

ProviderParameters.Insert("addr", "http://example.com/resource");

UserSetting = New SecondAuthenticationFactorSetting;

UserSetting.SettingTemplateName = "Question - answer";

UserSetting.Parameters = ProviderParameters;

UserSettings = New Array;

UserSettings.Add(UserSetting);

User = InfobaseUsers.FindByName("Seller");

User.SecondAuthenticationFactorSettings = UserSettings;

User.SecondAuthenticationFactorSettingsProcessing = SecondAuthenticationFactorSettingsProcessingType.UseNextIfFailed;

User.Record();

The platform will replace parameter names with the actual values in the following properties:

• HTTPRequest.ResourceAddress property.

• HTTPRequest.Headers property.

• HTTPRequest object request body. The method of specifying the request body does not affect the substitution.

• SecondAuthenticationFactorSettingTemplate.AuthenticationHTTPRequestMethod property.

• SecondAuthenticationFactorSettingTemplate.AuthenticationResultVerificationHTTPRequestMethod property.

Note that if the second factor provider selected for the user is "broken", the user cannot get access to the infobase. In this case, the term "broken" means any event that does not allow the provider to complete its task: no Internet connection for access from the server to the provider, no Internet connection for access from the provider to the user, an error on the provider side, and so on.

It is also necessary to understand that if you plan to use a third-party provider of the second factor, then the services of this provider may be paid and the provider may put forward additional conditions and restrictions that lie outside the 1C:Enterprise system and are not considered in this documentation.

6.2.10.9.4. OpenID Authentication and two-factor authentication

1C:Enterprise supports authentication using the OpenID protocol. If the information system uses OpenID authentication, the second factor is to be requested by the OpenID provider. This is true as well if a 1C:Enterprise infobase is specified as an OpenID provider. In other words, two-factor authentication must be configured in the infobase that is the OpenID provider.

6.2.10.10. Use of biometrics to log in through a mobile client

So far as devices which support biometric authentication (i.e. they have a fingerprint sensor, face or iris scanner, and so on) are concerned, Use biometrics check box is available in a mobile client infobase setting and authentication (on a mobile device) dialog boxes. Whenever this check box is checked, the following mechanism is activated:

• When you sign in for the first time, usernames and passwords you enter for the infobase and authentication using OpenID and web server are stored in a secure storage.

• The next time you sign in, the following logic is implemented:

  • First, an attempt to sign in is made without using data available in a secure storage to verify that authentication is not currently required or there is relevant authentication data disclosed by OpenID provider. If a mobile device stores relevant authentication data, a request to provide biometric data for authentication purposes is made only when authentication data life cycle expires.

  • If the previous step failed, a user is prompted to undergo biometric authentication using a mobile operating system interface. The authentication type specified in mobile device user settings is requested.

  • If biometric authentication is abandoned by a user, the standard authentication dialog box with the username and password is displayed.

  • If biometric data is accepted by the mobile device, data saved during prior successful authentication is recovered from the secure storage. The said data is used for authentication purposes.

  • If this data is not accepted by a mobile device, data saved during prior successful authentication is deleted from the secure storage. Then, the standard authentication dialog box with username and password is displayed.

• No biometric data is used if authentication is made through OpenID Connect as in this scenario a protected web page of OpenID Connect provider is used to perform authentication. On this page, the previously saved username and password for this provider cannot be inserted automatically. Moreover, OpenID Connect supports repeated authentication on this device without any time limit for entering username and password.

If your mobile device supports authentication through OpenID Connect, this method is used for authentication purposes. Whenever authentication through OpenID Connect is abandoned, you can sign in fast using biometric data. To attempt to re-use OpenID Connect authentication, an unsuccessful login attempt must occur.

6.2.11. Users and extensions

If the infobase user is assigned with native roles from the extension, the user is marked in the list with a special icon.

Roles that are present in the extensions connected to the infobase are available in the list of roles that can be assigned to the user. Extension roles are located at the end of the role list in the extensible configuration. You can mark or unmark extension roles.

6.3. Active users list

Sometimes you need to find out which users are connected to the infobase at the moment.

To get the list of active users, click Administration – Active users. A window with a list of users who currently use the database will open.

The current line displays data of the user who opened the form (current session). The current user is marked in the list with an icon. Data separation column specifies details of separators which are specified for a user in Designer (see Data separation tab in user properties). There are no values disclosed in this column for separators which apply to a specific session when a form is opened.

Using the Actions menu, you can customize appearance of the list or export it to a spreadsheet or text document. The list of active users can be sorted by any column.

6.4. Session operations

6.4.1. External session management

When you use information systems, you might face some situations when you need to manage the capability to create a new session with infobases:

• Restrict the number of concurrent infobase users.

• Ensure a guaranteed reserve of licenses when working with an infobase. For example, with 100 licenses available, to provide guaranteed access to the infobase for two users with particular names.

• Perform other similar tasks.

The external session management feature is designed to address these problems. The feature requires a dedicated web service that allows or prohibits session creation. The feature operates both with client/server and file infobases. File infobase operation is supported if all the following conditions are met:

• 1C:Enterprise client application version 8.3.22 or later.

• External session management web service version 4 or later.

The feature operates as follows:

• When the system attempts to start a session, 1C:Enterprise notifies the web service that a session needs to be created and provides the web service with a set of parameters that define all characteristics of the session to be created (infobase name, username, client application IP address, and so on).

• The web service decides whether to allow session creation and returns control to the calling party. If required, the web service can keep records of created sessions broken down by requested sections.

• At the end of the session, 1C:Enterprise notifies the web service that the session is ending.

• If the session enters or leaves the Hibernating state, 1C:Enterprise notifies the web service of this event. This feature is available only if you use the web service that supports the operation protocol of version 2 or later.

The external session management service possesses exact information on the current number of open sessions in infobases under its control and can make appropriate decisions.

The external session management service is only called for the sessions that require a client license:

• Designer

• Thick client

• External connection

• Thin client

• Web client

• Mobile client

• 1C:Analytics client

When you start other session kinds, the external session management service is not called.

To set up the external session management service, use the following:

• In the file infobase, the conf.cfg configuration file.

• In the server infobase, server cluster infobase properties.

For details on the web service of external session management, see External session management web service.

6.4.2. Session start lock

6.4.2.1. Manually, for all

Interactive method

1C:Enterprise allows you to prohibit users from creating new sessions with the infobase. In this case, when users attempt to access the infobase, an error message with the reason for prohibition is displayed. This capability can be useful when, for example, you need all current users to close their sessions and make sure that no new users can connect to the infobase.

When using client/server mode, you can enable this lock with the administration utility of the 1C:Enterprise server cluster.

To connect to the infobase regardless of the lock, use the UC command-line parameter and the UC connection string parameter. If a non-empty access code is specified for the lock, enter this code in the UC parameter to bypass the lock and connect to the infobase. If the access code contains spaces, you need to enclose it in quotes.

When using a web client or a thin client running via a web server, you can also specify the access code in the UC connection string parameter of a descriptor file. In this case, additional publication of the infobase on a web server is recommended.

When the session start lock is set and the access code is set to 123, you need to enter /UC123 in the client application startup command line in order to bypass the lock.

Software method

In any infobase mode, you can enable session start lock using 1C:Enterprise language. The SessionsLock object of the 1C:Enterprise language is used for this purpose. You can create it in constructor and configure the required properties for locking new connections. You can specify a message to display to a user (using the SessionsLock.Message property) as a simple text string or a formatted string.

The SetSessionLock() global context method enables the lock, and the GetSessionsLock() method gets the enabled lock.

6.4.2.2. By default, when password is under attack

Password attack is one of the methods which can be used to be granted unauthorized access to infobase data. In this scenario, a malicious user tries to hack a password using a pre-defined algorithm, until it is cracked and a password for a selected user becomes available thereto. To avoid the said manipulations, 1C:Enterprise supports a dedicated mechanism available in the infobase client/server mode only.

An administrator manages this feature by configuring the following infobase parameters (to open the dialog box, go to Main menu – Administration – Infobase parameters):

• Maximum number of failed authentication attempts. Defines the number of attempts allowed to be made by a user to enter their password before access is blocked. Access is blocked as soon as the aggregate number of consecutive unsuccessful attempts to authenticate becomes equal to N, where N is the parameter value. In other words, if this parameter is equal to 3, a user will be blocked as soon as their third attempt to authenticate fails. The user will be notified about blocking after N+1 authentication attempt.

If this parameter is set to 0, the feature is disabled and the platform does not monitor the number of failed authentication attempts.

• Lock duration on exceeding the maximum number of failed authentication attempts (in seconds). Defines the time period when a user is unable to authenticate if they attempt to enter a wrong password in excess of the number of attempts specified in the Maximum number of failed authentication attempts parameter.

• User name add-on codes when authentication is blocked. Allows you to block authentication attempts made by the already blocked user. Add-on codes are separated by ";". In this case, a username is generated based on the name of the blocked user and one of the add-on codes. A user with username generated with the help of add-on codes has as many authentication attempts as an ordinary user. As soon as all available attempts to authenticate are made, the said "extra" user is blocked as well.

This feature works as follows:

• Malicious user enters a username and attempts to hack a password by entering a password expected to be a valid password of a user. As soon as the aggregate number of failed attempts to authenticate is exceeded, the username entered by a malicious user is blocked.

• If the blocked user attempts to sign in using their name and password, a warning is displayed specifying that the user is blocked.

• Whenever add-on codes are specified in an infobase, these can be used by a user. To do it, the user must enter their name with an add-on code. When you use add-on codes, consider that an add-on code is analyzed only if the specified username is not included in the list of infobase users. Username add-on codes specified in the settings are successively subtracted from a username. Then, it is checked whether an infobase user with such name is available in the infobase or not. Therefore, we recommend that you avoid creating add-on codes that are similar to the end of an existing username. If such a user is blocked using the block feature, they will not be able to sign in using add-on codes. Moreover, we recommend that you start each add-on code with the so-called "technical" characters, which are unavailable in the username, for instance, "!", "^", and so on.

To view a list of blocked users, in Designer, click Main menu – Administration – Blocked authentication. This form is available to each user with the Administration or DataAdministration rights assigned. Information about blocked users is available in the event log.

Data about blocked users is stored by the auxiliary cluster function service. It means that:

• If a single administrator is blocked, to sign in using their username, reload the server cluster.

• Unsuccessful sign-in attempts are counted from the last successful sign-in without any time limitation. However, when you reload the server cluster, all counters for all infobase users are reset.

To manage the block feature, use the AuthenticationBlock global context object. Use this object to change settings of the feature (GetSettings() and SetSettings() methods). Moreover, a list of current blocks can be displayed using the GetBlocks() method.

In 1C:Enterprise language, you can force unblock all or certain blocked users. For that purpose, get a list of current blocks displayed as the InfoBaseUserAuthenticationLock object array. Then, define the list of users to unblock (based on the InfoBaseUserAuthenticationLock object properties). Call the Unlock() method of this object for the selected blocked users.

6.4.3. Idle session termination

It may be required to disable users who do not perform any actions in their infobase for a certain period of time. You may need it to effectively use licenses or to reduce the likelihood of unauthorized access to the infobase data. The 1C:Enterprise platform allows terminating an infobase session when the user is inactive.

For this, specify two parameter values in the list of infobase parameters:

• Idle session termination timeout This parameter allows you to specify the time interval after which the session will be terminated if the user is inactive.

• Time before warning about idle session termination. This parameter specifies the time interval after which the user is notified that their session will be automatically terminated if they do not resume operations in the session.

These parameters are used only with client sessions in the following applications: thin client, thick client, mobile client, and mobile application. You cannot terminate Designer sessions this way.

Depending on the client application type, "user activity" refers to:

• Thin and thick clients: keystrokes, mouse movements in the application window, and participation in Collaboration system videoconferences.

• Mobile client and mobile application: pressing on-screen buttons, scrolling forms, and touching various parts of forms.

The inactivity warning dialog box displays a countdown timer, after which the session will be terminated. The application will not be terminated. The dialog box will be displayed on the screen with information that the session is terminated due to user inactivity and a suggestion to shut down or restart the client application.

We do not recommend that you enable both saving authentication and idle session termination if idle session termination is enabled to minimize the risk of unauthorized data access. In this case, forced session termination will not protect against unauthorized access, as an attacker can still get access to the infobase using saved authentication credentials.

See also:

• Infobase parameters.

• Saving authentication.

6.5. Regional infobase settings

Regional infobase settings affect the format of date, time, numbers, logical constants, as well as string order in infobase lists. To start this mode, click Administration – Regional infobase settings.

If a property is not set, the default 1C:Enterprise settings for numbers, dates, and time for the specified language (country) will be used. Language (country) is specified during infobase creation.

Language (Country). Select the language (country) for this infobase.

First day of the week property is used to specify what day of the week is considered the first day of the week in the country. If you set this property to Auto, the first day of the week is chosen based on the country specified in Language (Country) property. For example, if you choose English language, Sunday will be set as the first day of the week, and if you choose Arabic, Saturday will be the first day. Any day of the week can be chosen as the first day of the week.

In infobases created with 1C:Enterprise 8.3.6 or older, the value of the first day of the week is not stored in the infobase. If compatibility with 8.3.6 and earlier versions is enabled for an application deployed in this infobase, Monday will be used as the first day of the week (and you will not be able to change this value). If the compatibility mode is set to Not used for this infobase (or compatibility version is earlier than 8.3.6), the first day of the week will be selected according to Language (Country) property. The First day of the week property is assumed to be set to Auto.

In infobases created with 1C:Enterprise 8.3.7 or later, the value of the first weekday is stored in the infobase. When creating an infobase, the First day of the week property is set to Auto. The value of this property can be changed; the changed value is stored in the infobase. Setting the mode for compatibility with 8.3.6 and later will make Monday the first day of the week and the First day of the week property will be uneditable. However, the actual settings will be saved and will become effective after setting the compatibility mode to Do not use (or if the compatibility version is later than 8.3.6). If you edit regional settings in 1C:Enterprise 8.3.6 and later, the value of First day of the week property will be cleared.

If the Use regional setting of the current session property is set, the values similar to Number and Date are displayed (including input fields, calendar, and calculator) according to regional settings of a current session. These settings are determined based on the regional settings of a client computer, but can be re-configured using the /VL command-line parameter.

In the lower part of the dialog box, examples of number, date and time formats for the selected regional settings are displayed.

Values of Boolean type are displayed in accordance with the interface language. This can be set using the /L parameter.

Decimal separator. You can choose a separator between integer and fractional parts of a number from the drop-down list, or type it in the input field. An example is displayed to the left of the input field.

Digit group separator. You can choose a separator of digit groups in a number from the drop-down list, or type it in the input field. An example is displayed to the left of the input field.

Grouping. This property sets the format for digit grouping in the integer part of a number. You can choose the format string from the drop-down list, or enter it manually. The grouping format is: <A><separator><B>. Any character can be used as a separator, except digits. A format string allows you to set one or two digit groups counting from right to left. Each character (A and B) specifies the number of digits in its group.

Consider an example of format strings for number 987654321, where a group separator is the character "/". The description also goes from right to left:

• Grouping – 3,2, presentation – 98/76/54/321:

  • First group includes the first 3 digits.

  • It is followed by the group separator specified in OS settings or in Group separator property.

  • All other digits are grouped by twos.

• Grouping – 3,0, presentation – 987/654/321:

  • Each group contains 3 digits.

  • Groups are separated by a separator character.

• Grouping – 4, presentation – 98765/4321:

  • First group includes 4 digits.

  • Groups are separated by a separator character.

  • Remaining digits are not grouped or separated.

Negative number format. You can choose the negative numbers format from the drop-down list. If you select Auto, negative numbers format is defined by the operating system settings.

Date format. Specifies the date format. You can use the following characters in different combinations:

The above mentioned characters and groups of characters can be entered in any sequence. You can specify the separators for day, month, and year.

Time format. Specifies the time format. You can use the following characters in different combinations:

The above mentioned characters and groups of characters can be entered in any sequence. You can specify the separator characters to separate hours, minutes, and seconds.

False. True. Specifies logical constants. You can choose these from the drop-down list, or enter manually.

See also:

• Converting values ​​to a string and back.

6.6. Infobase parameters

6.6.1. General information

Infobase parameter settings allow you to specify the following set of parameters:

• Authentication parameters

• User password requirements

• Data lock timeout

• Passive session operation parameters

• Number of totals recalculation jobs

• Mobile client signature behavior

These parameters are located in the Infobase parameters dialog box in Main menu – Administration – Infobase parameters.

6.6.2. Authentication tab

This tab is used to configure user authentication parameters.

Authentication parameters are divided into two groups: general parameters and parameters described by the password policy.

General parameters of the "Authentication" group are:

The maximum number of failed authentication attempts

For details on the parameter, see By default, when password is under attack.

Lock duration on exceeding the maximum number of failed authentication attempts (in seconds)

For details on the parameter, see By default, when password is under attack.

Username add-on codes used when authentication is blocked

For details on the parameter, see By default, when password is under attack.

User password hashing algorithm

User passwords are stored in the infobase not in an open format, but as a result of a hash function that prevents the original password recovery. As a result, even after gaining access to the list of infobase users, the attacker will not be able to see the passwords explicitly. The platform supports several hash functions (hashing algorithms) that can be used to hash passwords: SHA-1, SHA-256, SHA-512, and PBKDF2-SHA256. When selecting a hash function for passwords, consider the following:

• If it is necessary that users can access the infobase from any 1C:Enterprise system version, use the SHA-1 algorithm.

• If the infobase will be accessed from 1C:Enterprise system version 8.3.26 or later, you can use any hash function. All the following comments are significant only when the infobase is accessed from version 8.3.26 or later.

• To make it as difficult as possible to brute force a password, use the PBKDF2–SHA256 algorithm, while additionally protecting the infobase from DOS/DDOS attacks (denied of service). This recommendation is based on the fact that the PBKDF2-SHA256 algorithm is approximately 2,000 times slower than the SHA-1 algorithm. If you try to guess a password using numerous connections, you will force the 1C:Enterprise server cluster to only calculate password hash function values to check whether the authentication is possible.

• If we take the speed of the SHA-1 algorithm as 1, the SHA-256 algorithm's speed is 2*SHA-1, the SHA-512 algorithm's speed is 3*SHA-1, and the PBKDF2-SHA256 algorithm's speed is 1915*SHA-1.

To change the password hashing algorithm of the infobase, you can use one of the dialog boxes for interactive configuration of infobase parameters (in Designer or from standard functions) or use the GetUserPasswordHashAlgorithmType()/SetUserPasswordHashAlgorithmType() global context methods. To identify what hash function is used for a password of a particular infobase user, use the InfoBaseUser.PasswordHashAlgorithmType property. For all hashing algorithms except for SHA-1, "salt" is added to each password during hashing. "Salt" is an arbitrary and random string of data that is added to the hashed password to eliminate the situation when the same hash is generated for one set of input data (password). The "salt" changes with each password change and for each user.

To change the password hashing algorithm, use the following sequence of actions:

• The administrator changes the password hashing algorithm using one of the available methods.

• The administrator terminates all active sessions of infobase users for all users to go through the authentication procedure again.

• During authentication, a user re-enters their password, which is hashed using a completely new algorithm. A new hash function value is written to the corresponding InfoBaseUser object (with the new hash function algorithm).

• After some time, for example, 1 month, the administrator can check users who still have the password hashing algorithm that was before the algorithm was changed, and force these users to change passwords and send new passwords by email. You can do this using 1C:Enterprise language.

If some infobase users have the remembered authentication parameters, after changing the hash function, all issued tokens will become invalid, and these users will need to authenticate again with the Remember checkbox.

The Password requirements group describes a set of parameters that you can apply for the entire infobase and for certain users.

See also:

• Infobase user parameters (see Adding new users).

• User password policies (see Password policy).

• Infobase user authentication (see User authentication).

6.6.3. Additional tab

This tab contains the parameters for operating with the infobase and configuring the Designer behavior when operating with a mobile client signature.

Data lock timeout (in seconds)

Determines the maximum waiting time before the transaction lock is set by the database server. For example, when the current transaction needs to set lock on a database record but the record is already locked by another transaction, the current transaction will wait until the lock is released or the number of seconds specified in this parameter passed. The parameter also determines transaction lock timeout in 1C:Enterprise managed lock mode.

Changing this parameter (using this dialog box or 1C:Enterprise language) requires administrative rights and enables exclusive mode for infobase access.

Changes of the data lock timeout value become effective immediately for all databases except IBM DB2. In IBM DB2, you need to restart the database after the data lock timeout value is changed.

To access using 1C:Enterprise language, you can use the GetLockWaitTime()/SetLockWaitTime() methods.

Passive session hibernation timeout (in seconds)

A session that has no activity within the specified time becomes Hibernating.

Before the user is authenticated, the session state changes to Hibernating after 20 seconds of the client application inactivity.

To access using 1C:Enterprise language, you can use the GetPassiveSessionHibernateTime()/SetPassiveSessionHibernateTime() methods.

Hibernating session termination timeout (in seconds)

The hibernating session is terminated after the specified period of time.

Before the user is authenticated, the hibernating session is deleted after 20 minutes.

To access using 1C:Enterprise language, you can use the GetHibernateSessionTerminateTime()/SetHibernateSessionTerminateTime() methods.

Number of totals recalculation jobs

Defines the number of system background jobs used to recalculate register totals upon infobase restructuring or testing and introducing respective patches. The default value is 4. It means that to recalculate totals, 4 background jobs are started at the same time. This parameter is applicable in infobase client/server mode only.

Time before warning about idle session termination (in seconds)

If there is no activity in the user session, a dialog box with information that the session will be terminated will be displayed after the specified time interval. In the dialog box, you can select not to end the session. If the value is 0, the warning is not displayed.

To access using 1C:Enterprise language, use the GetInactivityTimeForTerminateSessionNotification()/SetInactivityTimeForTerminateSessionNotification() methods.

For more information on the automatic session termination, see Idle session termination.

Idle session termination timeout (in seconds)

A user session with no activity will be terminated after the specified time interval. If the value is 0, the user session is not terminated.

To access using 1C:Enterprise language, use the GetInactivityTimeForTerminateSession()/SetInactivityTimeForTerminateSession() methods.

For more information on the automatic session termination, see Idle session termination.

Use additional indexes

Enables additional indexes in the infobase.

To access using 1C:Enterprise language, use the SetAdditionalIndexesUsage()/GetAdditionalIndexesUsage() methods.

6.6.4. Parameters available only using 1C:Enterprise language

Some infobase parameters can be changed and received only using 1C:Enterprise language. Such parameters include:

• Infobase time zone: GetInfoBaseTimeZone()/SetInfoBaseTimeZone().

• First year of the century: GetInfoBaseBeginningOfCentury()/SetInfoBaseBeginningOfCentury()/SessionBeginningOfCentury().

The parameter is used if it is necessary to define the whole year of the date from the last two digits. When the first year of the century is set to "1950" (the default value), then the numbers of the year "49" will correspond to the year "2049", and the numbers of the year "50" will correspond to the year "1950".

If you set infobase parameters in a transaction, the method of getting the parameter will return:

• In current session:

  • Before transaction end: the latest value.

  • After transaction commitment: the latest value.

  • After transaction rollback: the value as of transaction start.

• In another session:

  • Outside the transaction in record-locking DBMS (Microsoft SQL Server, IBM DB2): the latest value, not later than 20 seconds after the value is set. After transaction rollback: the value as of transaction start, not later than 20 seconds after the rollback.

  • In the transaction and for versioned DBMS (file mode, PostgreSQL, Oracle Database): the latest value, not later than 20 seconds after committing the transaction where the value was set.

In the client/server mode, when the parameter value is set from the thick client side, the change is immediately visible at the server side, and vice versa.

6.7. Dumping an infobase to a file

An infobase can be saved to a file on hard drive. To save the infobase data to a file, click Administration – Dump infobase. This will open the standard file selection dialog box. Select a directory and specify the name of infobase data dump file.

The export file will contain all the infobase data, as well as data of all connected binary data storages. Binary data storage data will be included in the export if the export is performed from a client/server infobase, and a binary data storage is created for this infobase.

The export functionality allows you to:

• Obtain an infobase image regardless of the data storage method.

• Transfer an infobase between DBMS's or file modes.

Before exporting the infobase, it is recommended that you test it using Designer or a third-party utility, and fix all the issues found.

It is recommended that you do not use this method to create infobase backups because:

• Export file may be impossible to load if the exported infobase contains errors.

• Export procedure takes a long time.

• Export procedure requires exclusive mode.

• Export procedure has high RAM requirements.

See also:

• Binary data storage.

6.8. Importing infobases from file

To restore an infobase from a file, click Administration – Restore infobase.

This will open the standard file selection dialog box. Select a directory and specify the name of the infobase data dump file.

When restoring the infobase from a file, you need to ensure that free disk space (for temporary files) approximately equal to the expanded size of the infobase is available:

• For file mode: on the computer where the infobase restoration is performed.

• For client/server mode: on the computer hosting the 1C:Enterprise server.

The size of the resulting database may be several times larger than the size of the .dt data dump file.

To speed up the infobase import when using Microsoft SQL Server, set the recovery mode for the database to Simple or With incomplete logging. You can change the mode temporarily, before import, or permanently if you do not need to restore the database often. Before changing the database restoring mode, back up the database.

An infobase dump file (.dt) created by 1C:Enterprise 8.1 and 8.2 can be imported to 1C:Enterprise 8.3. If you try to import a configuration with unknown compatibility mode, an error is displayed indicating the required version. Importing 1cv8.dt files generated in version 8.3.1 and later into 1C:Enterprise versions prior to 8.3.1 is not allowed. The only exception is when the configuration property Compatibility Mode is set to Version 8.2.16 in 1C:Enterprise 8.3.1 and later.

6.9. Infobase backup

6.9.1. Infobase file mode

You can create infobase backups in any file management application. Open the infobase directory in the file manager of your choice. To create an infobase backup, simply copy the 1Cv8.1CD file to another directory. To restore the infobase from backup (in case of data loss, damage, and so on), just copy the backup file to the original infobase directory.

You can use specialized software to back up and restore data.

To make a backup more informative, we recommend that you include log files (for more information, see Event log) stored in the 1Cv8Log subdirectory of the infobase directory. We also recommend that you restore the infobase together with the logs (1Cv8Log directory). This provides you with history of infobase operations performed before the backup.

6.9.2. Client/server mode of infobase

It is recommended to perform infobase backup in client/server mode using available DBMS tools.

Backup consists of the following steps:

1. Back up the database.

2. Back up the event log. Do it if you need to view the log after restoring a backup.

3. Back up the binary data storage. To back up the storage, use 1C:Enterprise language or the Binary data storage management standard function.

In this case, the infobase is restored from the backup as follows:

1. Restore the database from the backup.

2. Restore the event log from the backup if the event log was previously backed up. Do it when the server cluster is stopped.

3. Restore the binary data storage from the backup if the binary data storage was previously backed up.

See also:

• Binary data storage.

6.9.3. Mobile devices

On iOS, use the standard system functionality to create infobase backups. On Android OS, use specialized utilities.

You can set up backup creation procedure directly on the mobile device. Two backup options are available:

1. Before application update
2. Before application start

To set up backup options, open the dialog box of the application properties and click Administration. Select Backup from the menu.

Specify the following backup settings:

• Backup location (on this device) field contains the path in the local file system of the device where the backups are created. By default, this property contains backup directory located in the document directory on the mobile device.

• Create backup on application update radio button enables backup creation on application update.

• Auto backup frequency (days) property specifies the backup frequency. If this property is set to 0, backups are not created automatically. Otherwise, the backup is created before the application start if the number of days since the previous backup is greater than the value of this property.

• Number of backups property determines capacity of the backup storage. If this property is set to 0, the number of backup copies is only limited by the free space available on the selected drive. Backups created before mobile application updates are also considered when calculating the number of backup copies.

The form also contains buttons for creating backups (Create backup) and restoring a database from backup (Restore...). When you choose to restore a database, you are prompted to select the backup from which the database will be restored. The list is retrieved automatically from the contents of the directory specified in the Backup location (on this device) property.

6.10. Verifying and repairing an infobase

6.10.1. General information

A variety of abnormal situations can occur while 1C:Enterprise is running: computer or mobile device power loss, operating system stops responding, hardware failures, and so on. If such an emergency occurs while writing data to 1C:Enterprise infobases (especially when in file mode), it can damage an infobase. External signs of infobase damage can vary; in more severe cases, the damaged infobase cannot be opened.

Verify and repair procedure is designed to diagnose and eliminate damage in infobases in file or client/server mode. This procedure can be used both for infobases used on personal computers and for infobases used on mobile devices.

6.10.2. On a personal computer

To start the repair procedure, click Administration – Verify and repair in Designer. The following dialog box opens:

In the list of checks and verification modes, select the actions you need to perform. Multiple checks can be performed independently. In both modes (file and client/server), you can check the logical and referential data integrity, recalculate totals, restructure and re-index the database tables. In the file mode, you can also compress database tables. In client/server mode, you can check integrity of the binary data storage.

You can check the logical integrity, reference integrity, and the integrity of the binary data storage only for the specified list of configuration object kinds. You can use such list to reduce the check time or if you suspect issues, for example, only in the information registers of the current infobase. When you check the logical and reference integrity, keep in mind that despite the number of selected metadata object types, all tables of all configuration objects will be checked.

For some distributed infobases that can provide data containing references to objects not located in the tested infobase, clearing the Check referential infobase integrity check box allows you to disable creation of "non-existent" data and, as a consequence, prevents copying such data to other nodes of the distributed infobase.

While verifying and repairing the infobase, the main table of each object (dictionary, chart of characteristic types, chart of calculation types, or chart of accounts) is checked for containing no more than one record per predefined item of each data area. If any duplicates are found, the predefined data flag is cleared from them and the deletion mark is set instead.

You can enable the Restructuring of configuration extension tables check only if you also select the Check logical integrity of configuration extensions check and set Verify and repair mode at the same time. If configuration extensions are included in the separators (the Configuration extension separation property is set to Use for one or several separators), you can specify data areas where operations with extensions will be performed. To do this, use the Configuration extension data separation table. Each table row describes one data area. You can specify area parameters in one row where each separator has a column.

The Reindex infobase tables mode re-indexes all indexes that are created for a specific table (including additional object indexes).

The Check and enable CORP functionality mode checks ("verification only" mode) or updates ("verification and repair" mode) the state of the infobase depending on various settings:

• The Use additional indexes infobase parameter:

  • The parameter is set. All additional indexes found are checked for compliance with those specified in the configuration. Non-compliant indexes are recreated with the required structure. The compliant ones remain unchanged. Additional indexes that exist in the configuration, but are missing in the infobase are created. A diagnostic message with a list of objects for which additional indexes are created is generated.

  • The parameter is cleared. All additional indexes found are deleted from the infobase. A diagnostic message with a list of objects for which additional indexes are deleted is generated.

Several groups of settings are located below the list of verification modes:

• In the first group, select the action to perform: verify only or verify and repair. In the first case, the infobase is checked but no changes are made to it. In the second case, the infobase is checked and actions specified in the second group of settings are performed. The names of radio buttons are self-explaining.

• In the second group, select actions to perform if any references to non-existent objects are found or a partial loss of data in existing objects is detected.

• In the third group of controls, you can perform time-consuming verification and repair procedures in multiple sessions.

The Pause verification in check box specifies the time interval after which verification will be interrupted and the verification and repair parameters will be saved for the next Designer session.

The Resume verification check box allows you to continue the verification procedure paused in the previous verification and repair session.

Verification and repair events are displayed in the event log.

Click Execute to start verification. Verification can be interrupted by pressing CTRL + Break.

If the Check logical integrity of configuration extensions or Restructuring of configuration extensions parameter is selected when setting up verification and repair of the infobase, exclusive mode for the entire infobase is not required and is not set. In other cases, an attempt to set the exclusive mode for the required actions will be made.

If installation is not possible, a warning message is displayed: Cannot switch to exclusive mode. There are active users. To get information about active users, open the list of active users (click Administration – Active users).

After exclusive mode is set (if required), actions specified when setting up verification and repair are started. The protocol of performing this operation is displayed in the message window.

If exclusive mode was set before performing verification and repair, exclusive mode will be removed at the end of this operation.

When Compress infobase tables is selected for file mode, the infobase file is additionally optimized by moving all data required to open the infobase to a continuous data block in the beginning of 1Cv8.1CD file. \$\$\$remove it\$\$\$\$ This optimization accelerates the opening of the infobase, especially for configurations with a large number of infobase tables and configurations located on the network resources. After restructuring the infobase tables, the effect of table compression is lost and it is recommended to compress the infobase tables again.

You can perform the actions from this dialog box using the /IBCheckAndRepair command-line option of Designer batch mode (for more information, see Configuration and extension checks).

The distribution package includes the utility for restoring the file database (chdbfl).

6.10.3. On a mobile device

To start the repair procedure, open the application properties for editing and click Administration. Click Verify and repair in the menu.

In the verification settings form, specify:

• What actions to perform.

• Verify only, or verify and repair (the Repair automatically check box).

• What to do if references to non-existent objects are found.

• What to do if partial loss of the infobase object data is detected.

Then, click Execute in the upper right corner.

Execution of the selected actions starts and verification progress information is displayed. To interrupt verification and repair procedure, click Cancel. \$\$\$remove it\$\$\$

6.11. Cancelling the distributed infobase master node assignment

To cancel assignment of the distributed infobase master node, use the /ResetMasterNode command in Designer batch mode command line. This operation is equivalent to calling the SetMasterNode(Undefined) method of the ExchangePlansManager object.

This may be necessary, for example, when you need to separate a subtree of the distributed infobase into an independent infobase or to reassign a distributed infobase node.

6.12. Deleting data areas or infobases

To delete a data area or the entire infobase, use the /EraseData command in Designer batch mode command line. The area to delete is determined by using the /Z parameter of the startup command line.

To delete data, the user on whose behalf the deletion is performed needs the Administration right and exclusive access to the infobase.

6.13. Event log

6.13.1. General information

To perform administrative duties, it is often required to find out which events occurred at a particular point in time or what actions a particular user performed.

You can find this information in the event log. This log can record various events. Using the event log, the administrator can get the history of user operations.

The event log is not a part of a database and is not saved when exporting/importing an infobase.

1C:Enterprise logs the major actions by users who modify infobases, perform routine operations, sign in, sign out, and so on.

Event log is supported both in Designer mode and 1C:Enterprise mode. For the instructions on how to use the event log in 1C:Enterprise mode, see the help to the standard Event log function. For how to access standard functions, see Standard functions.

Event log can be generated in either of two formats:

• Sequential format (.lgf).

• SQLite format (.lgd). Version 8.3.5 supports this format. Starting from version 8.3.22, you cannot use this format in new infobases and convert into this format. In later versions, this format will no longer be supported. In previous documentation versions, you can read about SQLite format operations.

Depending on 1C:Enterprise version, different default log formats are used:

• In 1C:Enterprise 8.3.4 and previous versions, you can use only the sequential event log format.

• In 1C:Enterprise versions 8.3.5 to 8.3.11, the default format is SQLite. Event log format change is not supported.

• In 1C:Enterprise 8.3.12 and later versions, the default format is sequential. You can change the format of the used event log.

• In 1C:Enterprise 8.3.22 and later versions, the sequential format is used for new infobases. Event log format change is disabled. You can view the event log in SQLite format.

When you change the event log format while the system is running, the selected event log format is saved in the infobase. As a result, when you restore an infobase from a backup or a dump file (.dt), the event log format is also restored. Consider that if you want to restore an infobase in version 8.3.22 (or later) and this infobase is set to SQLite format and was dumped to a dt-file in previous versions.

Each event in the event log is identified by a string. The system events use a combination of $ and $ characters (for example, $InfoBase$.MasterNodeUpdate or $PerformError$). $InfoBase$.MasterNodeUpdate will be displayed as a string: Infobase. Master node change. Using these character combinations in names of events written by the WriteLogEvent() method is prohibited. The events generated by this method are displayed as is.

6.13.2. Event log in .lgf format

The event log in .lgf format is stored in text files with the following extensions:

• 1Cv8.lgf. General information about the event log.

• *.lgp. Event log fragment.

• *.lgx. Index file of the event log fragment with the same name. The index file size is about 10% of its own event log file.

Generating an event log index file depends on the used mode:

• For file mode, the event log is not indexed. The index file is not created or used.

• For client/server mode, the event log is indexed. Create and use index files. The number of indexing streams is equal to half of the number of working cores on the server cluster manager computer. In general, there can be no more than 8 streams or less than 1 stream.

Log location:

• For file mode: in the 1Cv8Log subdirectory of the infobase directory.

• For client/server mode: in the 1Cv8Log subdirectory of the infobase directory in the directory of internal cluster files. The directory name can be determined from the data registry file of the cluster.

6.13.3. Saving event log

To save the event log, open it and click File – Save copy. This will open the dialog box for selecting the directory and file to export the event log to, as well as the file type (*.lgf by default). You can also export the log in XML format (for the format description, see Description of the event log elements).

Example of event log export:

<v8e:EventLog