Версия 5.2
Администрирование |
|---|
| ||||||||||
|
|
Версия 5.2 |
||||||||||||||||||||||||||||||||
|
|
Сервер CommuniGate Pro поддерживает как незащищённые, так и безопасные методы SASL аутентификации для следующих сессионных протоколов TCP:
Такие безопасные методы позволяют почтовым клиентам посылать зашифрованные пароли через нешифрованные и небезопасные каналы связи. Если кто-нибудь осуществляет мониторинг вашего сетевого трафика, то использование SASL методов обеспечит невозможность перехвата реальных паролей из трафика между клиентом и сервером.
В качестве альтернативы SASL методам, между сервером и почтовой программой может использоваться обмен информацией по безопасному (SSL/TLS) соединению. Когда SSL соединение установлено, весь сетевой трафик между сервером и клиентом шифруется, и через такие соединения пароли могут пересылаться в открытом виде.
Вы можете обязать Пользователя использовать либо безопасные методы аутентификации SASL, либо SSL/TLS соединения, если вы включите в Установках Пользователя опцию Аутентификация Только Безопасно. Когда эта опция включена, Сервер отвергает все запросы на аутентификацию, требующие переслать пароль в незащищённом виде через небезопасное соединение.
Сервер CommuniGate Pro поддерживает следующие небезопасные (незащищённые) методы SASL аутентификации:
Сервер CommuniGate Pro поддерживает следующие безопасные методы SASL аутентификации:
Сервер CommuniGate Pro поддерживает следующие GSSAPI методы аутентификации:
Сервер CommuniGate Pro поддерживает следующие SASL-EXTERNAL методы аутентификации:
Сервер CommuniGate Pro поддерживает нестандартные NTLM и MSN SASL методы, используемые в продуктах Microsoft®.
CommuniGate Pro поддерживает метод аутентификации APOP (преимущественно используемый для протокола POP), и небезопасный метод "обычного входа" для протоколов, которые поддерживают Незащищённый Вход.
Сервер CommuniGate Pro поддерживает специальный метод Аутентификации SessionID .
Используя Веб Интерфейс Администратора откройте страницу Установки Домена и найдите панель Способы Аутентификации:
Эти опции Оповещения влияют только на услуги "сессионного" типа (SMTP, POP, IMAP, ACAP, PWD, FTP), и никак не оказывают никакого эффекта на услуги "транзакционного" типа (HTTP, SIP).
Эти опции Оповещения задают только то, как Сервер оповещает о доступных методах входа. Клиентские приложения могут использовать любые методы, даже если оповещение об их доступности со стороны Сервера было выключено.
Один пароль - это "собственный пароль" CommuniGate Pro. Этот пароль хранится как элемент в Установках Пользователя, и может использоваться только Сервером CommuniGate Pro.
Другой пароль - это "Пароль из ОС". Пользователь может быть зарегистрирован в ОС Сервера и Сервер CommuniGate Pro может сверять полученный пароль с паролем, используемым этим пользователем для входа в ОС.
Можно так же установить для Пользователя опцию Через Внешнюю Программу. В этом случае, аутентификация пользователя выполняется через стороннюю программу, работающую как отдельный процесс (смотрите ниже).
Системный Администратор может включить использование любого набора паролей для любого пользователя. На больших сайтах, лучше включать эти опции через Общие для Сервера или Общие для Домена Умолчания для Пользователей.
В случае, когда для пользователя включено использование нескольких паролей, Сервер сначала проверяет CommuniGate-Пароль (внутренний), затем Пароль из ОС, и только затем будет пытаться аутентифицировать пользователя Через Внешнюю Программу. Если хотя бы один из этих паролей получен от клиентского приложения, то этому приложению будет предоставлен доступ к Серверу.
Пароли CommuniGate Pro это специальные строки, хранящиеся в Установках Пользователя. Парольные строки могут хранится в открытом или закодированном виде. Настройка Шифрование Пароля задаёт тип шифрования, который будет использоваться при очередном изменении пароля. При изменении этой настройки, текущие пароли не перешифровываются.
При использовании опции Шифрование Пароля U-crpt , пароли CommuniGate Pro сохраняются с использованием стандартной процедуры Unix crypt. Если выбрана опция Шифрование Пароля UB-crpt, то будет использоваться усиленное шифрование Blowfish.
В U-crpt и UB-crpt методах используется одностороннее шифрование. В результате, Сервер не сможет расшифровать оригинальные (в текстовой форме) пароли, и не сможет использовать их для безопасных (SASL) Методов Аутентификации. Используйте эти методы шифрования, только если вам необходимо обеспечить совместимость с существующими парольными строками, но вы не можете использовать Пароли из ОС - обычно, важнее обеспечить безопасность при "передачи по проводам" (через методы SASL), чем при "хранении на диске" (с использованием односторонних методов шифрования).
Пароли, зашифрованные методом U-crpt, могут содержать специальные префиксы. Эти префиксы позволяют вам импортировать пароли, зашифрованные с использованием других методов шифрования.
Дополнительную информацию смотрите в разделе Миграция.
Обратите внимание: пожалуйста, не забывайте, что в обычной процедуре Unix crypt используются только первые 8 символов парольной строки.
Если CommuniGate-Пароль отсутствует или пустой, он не может использоваться для входа на Сервер даже если опция использовать CommuniGate-Пароль включена. Но если пользователь аутентифицировался на Сервере используя Пароль из ОС (или при помощи Внешней Программы), то пользователь сможет задать (изменить) CommuniGate-Пароль. Эта возможность может быть использована при миграции пользователей из действующих почтовых систем, когда у вас нет возможности создать список пользователей с незашифрованными паролями.
Когда Сервер проверяет Пароль из ОС, он создаёт строку имя пользователя, используя настройку Имя в ОС. Когда используется строка по умолчанию *, то создаваемая строка Имя в ОС будет соответствовать имени Пользователя. Изменяя настройку Имя в ОС, вы можете использовать разные имена Пользователей в ОС для Пользователей из разных Доменов CommuniGate Pro.
| Операционная система Сервера | Примечания о Пароле из ОС |
|---|---|
| Microsoft Windows 95/98/ME | Эта ОС не поддерживает пароли, опция Пароль из ОС работать не будет. |
| Microsoft Windows 200x/XP/NT/Vista | Используется система аутентификации в домене Windows NT. Пользователь Windows, от имени которого запущен Сервер CommuniGate Pro, должен иметь право Действовать как часть операционной системы.
Аргумент командной строки --BatchLogon может быть использован для заданию Серверу метода аутентификации LOGON_BATCH (если опция не задана, будет использоваться метод LOGON_NETWORK). Сервер проверяет, содержит ли созданное имя пользователя ОС символ процент (%). Если такой символ имеется, то часть Имени Пользователя перед этим символом рассматривается как имя пользователя в Windows, а часть после будет считаться доменным именем Windows.
|
| Операционные системы Unix | Используются механизмы аутентификации passwd и shadow или другие, поддерживаемые OS. |
| OS/400 systems | Используется механизм аутентификации user profile. |
| OpenVMS системы | Полученное имя пользователя и парольная строка преобразовываются в заглавные буквы, а затем используется механизмы аутентификации OpenVMS. |
| BeOS | Эта ОС не поддерживает пароли, опция Пароль из ОС работать не будет. |
Пароль из ОС являются односторонне зашифрованными паролями. Как следствие, они не могут использоваться для Методов Безопасной Аутентификации.
Сервер CommuniGate Pro поддерживает метод аутентификации пользователей через Kerberos. Методы Kerberos базируется на "мандатах" ("ticket"), которое клиентское приложение отправляет на сервер. Эти мандаты выдаются центрами Kerberos (Центры Распространения Ключей, KDC), которые имеют общий с Сервером "ключ". Дополнительную информацию смотрите в документации на Kerberos.
Для поддержки Аутентификации через Kerberos вам необходимо, индивидуально для каждого домена добавить ключ(и) Сервера Kerberos в Сервер. Создайте "доверителя" сервера ("principal") в вашей базе данных KDC. Имя доверителя должно совпадать с именем домена CommuniGate Pro или с именем одного из Псевдонимов Домена. Экспортируйте созданный ключ в файл keytab.
Через Веб Интерфейс Администратора откройте страницу Установки Домена, затем пройдите по ссылкам Безопасность и Kerberos. Будет показан список Kerberos Ключей Домена:
Каждый Домен может иметь несколько Kerberos Ключей. Для того, что бы добавить ключи, нажмите на кнопку Browse и выберите файл keytab, экспортированный из KDC. Для того, что бы добавить ключи из файла к Kerberos Ключам Домена, нажмите на кнопку Импортировать Ключи.
Для удаления Ключей, отметьте ключи и нажмите на кнопку Удалить Помеченные.
Администраторы Домена могут Добавлять или Удалять Kerberos Ключи только если они имеют право доступа Kerberos Ключи.
Когда Сервер получает мандат Kerberos, он извлекает из Мандата имя Сервера ("sname"). Если Имя Сервера имеет только одну компоненту (domain.dom), то эта компонента используется как имя целевого Домена (ticket-domain-name). Если Имя Сервера имеет две или более компоненты, (service/domain.dom), то используется вторая компонента. Затем Сервер создаёт фиктивный адрес LoginPage@ticket-domain-name и пытается осуществить его маршрутизацию. При этом используется точно такой же механизм маршрутизации, что и при нахождении целевого Домена при HTTP запросах.
Если целевой Домен найден, Сервер ищет подходящий ключ в списке Ключей Kerberos для этого Домена. Если Ключ найден, и Мандат и Авторизационная информация могут быть расшифрованы с помощью этого Ключа, то пользователь аутентифицируется. Имя Пользователя берется из Имени Клиента, указанного в Мандате. Это имя должны быть "простым", то есть не должно содержать символов @ или %.
CommuniGate Pro добавляет имя целевого Домена к полученному имени пользователя и использует этот адрес как имя Пользователя, к ресурсам которого необходимо предоставить доступ.
Обратите внимание: Механизм Аутентификации Kerberos НЕ осуществляет маршрутизацию финального получившегося имени пользователя. Если бы использовался Маршрутизатор, то имя в одном Домене теоретически могло бы быть перенаправлено на имя в другом Домене, что привело бы к тому, что с помощью Kerberos Ключей действительных для одного Домена, был бы получен доступ к другому Домену. Побочным эффектом этого является то, что Псевдонимы Пользователей не могут использоваться в мандатах Kerberos.
Сервер будет предоставлять доступ к ресурсам только тех Пользователей, для которых Kerberos Аутентификация включена.
Возможно, вам потребуется что бы Microsoft Active Directory выступала в роли Центра Распространения Kerberos Ключей (KDC). Выполните следующие действия:
Более подробную информацию вы можете прочитать в Базе Знаний Microsoft, статья Q324144.
Если вы хотите использовать Аутентификацию Kerberos (механизм единого входа на сервер) с браузерами Microsoft, пожалуйста прочитайте статью "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документации Microsoft, доступной на MSDN.
Сервер CommuniGate Pro поддерживает методы аутентификации, использующие Сертификат Клиента. Это метод может использоваться, когда клиенты устанавливают соединения с Сервером через безопасные SSL/TLS соединения. Сервер может затребовать от клиента предоставления Сертификата Клиента (установленного на компьютере клиента), подписанного Доверенным Сертификатом, выбранным Сервером для требуемого Домена.
Если клиент отправляет такой сертификат, то адрес электронной почты, указанный в элементе subjectAltName Сертификата (если есть) или в поле электронной почты в элементе Subject может быть использован для Аутентификации по Сертификату. Этот адрес интерпретаруется как имя Пользователя, который должен войти на сервер CommuniGate Pro.
Обратите внимание: Механизм Аутентификации по Сертификату НЕ производит маршрутизацию адреса через Маршрутизатор. Если бы использовался Маршрутизатор, то имя в одном Домене теоретически могло бы быть перенаправлено на имя в другом Домене, что привело бы к тому, что с помощью Доверенных Сертификатов действительных для одного Домена, был бы получен доступ к другому Домену. Побочным эффектом этого является то, что Псевдонимы Пользователей не могут использоваться в механизме Аутентификации через Сертификаты.
Сервер будет предоставлять доступ к ресурсам только тех Пользователей, для которых Аутентификация По Сертификату включена.
Дополнительную информацию смотрите в разделе PKI.
Сервер CommuniGate Pro может использовать Внешнего Помощника для аутентификации пользователей. Эта программа создаётся вашим техническим персоналом и в ней реализуются требуемые для вашего сайта механизмы аутентификации, прямо не поддерживаемые Сервером CommuniGate Pro.
Программа Внешней Аутентификации может также использоваться также для:
Имя программы для Внешней Аутентификации и её дополнительные параметры задаются через Веб Интерфейс Администратора на странице Помощники. Через Веб Интерфейс Администратора откройте в области Установки страницу Помощники:
Подробно эти опции описываются в разделе Программы-Помощники.
Записи, помещаемые в Системный Журнал Сервера модулем Внешней Аутентификации имеют метку EXTAUTH.
Если программа, осуществляющая Внешнюю Аутентификацию, не запущена, то все запросы на Внешнюю Аутентификацию отвергаются.
Для того, что бы создать собственную программу для Внешней Аутентификации, ознакомьтесь в разделе Помощники с описанием Интерфейса и протокола для Внешней Аутентификации.
С примером программы и сценариев для Внешней Аутентификации можно ознакомиться на сайте CommuniGate Systems в разделеПомощники для Аутентификации.
Некоторые спаммеры используют "атаку грубой силой" на почтовые системы, отправляя случайные имена и пароли на POP, IMAP и другие порты доступа. Если система отправляет разные сообщения об ошибках в ситуациях "неизвестного имени" или "неправильного пароля", то, основываясь на этой информации, атакующий может собрать довольно много имён Пользователей с этой системы и затем использовать эти имена для рассылки на них спама.
Для того, что бы настроить опцию Безопасность Входов, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Общее, затем на странице Прочее найдите панель Безопасность Входов:
Сервер CommuniGate Pro может временно блокировать все типы операций входа на сервер для Пользователя, у которого было слишком много неудачных попыток входа на Сервер. Панель Безопасность Входов, показанная выше, позволяет вам указать интервал времени и число неудачных попыток входа, которое пользователь (или пользователи) могут сделать до блокировки для этого Пользователя операций входа. Вход на Сервер будет разрешён для этого Пользователя спустя такой же интервал времени.
Обычно, для того, что бы контролировать работу Сервера CommuniGate Pro, наблюдать и обслуживать его, достаточно Пользователя Postmaster. Но вы также можете предоставить другим пользователям право администрировать Сервер CommuniGate Pro: например, вы можете предоставить Оператору право просмотра Журналов Работы Сервера, не предоставляя ему всех прав администрирования, имеющихся у Пользователя Postmaster.
Для того, что бы предоставлять другим пользователям требуемые Права Доступа, вы должны войти на Сервер как Postmaster или другой Пользователь, имеющий права "Может Всё".
Для того, что бы предоставить Пользователю права и/или забрать права, откройте для этого пользователя страницу Установки Пользователя, затем нажмите на ссылку Права Доступа. Появится страница с Правами Доступа.
На странице перечисляются все возможные Права Доступа, и отмечены те из них, которые предоставлены этому Пользователю.
Нижеперечисленные Права Доступа могут быть предоставлены только Пользователям из Главного Домена:
Нижеперечисленные Права Доступа могут быть предоставлены пользователю из любого домена:
Первоначально, пользователь Postmaster в главном домене имеет Права Доступа Может Всё.
Выберите требуемые Права Доступа и нажмите на кнопку Модифицировать.
Права Доступа хранятся в индивидуальном для каждого домена файле; этот файл Access.settings хранится в поддиректории директории домена. Это позволяет легко проверять, кому предоставлены права на Администрирование Сервера.
Если вы не планируете обслуживать мобильных пользователей, то, возможно, вы захотите ограничить доступ к данным Пользователей на Сервере. Используйте для этого следующую опцию Сетевые Адреса Клиентов на странице Установки->Сеть->Клиенты:
Когда модуль доступа принимает соединение с неуказанного в этом списке сетевого адреса, модуль отправляет клиентскому приложению сообщение об ошибке и соединение немедленно закрывается. Связь с остальным Интернетом будет использоваться только для целей Передачи Почты, обмена Сигналами Реального Времени и для HTTP доступа к Хранилищу файлов Пользователя.
Когда эта опция имеет значение Запретить, операция SMTP AUTH может использоваться, только если клиентская почтовая программа или сервер соединяются сетевого адреса, указанного в списке Сетевые Адреса Клиентов.
Когда эта опция имеет значение Запретить, любая из операций по обмену Сигналами, требующая аутентификации будет осуществляться, только если клиентское устройство или сервер установили соединение с сетевого адреса, указанного в списке Сетевые Адреса Клиентов.
Обратите внимание: До того, как вы выберите в этой опции значение Запретить, убедитесь, что сетевой адрес, которые вы используете в настоящее время, включён в список Сетевых Адресов Клиентов: в противном случае вы немедленно утратите доступ к Серверу даже через Веб Интерфейс Администратора.
Также вы можете установить ограничения на доступ к серверу на более низком уровне TCP-соединений. Для каждого сервиса (модуля), откройте страницу Приёмник и укажите адреса, с которых этот сервис (модуль) должен (или не должен) принимать соединения. Если соединение устанавливается с адреса, который не включён в число адресов, доступ с которых Разрешён, или этот адрес включён в число адресов, доступ с которых Запрещён, то соединение немедленно закрывается, и никаких операций на уровне модуля не выполняется.
Сервер CommuniGate Pro поддерживает возможность работы под чужими правами - особый режим входа на сервер, при котором одному Пользователю (Аутентифицированному Пользователю) предоставляются полномочия другого Пользователя (Авторизованного Пользователя).
Эта возможность также может использоваться для Регистраций Реального Времени.
Действия от чужого имени поддерживаются при работе с методами Аутентификации PLAN и GSSAPI.
При использовании Действия от чужого имени, Сервер проверяет, есть ли соответствующие полномочия у аутентифицированного пользователя, и разрешена ли для этого пользователя эта услуга. Он также проверяет, если ли у Аутентифицированного Пользователя Право Может выступать от имени других в Правах Доступа Домена.
Сервер CommuniGate Pro поддерживает специальный метод Аутентификации SessionID . В этом методе вместо пароля Пользователя используется идентификационный номер WebUser или XIMSS сессии.
Этот метод полезен для CGI-скриптов или программ.
По умолчанию, этот метод выключен (смотрите выше).
Этот метод является SASL-методом и требует "непосредственного" указания параметров в командах аутентификационного протокола. Первый параметр - это имя Пользователя, второй, отделённый пробелом, это идентификационный номер сессии.
Для PWD модуля операция аутентификации SESSIONID выглядит как:
Если у пользователя john@doe.dom открыта WebUser сессия с идентификационным номером 114-bXaKw92JK1pZVB5taj1r, то следующая команда PWD:
AUTH SESSIONID john@doe.dom 114-bXaKw92JK1pZVB5taj1r
откроет PWD сессию для пользователя john@doe.dom.