Безопасность

Сервер CommuniGate Pro поддерживает как незащищённые, так и безопасные методы SASL аутентификации для следующих сессионных протоколов TCP:

• POP (согласно RFC1734)
• IMAP (согласно RFC2060)
• LDAP (согласно RFC2251)
• ACAP (согласно RFC2244)
• SMTP (согласно RFC2554)
• FTP (согласно RFC2228)
• XMPP (согласно RFC3920)

Такие безопасные методы позволяют почтовым клиентам посылать зашифрованные пароли через нешифрованные и небезопасные каналы связи. Если кто-нибудь осуществляет мониторинг вашего сетевого трафика, то использование SASL методов обеспечит невозможность перехвата реальных паролей из трафика между клиентом и сервером.

В качестве альтернативы SASL методам, между сервером и почтовой программой может использоваться обмен информацией по безопасному (SSL/TLS) соединению. Когда SSL соединение установлено, весь сетевой трафик между сервером и клиентом шифруется, и через такие соединения пароли могут пересылаться в открытом виде.

Вы можете обязать Пользователя использовать либо безопасные методы аутентификации SASL, либо SSL/TLS соединения, если вы включите в Установках Пользователя опцию Аутентификация Только Безопасно. Когда эта опция включена, Сервер отвергает все запросы на аутентификацию, требующие переслать пароль в незащищённом виде через небезопасное соединение.

Сервер CommuniGate Pro поддерживает следующие небезопасные (незащищённые) методы SASL аутентификации:

• PLAIN
• LOGIN

Сервер CommuniGate Pro поддерживает следующие безопасные методы SASL аутентификации:

• CRAM-MD5
• DIGEST-MD5
• GSSAPI

Сервер CommuniGate Pro поддерживает следующие GSSAPI методы аутентификации:

• Kerberos V5
• NTLM

Сервер CommuniGate Pro поддерживает следующие SASL-EXTERNAL методы аутентификации:

• TLS-Certificate

Сервер CommuniGate Pro поддерживает нестандартные SASL методы NTLM и MSN, используемые в продуктах Microsoft®.

CommuniGate Pro поддерживает метод аутентификации APOP (преимущественно используемый для протокола POP), и небезопасный метод "обычного входа" для протоколов, которые поддерживают Незащищённый Вход.

Сервер CommuniGate Pro поддерживает специальный метод Аутентификации SessionID.

Используя Веб Интерфейс Администратора откройте страницу Установки Домена и найдите панель Способы Аутентификации:

Справка

Способы Аутентификации CLRTXT CRAM-MD5 DIGEST-MD5 APOP GSSAPI NTLM MSN SESSIONID

CLRTXT

Когда эта опция выбрана, сервер оповещает обо всех поддерживаемых небезопасных (незащищённых) Методах Аутентификации для этого Домена.

CRAM-MD5, DIGEST-MD5

Когда выбраны эти опции, Сервер оповещает о возможности использования CRAM-MD5 и DIGEST-MD5 безопасных методов аутентификации для этого Домена.
Не выбирайте эти опции, если Пользователи Домена используют пароли, зашифрованные односторонним образом, URI Аутентификации или другие способы, не поддерживающие безопасные методы аутентификации.

APOP

Когда выбрана эта опция, Сервер выдаёт специальный начальный запрос для POP и PWD соединений. Почтовые клиенты могут использовать этот запрос для использования безопасного метода аутентификации APOP.
Не выбирайте эту опцию если Пользователи Домена используют пароли, зашифрованные односторонним образом, URI Аутентификации или другие способы, не поддерживающие безопасные методы аутентификации.

GSSAPI

Когда эта опция выбрана, сервер оповещает обо всех поддерживаемых GSSAPI Методах Аутентификации.
Не выбирайте эту опцию, если в Домене не установлена поддержка GSSAPI методов (например, вы не указали необходимые Ключи Kerberos).

MSN, NTLM

Когда выбраны эти опции, Сервер оповещает о возможности использования для этого Домена нестандартных MSN и NTLM методов аутентификации (используемых в некоторых продуктах Microsoft).
Не выбирайте эти опции, если Пользователи Домена используют пароли, зашифрованные односторонним образом, URI Аутентификации или другие способы, не поддерживающие безопасные методы аутентификации.
Обратите внимание: В случаях, если в продуктах Microsoft Outlook для некоторых версий MacOS есть настройки для более чем одного пользователя, то эти продукты работают с методом MSN некорректно.
Обратите внимание: Некоторые продукты Microsoft отправляют неверные данные аутентификации, если они обнаруживают, что сервер поддерживает NTLM SASL метод. Хотя эти продукты впоследствии и пересылают корректные данные, закончившиеся неудачно попытки входа на сервер приводят к появлению в Журнале записей уровня Сбои и довольно быстро могут привести к увеличению счётчика "неудачных входов"; что, в свою очередь, может привести к временному блокированию попыток Пользователя входа на Сервер.

Эти опции Оповещения влияют только на услуги "сессионного" типа (SMTP, POP, IMAP, ACAP, PWD, FTP), и никак не оказывают никакого эффекта на услуги "транзакционного" типа (HTTP, SIP).
Эти опции Оповещения задают только то, как Сервер оповещает о доступных методах входа. Клиентские приложения могут использовать любые методы, даже если оповещение об их доступности со стороны Сервера было выключено.

SESSIONID

Эта опция активирует метод Аутентификации SessionID для этого Домена.

Сервер CommuniGate Pro может использовать несколько паролей для каждого пользователя.

Один пароль - это "собственный пароль" CommuniGate Pro. Этот пароль хранится как элемент в Установках Пользователя, и может использоваться только Сервером CommuniGate Pro.

Для Пользователя могут быть заданы дополнительные варианты внутреннего пароля с метками. При аутентификации с использованием этих паролей метка передаётся вместе с именем аккаунта через символ $: user$tag.

Для Пользователя можно задать URI Аутентификации. Он может использоваться для проверки пароля через внешний сервер LDAP с указанным DN аутентификации. Метод работает только с незащищёнными методами аутентификации.

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

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

В случае, когда для пользователя включено использование нескольких паролей, Сервер сначала проверяет CommuniGate-Пароль (внутренний), затем пароль на внешнем LDAP сервере, если задан URI Аутентификации, и только затем будет пытаться аутентифицировать пользователя Через Внешнюю Программу. Если хотя бы один из этих паролей получен от клиентского приложения, то этому приложению будет предоставлен доступ к Серверу.

Пароли 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-Пароль. Эта возможность может быть использована при миграции пользователей из действующих почтовых систем, когда у вас нет возможности создать список пользователей с незашифрованными паролями.

Cервер CommuniGate Pro поддерживает метод аутентификации пользователей через Kerberos. Методы Kerberos базируются на "билетах" ("ticket"). Клиентские приложения используют билеты для аутентификации доступа к службам сервера. Билеты зашифровываются с помощью "ключа" ("key") и выдаются Центрами Распространения Ключей (KDC), которые имеют общий ключ с сервером. Дополнительную информацию смотрите в документации по Kerberos.

Для поддержки аутентификации пользователей домена CommuniGate Pro через Kerberos необходимо для этого домена добавить ключ(и) Сервера Kerberos.

1) В базе данных KDC создайте "принципал" ("principal") для службы (протокола) сервера CommuniGate Pro, доступ к которой нужно аутентифицировать через Kerberos. В имени принципала используйте следующие значения параметров:

• В "основе" ("primary") укажите имя службы (протокола) CommuniGate Pro. Обычно названия протоколов указываются в нижнем регистре, например smtp, imap, но для протокола HTTP есть исключение, его имя указывается в верхнем регистре: HTTP.
• В "экземпляре" ("instance") укажите имя хоста, используемое для подключения к домену CommuniGate Pro. Это имя должно совпадать с именем домена CommuniGate Pro или с одним из его Псевдонимов.
• В "области" ("realm") укажите в верхнем регистре имя домена службы каталогов, в котором происходит аутентификация.

2) Экспортируйте ключ принципала в файл таблицы ключей ("keytab").

3) Через Веб Интерфейс Администратора откройте страницу Установки Домена, затем пройдите по ссылкам Безопасность и Kerberos. Будет показан список Kerberos Ключей Домена:

	Realm		Выдан	Версия	Тип
	REALM1.COM	(3)imap/domain1.com	19-05-2021 17:36:33	6	RC4-HMAC
	REALM1.COM	(3)imap/domain1.com	21-05-2021 17:32:35	9	DES-MD5
	REALM1.COM	(3)imap/domain1.com	24-05-2021 12:41:55	10	DES-MD5
	REALM1.COM	(3)imap/domain1.com	24-05-2021 17:33:27	13	DES-CRC32
		Загрузить Файл

Каждый Домен может иметь несколько Kerberos Ключей. Для того, чтобы добавить ключи из файла к Kerberos Ключам Домена, нажмите на кнопку Обзор (…), выберите файл keytab и нажмите на кнопку Импортировать Ключи.

Для удаления Ключей, отметьте ключи и нажмите на кнопку Удалить Помеченные.

Администраторы Домена могут Добавлять или Удалять Kerberos Ключи только если они имеют право доступа Kerberos Ключи.

Когда Сервер получает билет Kerberos, он извлекает экземпляр из имени принципала службы, указанного в билете. Экземпляр используется как имя целевого Домена (ticket-domain-name). Затем Сервер создаёт фиктивный адрес LoginPage@ticket-domain-name и пытается осуществить его маршрутизацию. Используется тот же механизм, что и для определения целевого Домена при доступе по HTTP.

Если целевой Домен найден, Сервер ищет в списке Ключей Kerberos этого Домена подходящий ключ (ключ, для которого имя принципала службы и тип шифрования, совпадают с указанными в билете). Если Ключ найден, и Билет может быть расшифрован с помощью этого Ключа; Аутентификатор может быть расшифрован полученным сессионным ключом и аутентификационная информация в нём верна, сервер извлекает основу из имени принципала пользователя. Основа используется как имя целевого Пользователя. Это имя должно быть "простым", то есть не должно содержать символов @ или %.

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

Если пользователь найден, и для этого пользователя Kerberos Аутентификация включена, сервер предоставляет доступ к ресурсам пользователя.

Интеграция с Microsoft Active Directory

Microsoft Active Directory может быть использована для Kerberos-аутентификации пользователей домена CommuniGate Pro. Выполните следующие действия:

• В DNS-зоне домена Active Directory создайте A-запись, указывающую на IP-адрес домена CommuniGate Pro.
• Добавьте полное имя хоста (FQDN) A-записи в псевдонимы домена CommuniGate Pro.
• В Active Directory создайте пользователя cgatepro (вы можете использовать и другое имя).
• На контроллере домена Active Directory используйте команду Microsoft ktpass для создания принципала службы и экспорта ключа:

ktpass -princ service/hostName@REALMNAME -mapuser cgatepro -pass key -out keytab.data -crypto encType -ptype KRB5_NT_SRV_HST

где

service

имя службы (протокола) сервера CommuniGate Pro: imap для IMAP и MAPI, smtp для SMTP, HTTP для веб-интерфейсов

hostName

Полное имя хоста для подключения к домену CommuniGate Pro

Обратите внимание: это же имя должно использоваться в клиентских приложениях

REALMNAME

полное имя домена Active Directory в верхнем регистре

key

ключ шифрования

encType

тип шифрования

Пример:

ktpass -princ imap/cgpro.ad-domain.dom@AD-DOMAIN.DOM -mapuser cgatepro -pass 12345678 -out imap.data -crypto All -ptype KRB5_NT_PRINCIPAL

Дополнительную информацию смотрите в документации по ktpass.

• Импортируйте получившийся файл keytab.data в Kerberos Установки Домена CommuniGate Pro, как указано выше.

Интеграция с FreeIPA

FreeIPA может быть использована для Kerberos-аутентификации пользователей домена CommuniGate Pro. Выполните следующие действия:

• В FreeIPA создайте хост с IP-адресом домена CommuniGate Pro.
• Добавьте полное имя хоста (FQDN) в псевдонимы домена CommuniGate Pro.
• Для хоста добавьте службы, соответствующие службам (протоколам) CommuniGate Pro, или добавьте псевдонимы принципалов.
• Используйте команду ipa-getkeytab для экспорта ключа:

ipa-getkeytab -s FreeIPA-hostName -p service/CGPro-hostName -e encType -k keytab.data -P

где

FreeIPA-hostName

Полное имя хоста FreeIPA

service

имя службы (протокола) сервера CommuniGate Pro: imap для IMAP и MAPI, smtp для SMTP, HTTP для веб-браузеров

CGPro-hostName

Полное имя хоста для подключения к домену CommuniGate Pro

Обратите внимание: это же имя должно использоваться в клиентских приложениях

encType

тип шифрования

Пример:

ipa-getkeytab -s freeipa.ipadom.dom -p imap/cgpro.ipadom.dom -e arcfour-hmac -k imap.data -P

Дополнительную информацию смотрите в документации по ipa-getkeytab.

• Импортируйте получившийся файл keytab.data в Kerberos Установки Домена CommuniGate Pro, как указано выше.

Сервер CommuniGate Pro поддерживает проверку паролей методом запроса по LDAP URI, когда URI имеет вид ldap(s)://address[:port]/parameters. Метод использует отправку запроса BIND по протоколу LDAP на сервер по адресу address[:port] с DN аутентификации, построенном по значению parameters и паролем, полученным сервером CommuniGate Pro в аутентифицирующейся сессии доступа. При использовании этого способа между клиентом и сервером CommuniGate Pro могут быть использованы только методы с передачей пароля открытым текстом. Если внешний LDAP положительно отвечает на запрос BIND с BIND DN, построенным из части parameters URI, то соединение Пользователя аутентифицируется.

Символ звёздочка (*) в строке parameters заменяется на имя Пользователя CommuniGate Pro, а комбинация ^0 заменяется на имя Домена CommuniGate Pro.

Внимание: при использовании в качестве LDAP сервера Microsoft Active Directory в части parameters можно передать строку вида DOMAIN\account или account@domain.dom, где DOMAIN - короткое имя домена Windows, domain.dom - полное имя домена Windows, а account является значением атрибута sAMAccountName записи в AD.

Примеры:

ldap://10.0.0.2:389/*@^0

ldaps://dc.ad-domain.dom:636/*@ad-domain.dom

ldap://10.0.0.2:389/AD-DOMAIN\*

Сервер CommuniGate Pro поддерживает методы аутентификации, использующие Сертификат Клиента. Это метод может использоваться, когда клиенты устанавливают соединения с Сервером через безопасные SSL/TLS соединения. Сервер может затребовать от клиента предоставления Сертификата Клиента (установленного на компьютере клиента), подписанного Доверенным Сертификатом, выбранным Сервером для требуемого Домена.

Если клиент отправляет такой сертификат, то адрес электронной почты, указанный в элементе subjectAltName Сертификата (если есть) или в поле электронной почты в элементе Subject может быть использован для Аутентификации по Сертификату. Этот адрес интерпретируется как имя Пользователя, который должен войти на сервер CommuniGate Pro.

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

Сервер будет предоставлять доступ к ресурсам только тем Пользователям, для которых Аутентификация По Сертификату включена.

Дополнительную информацию смотрите в разделе PKI.

Сервер CommuniGate Pro может использовать программу Внешнего Помощника для аутентификации пользователей. Эта программа создаётся вашим техническим персоналом и в ней реализуются требуемые для вашего сайта механизмы аутентификации, напрямую не поддерживаемые Сервером CommuniGate Pro.

Программа Внешней Аутентификации может использоваться также для:

• автоматического создания Пользователей на основании каких-либо данных из внешних источников
• помощи в операциях Маршрутизатора
• помощи в управлении Пользователями.

Имя программы для Внешней Аутентификации и её дополнительные параметры задаются через Веб Интерфейс Администратора на странице Помощники. Через Веб Интерфейс Администратора откройте в области Установки страницу Помощники:

Внешняя Аутентификация
Уровень Журнала:	КатастрофыСбоиОсновноеПроблемыПодробностиВсё	Путь к Программе:
Тайм-аут:	Никогда15 сек30 секминуту2 мин3 мин5 мин10 мин15 мин30 минчас	Авторестарт:	Никогда5 сек7 сек10 сек15 сек30 секминуту2 мин3 мин5 мин10 мин15 мин30 минчас2 час.3 час.6 час.

Подробно эти опции описываются в разделе Программы-Помощники.

Записи, помещаемые в Системный Журнал Сервера модулем Внешней Аутентификации, имеют метку EXTAUTH.

Если программа, осуществляющая Внешнюю Аутентификацию, не запущена, то все запросы на Внешнюю Аутентификацию отвергаются.

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

С примером программы и сценариев для Внешней Аутентификации можно ознакомиться на сайте CommuniGate Systems в разделе Помощники для Аутентификации.

Некоторые спаммеры используют "атаку грубой силой" на почтовые системы, отправляя случайные имена и пароли на POP, IMAP и другие порты доступа. Если система отправляет разные сообщения об ошибках в ситуациях "неизвестного имени" или "неправильного пароля", то, основываясь на этой информации, атакующий может собрать довольно много имён Пользователей с этой системы и затем использовать эти имена для рассылки на них спама.

Для того, чтобы настроить опцию Безопасность Входов, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Общее, затем на странице Прочее найдите панель Безопасность Входов:

Безопасность Входов
	Прятать сообщения 'Неизвестное имя'

Прятать сообщения Неизвестное имя

Если эта опция включена, то Сервер не будет отправлять сообщения Неизвестное имя и Неверный Пароль. Вместо этих обоих сообщений будет отправляться сообщение Неверное имя пользователя или пароль.

Сервер CommuniGate Pro может временно блокировать все типы операций входа на сервер для Пользователя, у которого было слишком много неудачных попыток входа на Сервер. Эта настройка Пользователя позволяет указать интервал времени и число неудачных попыток входа, которое пользователь (или пользователи) могут сделать до блокировки для этого Пользователя. Вход на Сервер будет разрешён для этого Пользователя спустя такой же интервал времени.

Обычно, для того, чтобы контролировать работу Сервера CommuniGate Pro, наблюдать и обслуживать его, достаточно Пользователя Postmaster. Но вы также можете предоставить другим пользователям право администрировать Сервер CommuniGate Pro: например, вы можете предоставить Оператору право просмотра Журналов Работы Сервера, не предоставляя ему всех прав администрирования, имеющихся у Пользователя Postmaster.

Для того, чтобы предоставлять другим пользователям требуемые Права Доступа, вы должны войти на Сервер как Postmaster или другой Пользователь, имеющий права "Может Всё".

Чтобы предоставить Пользователю права и/или забрать права, откройте для этого пользователя страницу Установки Пользователя, затем нажмите на ссылку Права Доступа. Появится страница с Правами Доступа.

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

Нижеперечисленные Права Доступа могут быть предоставлены только Пользователям из Главного Домена:

Может Всё (право Мастер)

Если пользователю предоставлено это право, он имеет полный доступ ко всем компонентам Сервера.

Может менять установки Сервера (право Настройки)

Это право позволяет пользователю изменять конфигурацию всех модулей и компонентов CommuniGate Pro (SMTP, POP, Маршрутизатор и т.д.))

Может менять установки Справочника (право Справочник)

Это право позволяет пользователю изменять конфигурацию системного Справочника

Может менять установки Всех Доменов и Пользователей (право Все Пользователи)

Эта настройка указывает, может ли пользователь создавать, переименовывать и удалять Домены, Пользователей и другие Объекты, а также изменять Установки Доменов, Пользователей и других Объектов.

Может наблюдать за Сервером (право Наблюдать)

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

Нижеперечисленные Права Доступа могут быть предоставлены пользователю из любого домена:

Может менять установки Этого Домена и его Пользователей:

Эта настройка указывает, может ли пользователь создавать, переименовывать и удалять других Пользователей в своём собственном Домене, а также изменять некоторые Установки Домена. Обычно вы предоставляете такие права пользователю ("хозяину домена"), который будет обслуживать этот домен.

Первоначально, пользователь Postmaster в главном домене имеет Права Доступа Может Всё.

Выберите требуемые Права Доступа и нажмите на кнопку Модифицировать.

Права Доступа хранятся в индивидуальном для каждого домена файле; этот файл Access.settings хранится в поддиректории директории домена. Это позволяет легко проверять, кому предоставлены права на Администрирование Сервера.

Сервер CommuniGate Pro поддерживает возможность работы под чужими правами - особый режим входа на сервер, при котором одному Пользователю (Аутентифицированному Пользователю) предоставляются полномочия другого Пользователя (Авторизованного Пользователя).
Эта возможность также может использоваться для Регистраций Реального Времени.

Действия от чужого имени поддерживаются при работе с методами Аутентификации PLAIN и GSSAPI.

При использовании Действия от чужого имени, Сервер проверяет, есть ли соответствующие полномочия у аутентифицированного пользователя, и разрешена ли для этого пользователя эта услуга. Он также проверяет, если ли у Аутентифицированного Пользователя Право Может выступать от имени других в Правах Доступа Домена.

Сервер CommuniGate Pro поддерживает специальный метод Аутентификации SessionID. В этом методе вместо пароля Пользователя используется идентификационный номер WebUser или XIMSS сессии.
Этот метод полезен для CGI-скриптов или программ.
По умолчанию, этот метод выключен (смотрите выше).

Этот метод является SASL-методом и требует "непосредственного" указания параметров в командах аутентификационного протокола. Первый параметр - это имя Пользователя, второй, отделённый пробелом, это идентификационный номер сессии.
Для PWD модуля операция аутентификации SESSIONID выглядит как:

AUTH SESSIONID userName session-ID

Для IMAP модуля операция аутентификации SESSIONID выглядит как:

AUTHENTICATE SESSIONID bindata
где bindata это следующие данные, закодированные в base64:

userName session-ID

Если у пользователя john@doe.dom открыта WebUser сессия с идентификационным номером 114-bXaKw92JK1pZVB5taj1r, то следующая команда PWD:
AUTH SESSIONID john@doe.dom 114-bXaKw92JK1pZVB5taj1r
откроет PWD сессию для пользователя john@doe.dom.

Пользователь - владелец ресурса может предоставить определённые права другим пользователям: право доступа к определённым Папкам, право управлять настройками ТфОП и т.д.

Каждый элемент в Списке Прав Доступа содержит имя и набор прав доступа, предоставляемых этому имени.

Имя элемента ACL может быть:

null@null

Этот элемент ACL задаёт права доступа, предоставляемые "гостям" (всем неаутентифицированным пользователями).

anyone

Этот элемент ACL задаёт права доступа, предоставляемые каждому (всем аутентифицированным пользователями).

anyone@

Этот элемент ACL задаёт права доступа, предоставляемые всем Пользователям из этого же домена CommuniGate Pro.

anyone@domainName

Этот элемент ACL задаёт права доступа, предоставляемые всем Пользователям CommuniGate Pro из Домена domainName. Имя domainName должно быть настоящим именем Домена и не может быть Псевдонимом Домена.

accountName

Этот элемент ACL задаёт права доступа, предоставляемые Пользователю accountName в том же Домене CommuniGate Pro. Имя accountName должно быть настоящим именем Пользователя и не может быть Псевдонимом Пользователя или Переадресатором.

accountname@domainname

Этот элемент ACL задаёт права доступа, предоставляемые Пользователю CommuniGate Pro из другого Домена. Имя domainName должно быть настоящим именем Домена и не может быть Псевдонимом Домена.

#groupName

Этот элемент ACL задаёт права доступа, предоставляемые всем участникам Группы groupName (из того же Домена).

#groupName@domainName

Этот элемент ACL задаёт права доступа, предоставляемые всем участникам Группы groupName из другого Домена в CommuniGate Pro. Имя domainName должно быть настоящим именем Домена и не может быть Псевдонимом Домена.

Имя элемента ACL может иметь префиксы + или -.

Пользователи - владельцы всегда имеют полные Права Доступа ко всем своим объектам (Папкам, функциям).

Для любого другого Пользователя someaccount проверяются действующие права доступа.

Действующие права доступа вычисляются в несколько шагов:

• Если существует элемент ACL для имени someaccount (без префиксов + или -), то в качестве действующего права доступа используется право Доступа, указанной в этом элементе ACL.
  Иначе,
• Все элементы ACL без префиксов + или -, соответствующие имени someaccount объединяются для формирования "прямых" прав доступа.
• Все элементы ACL соответствующие имени someaccount с префиксом - объединяются для формирования "убираемых" прав доступа.
• Все элементы ACL соответствующие имени someaccount с префиксом + объединяются для формирования "добавляемых" прав доступа.
• "Убираемые" права доступа удаляются из "прямых" прав доступа.
• "Добавляемые" права доступа объединяются с "прямыми" правами доступа.
• Получившиеся "прямые" права доступа используются как действующие права доступа.

При предоставлении прав доступа, должны использоваться настоящие имена Пользователей, а не Псевдонимы. Если Пользователь j.smith имеет два псевдонима john.smith и jonny, то право доступа должно предоставляться для имени j.smith.

Примеры:

Предоставление прав доступа Видеть, Входить, Читать для всех пользователей из этого же Домена, кроме пользователя John, который имеет только право Видеть, и пользователя Susan, которая должна иметь права Видеть, Входить, Читать и Удалять:

anyone@		Видеть, Входить, Читать
-john		Входить, Читать
+susan		Удалить

Предоставление прав доступа Видеть, Входить, Читать для всех пользователей из другого Домена company2.com, кроме пользователя john@company2.com, который не должен иметь прав доступа вообще, и пользователя Susan из третьего домена company3.com, которая должна иметь права Видеть, Входить и Удалять.

anyone@company2.com		Видеть, Входить, Читать
-john@company2.com		Видеть, Входить, Читать
susan@company3.com		Видеть, Входить, Удалить

Список Прав Доступа может задаваться и изменяться через Веб Интерфейс Пользователя, XIMSS, MAPI или подходящий IMAP клиент.