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

Сервер CommuniGate Pro обеспечивает доступ к определённым ресурсам только для определённых пользователей.

Сервер CommuniGate Pro может аутентифицировать своих пользователей, а также он может отвергать соединения, устанавливаемые извне «клиентской сети».

Методы аутентификации

Сервер 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

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

APOP

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

GSSAPI

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

MSN, NTLM

Когда выбраны эти опции, сервер оповещает о возможности использования для этого домена нестандартных MSN и NTLM-методов аутентификации (используемых в некоторых продуктах Microsoft).
Не выбирайте эти опции, если пользователи домена используют пароли, зашифрованные односторонним образом, пароли из ОС или другие способы, не поддерживающие безопасные методы аутентификации.

Обратите внимание: в случаях, если в продуктах Microsoft Outlook для некоторых версий MacOS есть настройки для более чем одного пользователя, то эти продукты работают с методом MSN некорректно.

Обратите внимание: некоторые продукты Microsoft отправляют неверные данные аутентификации, если они обнаруживают, что сервер поддерживает NTLM SASL-метод. Хотя эти продукты впоследствии и пересылают корректные данные, закончившиеся неудачно попытки входа на сервер приводят к появлению в журнале записей уровня «сбои» и довольно быстро могут привести к увеличению счётчика «неудачных входов»; что, в свою очередь, может привести к временному блокированию попыток пользователя входа на сервер.

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

SESSIONID

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

Пароли пользователя

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

Один пароль — это «собственный пароль» CommuniGate Pro. Этот пароль хранится как элемент в установках пользователя, и может использоваться только сервером CommuniGate Pro.

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

Другой пароль — это «пароль из ОС». Пользователь может быть зарегистрирован в ОС сервера и сервер CommuniGate Pro может сверять полученный пароль с паролем, используемым этим пользователем для входа в ОС.

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

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

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

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

Пароли CommuniGate Pro

Пароли 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.

Пароль из ОС являются односторонне зашифрованными паролями. Как следствие, они не могут использоваться для методов безопасной аутентификации.

Аутентификация Kerberos

Сервер 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-аутентификация включена.

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

Возможно, вам потребуется, чтобы Microsoft Active Directory выступала в роли центра распространения Kerberos ключей (KDC). Выполните следующие действия:

• создайте в Active Directory пользователя cgatepro (вы можете использовать и другое имя)

Используйте команду Microsoft ktpass для экспорта ключей:

ktpass -princ service/domainName@REALMNAME -mapuser cgatepro -pass password -out keytab.data -crypto RC4-HMAC-NT -ptype KRB5_NT_SRV_HST

где

service

это имя сервиса в CommuniGate Pro, который вам необходимо использовать: imap для IMAP и MAPI, HTTP для веб-браузеров

domainName

это имя домена CommuniGate Pro (или его алиас), в который должен предоставляться доступ пользователям Kerberos. Клиентские приложения используют это имя как имя хоста для соединения.

REALMNAME

это имя Realm в Kerberos — имя домена Active Directory, с которым вы хотите аутентифицироваться

password

пароль пользователя cgatepro.

Обратите внимание: из-за ошибок в реализации Active Directory в Windows 2000, при использовании команды ktpass рекомендуется указывать параметр -kvno 0.

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

Более подробную информацию вы можете прочитать в базе знаний 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 или другой пользователь, имеющий права «может всё».

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

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

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

Может всё (право «мастер»)

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

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

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

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

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

Может менять установки всех доменов и пользователей (право «все пользователи»)

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

Может наблюдать за сервером (право «наблюдать»)

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

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

Может менять установки этого домена и его пользователей:

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

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

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

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

Ограничение доступа

Если вы не планируете обслуживать мобильных пользователей, то, возможно, вы захотите ограничить доступ к данным пользователей на сервере. Используйте для этого следующую опцию «сетевые адреса клиентов» на странице Установки->Сеть->Клиенты:

Вход с не-Клиентских Адресов

Когда эта опция имеет значение «запретить», все операции «входа» (необходимые для POP, IMAP, SIP, XMPP, веб-интерфейса пользователя, ACAP, PWD и т.д.) осуществляются только с компьютера, на котором работает сервер и с сетевых адресов клиентов.

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

Когда эта опция имеет значение «запретить», операция SMTP AUTH может использоваться, только если клиентская почтовая программа или сервер соединяются с сетевого адреса, указанного в списке сетевые адреса клиентов.

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

Также вы можете установить ограничения на доступ к серверу на более низком уровне TCP-соединений. Для каждого сервиса (модуля), откройте страницу «приёмник» и укажите адреса, с которых этот сервис (модуль) должен (или не должен) принимать соединения. Если соединение устанавливается с адреса, который не включён в число адресов, доступ с которых «разрешён», или этот адрес включён в число адресов, доступ с которых «запрещён», то соединение немедленно закрывается, и никаких операций на уровне модуля не выполняется.

Действия от чужого имени

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

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

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

Метод Аутентификации через SessionID

Сервер 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)

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

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

Имя элемента 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, которая должна иметь права видеть, входить, читать и удалять:

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

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