Функции безопасности Domino/Notes 6

Стандартная безопасность базы данных webadmin.nsf

Стандартные параметры ACL для базы данных Web-администратора см. в табл. 11.2. Вам не требуется изменять эти параметры, если имя администратора указано в поле Administrators (Администраторы) документа Server.

Аутентификация администраторов

Для доступа к Web-администратору можно использовать либо интернет-пароль, либо сертификат SSL-клиента. Web-администратор использует либо имя и пароль, либо SSL-аутентификацию для проверки личности пользователя. Используемый Web-администратором метод зависит от того, настроен ли сервер и/или база данных Web-администратора Domino (WEBADMIN.NSF) на требование имени и пароля или SSL-аутентификации.

Для доступа к базе данных Web-администратора необходимо настроить на сервере аутентификацию с использованием имени и пароля или аутентификацию SSL-клиента. Аутентификация с использованием имени и пароля включена для протокола HTTP по умолчанию.

11.1.4 Ограничения программируемости

Для управления типами агентов, которые пользователи могут запускать на сервере, можно установить ограничения для серверных агентов в документе Server. Как и в случае административного доступа, список серверных агентов в документе Server организован иерархически с учетом привилегий. Категория Run unrestricted methods and operations (Выполнение неограниченных методов и операций) имеет наибольший уровень привилегий, тогда как Run Simple and Formula agents (Выполнение простых агентов и агентов формул) имеет наименьший уровень привилегий. Имя пользователя или группы в списке автоматически получает права всех списков, находящихся ниже в иерархии. Таким образом, имя нужно вводить только в одном списке, в результате чего пользователь получит наивысшие права.

Замечание. Следует создавать группы для каждого класса пользователей, который будет употребляться в каждой категории.

Run unrestricted methods and operations (Выполнение неограниченных методов и операций)

Новое в Domino 6

В этой категории можно выбирать пользователей и группы по агентам, в одном из трех уровней доступа для агентов, подписанных своими идентификаторами. Пользователи с такими привилегиями выбирают один их нижеперечисленных уровней доступа при использовании Domino Designer 6 для компоновки агента.

• Ограниченный режим (Restricted mode).
• Неограниченный режим (Unrestricted mode).
• Неограниченный режим с полными административными правами (Unrestricted mode with full administration rights).

Только пользователи с таким уровнем доступа могут выбрать опцию, отличную от Do not allow restricted operations (Не разрешать ограниченные операции). Такой доступ устанавливается по умолчанию для текущего сервера и разработчиков шаблонов Lotus Notes.

Если пользователи из этого списка также указаны как администраторы базы данных в документе Server, им разрешается выполнять операции с базой данных без явного указания в ACL базы данных (например, они могут удалять базы данных, не будучи указанными в ACL этих баз данных).

Примечание. Чтобы иметь возможность выполнения агентов в неограниченном режиме с полными административными правами, пользователь (группа), выполнивший подписание агента, должен быть указан в этом поле или в поле Full Access Administrators (Администраторы с полным доступом), а также для них должен быть выбран этот режим в Agent Builder. Внесение в список Full Access Administrators (Администраторы с полным доступом) само по себе не является достаточным для выполнения агентов в этом режиме.

Sign agents to run on behalf of someone else (Подписание агентов для выполнения от имени другого пользователя/группы)

Следует ввести имена пользователей и групп, которым разрешается выполнять подписание агентов, которые будут выполняться от имени другого пользователя. По умолчанию эта категория пуста; это означает, что никто не может осуществлять подписание агентов таким образом.

Примечание. Эту привилегию следует использовать с осторожностью, так как имя, применявшееся для подписания агента, употребляется для проверки доступа в ACL.

Sign agents to run on behalf of the invoker of the agent (Подписание агентов для выполнения от имени вызывающей стороны)

Следует ввести имена пользователей и групп, которым разрешается выполнять подписание агентов, которые будут выполняться от имени вызывающей стороны, когда вызывающая сторона неидентична подписывающей стороне. Если вызывающая сторона и подписывающая сторона идентичны, этот параметр игнорируется. В настоящее время используется только для Web-агентов. По умолчанию эта категория пуста; это означает, что все могут выполнять подписание агентов, вызываемых таким образом (предназначено для обратной совместимости).

Run restricted LotusScript/Java agents (Выполнение ограниченных агентов LotusScript/Java)

Введите имена пользователей и групп, которым разрешено выполнять агенты, созданные с использованием функций LotusScript и Java, но не содержащие привилегированные методы и операции, такие, как чтение и запись в файловую систему. Чтобы запретить доступ для всех пользователей и групп, следует оставить это поле пустым.

Run simple and formula agents (Выполнение простых агентов и агентов формул)

Следует ввести имена пользователей и групп, которым разрешается выполнять простые агенты и агенты формул (как личные, так и общие). Для того чтобы все пользователи и группы могли выполнять простые агенты и агенты формул (как личные, так и общие), следует оставить это поле пустым.

Sign script libraries to run on behalf of someone else (Подписание библиотек скриптов для выполнения от имени другого пользователя/группы)

Введите имена пользователей и групп, которым разрешается выполнять подписание библиотек скриптов в агентах, выполняемых другими пользователями/группами. В целях обратной совместимости по умолчанию это поле остается пустым, что разрешает всем пользователям/группам выполнять такие операции.

11.1.5 Политики и документы политик

Политики позволяют осуществлять контроль над работой пользователей с Notes. Политика представляет собой документ, который идентифицирует набор отдельных документов с параметрами политик. Каждый из этих документов с параметрами политик определяет набор используемых по умолчанию параметров, которые применяются к пользователям и группам, для которых устанавливается политика. После установления политики можно легко изменить параметры, и они будут автоматически применяться к тем пользователям, для которых установлена политика.

Политики Domino не следует путать с корпоративными политиками безопасности. Корпоративная политика безопасности представляет собой набор инструкций и стандартов, используемых в организации для установления и применения безопасных методов работы с информацией. Дополнительные сведения о политиках без-опасности в организации см. в "Методологии построения систем безопасности" .

Создание документов с параметрами политик выполняется для следующих областей администрирования:

• Регистрация (Registration). Устанавливаются используемые по умолчанию значения параметров регистрации пользователя, включая пароль пользователя, формат интернет-адреса, обозначение перемещающегося пользователя и почту.
• Установка (Setup). Эти параметры используются при начальной установке клиента Notes для заполнения документа Location пользователя. К параметрам установки относятся параметры интернет-браузера и прокси-сервера, параметры безопасности апплетов и предпочтения рабочего стола и пользователей.
• Рабочий стол (Desktop). Осуществляет контроль и обновление рабочей среды пользователя или усиливает параметры политики установки. Например, при внесении изменений в любой из параметров политик при следующей аутентификации пользователей на домашнем сервере параметры политики рабочего стола восстанавливают заданные по умолчанию параметры или распространяют новые параметры, заданные в документе параметров политики рабочего стола.
• Архивация почты (Mail archiving). Управляет архивацией почты. Параметры архивации управляют выполнением архивации и определяют критерии архивации.
• Безопасность (Security). Устанавливают ECL администрирования и определяют опции управления паролями, включая синхронизацию интернет-паролей и паролей Notes. Ниже перечислены некоторые опции управления паролями
  • Разрешение изменения пользователями своих интернет-паролей через HTTP.

    Примечание. Чтобы пользователи могли изменять свои интернет-пароли через браузер, необходимо, чтобы на вашем сервере была включена сеансовая аутентификация (session authentication).
  • Синхронизация интернет-паролей с паролями Notes. (Дополнительные сведения о синхронизации паролей Notes и интернет-паролей см. в разделе 11.7, "Синхронизация интернет-паролей и паролей Notes".)
  • Требование паролей для аутентификации в Notes.
  • Применение срока действия для паролей Notes и/или интернет-паролей. Можно также определить требуемые интервалы изменений, периоды отсрочки (grace periods) и историю паролей history (только в Notes).
  • Настройка качества пароля. Устанавливает уровень качества или длину пароля.
  

  
  увеличить изображение
  Рис. 11.3. Параметры паролей в документе Security Settings

  Важно! При проверке паролей информация в документе Person отменяет информацию в документе Server. При отключении проверки паролей для пользователя Domino не проверяет пароли для пользователя, даже если проверка паролей включена для сервера. При отключении проверки паролей для сервера Domino не проверяет пароли для любых пользователей, осуществляющих доступ к серверу, даже если для пользователя включена проверка пароля.

Что касается ECL, политика позволяет осуществлять управление следующими параметрами:

• Создание нового административного ECL или редактирование ECL по умолчанию.
• Выбор режима обновления для ECL рабочей станции. Значение Refresh обновляет ECL рабочей станции, добавляя изменения, внесенные в административный ECL; параметры административного ECL замещают параметры ECL рабочей станции. Значение Replace перезаписывает ECL рабочей станции административным ECL. Эта опция перезаписывает все параметры ECL рабочей станции.
• Частота обновления ECL рабочей станции: Once Daily – при аутентификации клиента на домашнем сервере, если либо прошли сутки с момента последнего обновления ECL либо был изменен административный ECL; When Admin ECL Changes – обновление ECL рабочей станции выполняется при аутентификации клиента на домашнем сервере, если административный ECL был изменен с момента последнего обновления; Never – не допускает обновления ECL рабочей станции во время аутентификации.

Существует два типа политик: организационные (organizational) и явные (explicit). Понимание различий между этими типами помогает при планировании реализации.

Организационные политики

увеличить изображение
Рис. 11.4. Параметры безопасности: опции списка управления выполнением

Организационная политика автоматически применяется ко всем пользователям, зарегистрированным в определенном подразделении. Например, для распространения параметров по умолчанию для всех пользователей, зарегистрированных в Sales/Acme, следует создать организационную политику с именем */Sales/Acme. Затем при употреблении идентификатора центра сертификации Sales/Acme для регистрации пользователя этот пользователь автоматически получает параметры из соответствующей организационной политики.

При перемещении пользователя в иерархической структуре, например в связи с переходом пользователя из отдела продаж (Sales) в отдел маркетинга (Marketing), пользователю автоматически назначается организационная политика для соответствующего идентификатора центра сертификации. Например, при перемещении пользователя из Sales/Acme в Marketing/Acme пользователю назначаются все параметры рабочего стола, архивации и безопасности, связанные с организационной политикой */Marketing/Acme. Новые параметры политики вводятся в действие при первой аутентификации пользователей на домашнем сервере.

Явные политики

Явная политика назначает параметры по умолчанию отдельным пользователям или группам. Например, для того чтобы установить 6-месячный период сертификации для контрактных сотрудников во всех отделах, следует создать явную политику, после чего применить ее для каждого контрактного сотрудника или группы, включающей всех контрактных сотрудников.

Существует три способа назначения явной политики: во время регистрации пользователя, при редактировании документа Person пользователя или с применением инструмента Assign Policy.

Использование исключений

Можно назначить атрибут исключения как для организационной, так и для явной политики, чтобы пользователь мог игнорировать параметр политики, который в противном случае применяется в организации. При создании политики исключения указываются только те параметры, которые не применяются принудительно. Кроме того, при назначении политики исключения она освобождает пользователей только от применения этих параметров.

Политики исключений представляют собой способ специального обслуживания пользователей в организации, что может быть связано с их должностью или специальными требованиями. Например, предположим, что политика */Acme включает параметр политики регистрации, применяющий квоту почтовой базы данных объемом 60 Мб. Однако небольшой группе сотрудников в подразделении Acme требуется превысить эту квоту. Решение состоит в том, чтобы создать политику исключения, включающую только документ параметров политики регистрации, не устанавливающий ограничение квоты для почтовой базы данных. При назначении политики исключения пользователям они могут заменить параметр квоты базы данных. Так как политики исключений отменяют применение параметров политик, их использование должно быть умеренным.

Дополнительные сведения о настройке и назначении политик см. в разделе "Policies" ("Политики") главы "User and Server Configuration" ("Конфигурация пользователей и серверов") руководства "Domino 6 Administration Guide".

11.1.6 Безопасность интернет-сайта

Новое в Domino 6

Документы Internet Site используются для настройки интернет-протоколов, поддерживаемых серверами Domino. Отдельный документ Internet Site создается для каждого протокола [Web (HTTP), IMAP, POP3, SMTP Inbound, LDAP и IIOP] и затем используется для предоставления информации о настройке протокола для одного сервера или для нескольких серверов в организации Domino. В частности, можно создавать следующие типы документов:

• Документы Web Site. По одному для каждого Web-сайта, расположенного на сервере Domino.
• Документы LDAP Site. Для включения LDAP-доступа к организации в каталоге.
• Документы IMAP Site, POP3 Site и SMTP Site. Для каждого почтового протокола, для которого вводится IP-адрес, создается отдельный документ Internet Site.
• Документы IIOP Site. Создается один документ для включения задачи Domino IIOP (DIIOP) на сервере. Эта задача позволяет Domino и клиенту на основе браузера использовать серверную программу Domino Object Request Broker (ORB).

Документы Internet Site упрощают для администраторов конфигурирование и управление интернет-протоколами в своих организациях. Например, до появления Domino 6 при установке Web-сайта в организации необходимо было настраивать каждый сервер Domino в домене с использованием документов Mapping, Web realms (экземпляров) и документов File Protection. При использовании виртуальных серверов и виртуальных узлов необходимо было выполнять для них такие же операции. В Domino 6 можно сконфигурировать документ Web Site, который будет использоваться всеми серверами и узлами для получения информации о конфигурации для Web-сайта, включая информацию о сопоставлении, информацию о защите файлов и информацию об аутентификации экземпляра Web realm.

Необходимо использовать документы Internet Site в следующих случаях:

• eсли требуется использовать WebDAV (Web-based Distributed Authoring and Versioning) на Web-сервере Domino;
• eсли на вашем сервере включен SSL и требуется использовать списки отзыва сертификатов (Certificate Revocation Lists) для проверки подлинности интернет-сертификатов, используемых для аутентификации на сервере;
• eсли на сервере используется конфигурация hosted organization (хостируемая организация).

Дополнительные сведения о конфигурировании Domino для хостируемых организаций см. в руководстве "Domino 6 Administration Guide".

Изменения в документах Internet Site (включая создание новых документов Site) являются динамическими. Не требуется перезапускать сервер или протокол после создания нового документа Site или после изменения или удаления существующего. Изменения обычно вступают в действие через несколько минут после их внесения.

Возможность динамического создания, изменения и удаления документов Internet Site особенно полезна в средах поставщиков услуг; при этом работа существующих хостируемых организаций не прерывается при конфигурировании новой хостируемой организации.

Сервер Domino настраивается на использование документов Internet Site, если эта опция включена в документ Server. Если опция не включена, сервер использует параметры документа Server для получения информации о конфигурации для интернетпротоколов.

Документы Internet Site создаются в представлении Internet Sites, которое помогает в управлении информацией о конфигурации интернет-протоколов, выводя сконфигурированные документы Internet Site для каждой организации в домене.

увеличить изображение
Рис. 11.5. Параметры безопасности в документе Server, осуществляющие поддержку конфигураций интернет-протоколов

Важно! При использовании документа Internet Site для конфигурирования одного интернетпротокола на сервере необходимо также использовать документы Internet Site для всех интернет-протоколов на этом сервере. Например, нельзя настроить документ LDAP Internet Site и на том же сервере использовать документ Server для конфигурирования HTTP.

Хотя настройка большинства параметров протоколов осуществляется через документы Internet Site, некоторые параметры требуется настраивать в документе Server для поддержки конфигураций интернет-протоколов. К ним относятся следующие параметры:

• включение и конфигурирование порта TCP/IP;
• включение и конфигурирование порта SSL (включая перенаправление TCP в SSL);
• конфигурирование доступа к серверу, а именно кто и каким образом может осуществлять доступ к серверу.

Рис. 11.6. Параметры безопасности в документе Web Site

Защита документов Internet Site

Для обеспечения защиты документов Internet Site можно включить SSL-аутентификацию сервера и клиента, аутентификацию с использованием имени и пароля или анонимный доступ для интернет-клиентов и клиентов интрасети.

Чтобы включить SSL для интернет-сайтов, необходимо сконфигурировать SSL-порт в документе Server и установить SSL на сервере, получив сертификат сервера и набор ключей (key ring) от центра сертификации в Интернете.

Для настройки SSL-аутентификации необходимо создать файл набора ключей сервера (server key ring file) для каждого документа Internet Site. Однако если документы Internet Site относятся к одной организации, но создаются для различных протоколов, можно использовать один файл набора ключей сервера. Следует обязательно ввести имя файла набора ключей сервера в соответствующем поле вкладки Security (Безопасность) документа для каждого сайта.

Если требуется использовать списки отзыва сертификатов (Certificate Revocation List, CRL) для аутентификации на основе интернет-сертификатов, сервер должен использовать центр сертификации на основе сервера Domino для выдачи интернетсертификатов.

Чтобы включить SSL для хостируемой организации, необходимо ввести IP-адрес сервера в поле Host names or addresses mapped to this site (Имена или адреса узлов, поставленных в соответствие этому сайту) на вкладке Basics (Основные параметры) документа Internet Site.

Для Web-сайтов общее имя (common name) в серверном наборе ключей должно соответствовать DNS-имени, которому ставится в соответствие IP-адрес в документе Web Site. IP-адрес должен быть записан в поле Host name or addresses to map to this site (Имя узла или адреса, ставящиеся в соответствие этому сайту) в документе Web Site. При включении опции Redirect TCP to SSL (Перенаправление TCP в SSL) в документе Web Site в этом поле следует указать как имя, так и IP-адрес узла.

В Domino 6 можно эффективно препятствовать доступу к документу Internet Site, выбрав "No" для всех опций аутентификации в документе Internet Site. К этим опциям относятся TCP-аутентификация, SSL-аутентификация и анонимный доступ TCP.

Нельзя использовать документы Internet Site в среде со смешанными версиями Domino. Вместо них следует применять документы конфигурации Web Server и параметры протоколов в документе Server.

Дополнительные сведения о настройке SSL см. в "Инфраструктуры открытых ключей" .

Дополнительные сведения о центре сертификации на основе сервера Domino 6 см. в разделе 11.5.1, "Центр сертификации на основе сервера Domino".

11.1.7 Физическая защита сервера

И наконец, при планировании безопасности любой серверной среды следует обязательно рассмотреть методы физической защиты сервера от злоумышленников. Физическая защита включает следующие методы:

• Расположение сервера в защищенном месте во избежание несанкционированного доступа к незашифрованным данным, идентификаторам сервера и центра сертификации, хранящимся на жестком диске сервера.
• Защита консоли сервера паролем во избежание ввода команд на консоли сервера неавторизованными пользователями.

Новое в Domino 6

• Защита консоли сервера смарт-картой во избежание неавторизованного доступа. Подробные сведения об использовании смарт-карты для защиты консоли сервера см. в главе "Доступ пользователей Notes, пользователей Интернета и серверов Domino к серверу" руководства "Domino 6 Administration Guide".

11.2 Безопасность HTTP-сервера

Новое в Domino 6

Начиная с Domino 6, Lotus Domino имеет полностью новый HTTP-сервер. Этот новый "стек" HTTP более актуален, чем первоначальный код, реализованный в Domino при внедрении поддержки протокола HTTP в Domino 4.5. Новый стек Domino 6 больше не содержит устаревших компонентов кода HTTP оригинального HTTP-сервера IBM (также известного как ICS). Это означает, что в Domino 6 изменена поддержка API-интерфейсов стеков HTTP.

Новый стек содержит функции расширенного администрирования Web-сайта и виртуального хоста, поддержку постоянных подключений HTTP 1.1 и улучшенную обработку сеансов. С точки зрения безопасности также реализована улучшенная защита от атак типа "denial of service" (отказ в обслуживании, DOS) с большей степенью контроля над количеством сегментов путей, максимальным размером заголовков, длиной URL length и т. д. Также можно осуществлять IP-фильтрацию с помощью шаблонов с использованием списков разрешений и отказов в доступе на основе IP-адреса.

Кроме того, новый стек содержит улучшенную поддержку подключаемых модулей HTTP, что позволяет подключать HTTP-сервер Domino к Web-серверам сторонних производителей (включая установку брандмауэра между Web-сервером и Domino), а также расширенный и улучшенный подключаемый модуль DSAPI, что упрощает создание собственных подключаемых модулей для HTTP-сервера Domino. Эти две функции (подключаемые модули DSAPI и HTTP) более подробно описываются в следующих двух разделах.

11.2.1 Domino Web Server API

Domino Web Server Application Programming Interface (DSAPI) представляет собой инструмент C API, позволяющий создавать собственные расширения для Web-сервера Domino. Эти расширения (или фильтры) позволяют настраивать аутентификацию Web-пользователей.

Во времена Domino 4.6.1 оригинальный Web-сервер IBM Web Server (ICS) был переименован в Domino "GO" Web Server и общий API для Domino и нового Domino "GO" Server был назван GWAPI (Go Webserver Application Programming Interface). Однако начиная с Domino 5.0 был реализован новый, в полной мере кросс-платформенный API для расширения функциональности таких дополнительных подключаемых модулей. Domino 5 DSAPI взаимодействовал с "устаревшим" HTTP-стеком ICS, который все еще входил в состав Domino 5, обеспечивая совместимость с GWAPI (хотя и не объявленную, а только толерантную совместимость). Это представляло дополнительную сложность, поэтому такая схема была упрощена в новом HTTP-стеке Domino 6, включающем улучшенный DSAPI.

Принимая во внимание исторические изменения в DSAPI, при обновлении до Domino 6 важно рассмотреть все подключаемые модули DSAPI на основе R5, существующие в вашей архитектуре. Несмотря на то что DSAPI, разработанный для Domino 5, может выполняться и в Lotus Domino 6, он не предназначен для поддержки новой архитектуры HTTP-стека, поэтому он может не работать оптимальным образом. Другими словами, он может функционировать, однако функции, выполняемые API, могут требовать другого архитектурного способа реализации, чтобы использовать преимущества новой архитектуры HTTP, встроенной в Domino 6.

Одним из изменений, реализованных в Domino 6 API, которое может быть причиной для перезаписи R5 DSAPI, состоит в том, что в R5 DSAPI ваш код вызывается в 100 % случаев, когда требуется "шаг" HTTP-стека (другими словами, при перехвате запросов аутентификации DSAPI вызывается в 100 % случаев). Однако в Domino 6 можно назначать DSAPI для отдельных интернет-сайтов, вследствие чего они не вызываются в 100 % случаев, что позволяет улучшить производительность.

Ограничение. DSAPI-интерфейсы, разработанные для R5, могут вызвать отказ HTTP-сервера при выделении динамической памяти DSAPI для использования в качестве частного (private) контекста с нарушением новых правил для Domino 6. Это означает, что вам (или поставщику вашего DSAPI-приложения) может потребоваться внести некоторые изменения в исходный код R5/DSAPI-приложения и перекомпилировать его с использованием нового пакета инструментов. Это та цена, которую приходится платить за улучшение стабильности памяти в соответствии с требованиями HTTP-стека R6.

Дополнительные сведения об использовании DSAPI в конфигурации с единой регистрацией (single sign-on) см. в разделе 7.4, "DSAPI".

11.2.2 Подключаемые модули HTTP-сервера

Новое в Domino 6

Domino R6 использует модель подключаемых модулей Web-сервера WebSphere. Эта функция заменяет архитектуру "Domino for IIS", которая была реализована в Release 5. Эта новая модель позволяет использовать Web-сервер стороннего производителя (например, IIS) для работы с браузерами и обслуживания статического содержимого (что является их специализацией), направляя все NSF-запросы в HTTP-стек Domino. Подключаемые модули используют HTTP для связи с сервером Domino; при этом HTTP-сервер стороннего производителя может находиться в демилитаризованной зоне, тогда как его подключаемые модули, осуществляющие обмен данными с HTTP-сервером Domino, находятся в брандмауэре. Подключаемые модули поддерживают основные службы заднего плана Domino [основные функции базы данных Domino, Lotus iNotes Web Access, Lotus Domino Off-Line Services (DOLS), Lotus Discovery Server™]; остальной HTTP-трафик игнорируется подключаемым модулем и обрабатывается HTTP-сервером переднего плана.

Такая новая архитектура подключаемых модулей применима для всех поддерживаемых операционных систем, в которых работает Domino, так как подключаемый модуль в действительности не устанавливается непосредственно на сервере Domino. Вместо этого подключаемый модуль устанавливается на HTTP-сервере переднего плана. Domino 6.0 поддерживает следующие серверы переднего плана:

• IBM HTTP Server (IHS) в AIX, Windows NT 4.0 и Windows 2000 Server;
• Microsoft IIS в Windows NT 4.0 и Windows 2000 Server.

Файлы подключаемых модулей для этих серверов поставляются вместе с сервером Domino 6, и их использование покрывается лицензией Domino (при условии, что подключаемый модуль, устанавливаемый в системе, будет использоваться для доступа к лицензированному серверу Domino 6).

При установке Lotus Domino 6 процедура установки генерирует подкаталог plugins в каталоге data/domino. Этот подкаталог plug-ins содержит подключаемые модули WAS 4.x и 5.x для работы со множеством серверов переднего плана, включая Microsoft IIS и IBM Apache HTTP. Повторимся, что вам не следует устанавливать эти подключаемые модули в Domino 6, их следует копировать и устанавливать в других HTTP-стеках (например, в IIS).

После установки и надлежащего конфигурирования подключаемого модуля на HTTP-сервере переднего плана на сервере Domino выполняется настройка параметра файла notes.ini (HTTPEnableConnectorHeaders=1). Этот параметр файла notes.ini сообщает Domino о том, что следует начать использовать и доверять информации USER, как передаваемой в HTTP-заголовках подключаемым модулем переднего плана.

Дополнительные сведения о внутренней работе новой модели подключаемых модулей HTTP см. в прил. "C", "Советы и рекомендации по подключаемым модулям HTTP в Domino 6".

Дополнительные сведения об архитектуре подключаемых модулей HTTP в Domino 6, а также об их использовании в системах IBM iSeries см. в руководстве Lotus Domino 6 for iSeries Implementation, SG24-6592.