Доступ к данным Пользователей

Каждый пользователь может получать доступ к CommuniGate Pro через различные модули доступа - POP, IMAP, XIMSS, Веб Интерфейс Пользователя, FTP, XMPP и т.д. Несколько приложений могут работать с информацией пользователя в одно и то же время, используя как один и тот же, так и разные модули доступа или услуг.

Доступ к любой Папке любого Пользователя в CommuniGate Pro может быть совместным: то есть, доступ к папке может быть предоставлен не только пользователю-владельцу этой папки, но также и другому пользователю, при условии, что сам пользователь или Администратор предоставили другим пользователям соответствующие права.

Основной проблемой при обслуживании нескольких доменов на одном сервере является предоставление доступа пользователям в различных доменах. Чтобы найти пользователя с указанным именем, сервер должен получить имя домена, в котором его следует искать.
Доступ производится аналогично доставке сообщений или обработке Сигналов: сервер должен знать "полное имя пользователя" - адрес в форме accountname@domainname.

Существует несколько способов передачи имени домена серверу:

• Клиентское приложения указывает имя домена в явном виде.
  • Если пользователь получает доступ к Серверу через HTTP (Веб Интерфейс), это происходит автоматически, так как сначала пользователь указывает URL сервера (http://domainname:port), а затем вводит имя пользователя в специальной регистрационной форме.
    Так как все современные браузеры передают оригинальный URL серверу, то имя домена становится известным Серверу и Модуль HTTP сразу добавляет имя домена к простому имени пользователя, введённому в регистрационной форме.
  • Если пользователь получает доступ к Серверу через XMPP, это происходит автоматически: пользователь указывает имя сервера в настройках клиентского приложения, а клиентское приложение посылает эти данные в атрибуте 'to' потока XML.
  • Если пользователь получает доступ к Серверу через почтовую программу, работающую по протоколу POP или IMAP, то он может в настройках почтовой программы указать полное имя в соответствующем поле "имя пользователя".
    Многие почтовые программы не допускают использования символа @ в поле "имя пользователя"; в таких случаях вместо него можно использовать символ %.
    Для доступа к аккаунту john в дополнительном домене client1.com пользователь должен указать имя пользователя в виде john%client1.com, а не просто john.
  • Если пользователь получает доступ к Серверу через клиентское приложение, работающее по протоколу XIMSS, то это приложение для целей аутентификации всегда использует полное имя пользователя.

• Имя домена может быть обнаружено косвенным образом, на основании информации об IP адресе, на который было осуществлено соединение. Если пользователи получают доступ к Серверу не только через Веб Интерфейс и не указывают полное имя пользователя в настройках почтовой программы POP/IMAP, то для определения имени домена может быть использована информация об IP адресах, обслуживаемых Сервером.
  Сервер обслуживает несколько IP адресов, если он имеет более одного Интернет (IP) адреса. В DNS добавочным доменам могут быть назначены отдельные IP адреса.
  Если добавочный домен имеет свой IP адрес, и пользователь устанавливает соединение на этот IP адрес, то все простые имена пользователя, указанные в почтовой программе пользователя, интерпретируются как простые имена из этого добавочного домена.
  Назначение отдельного IP адреса для каждого домена может быть довольно трудоёмкой процедурой, однако этот метод должен использоваться, если невозможно заставить пользователя указывать явно имя домена.

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

Каждая сессия доступа к Серверу начинается с процедуры аутентификации: клиентское приложение посылает на Сервер имя пользователя и пароль.

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

• Если указанное имя содержит символ @ или символ %, то Сервер рассматривает указанное пользователем имя как "полное имя аккаунта", то есть имя Пользователя (или другого Объекта) вместе с именем домена: username@domainname или username%domainname (смотрите выше).
• Если указанное имя не содержит символа @ или символа %, то для определения имени домена Сервер использует IP адрес, на который установлено соединение.
  В системах с несколькими IP адресами определённые IP адреса могут быть назначены некоторым Доменам. Если IP адрес, с которым установлено соединение, соответствует некоторому домену, то имя этого домена будет добавлено к имени пользователя для формирования полного имени пользователя. Если адрес соответствует Главному Домену, то указанное имя считается именем в главном Домене.
  По умолчанию, все IP адреса Сервера соответствуют Главному Домену.

Пример:

Сервер имеет 2 IP адреса: 192.0.0.1 и 192.0.0.2.
Главный домен сервера company.com, а добавочные домены client1.com и client2.com.
A-запись в DNS для домена company.com указывает на IP адрес 192.0.0.1,
A-запись для домена client1.com указывает на IP адрес 192.0.0.2, а A-запись для домена client2.com указывает на тот же самый "главный" IP address 192.0.0.1.
В каждом домене есть пользователь с именем info.

Три пользователя настроили свои клиентские программы для доступа к аккаунту info, но они указали разное значение настройки "сервер": первый ввёл company.com, второй - client1.com, а третий пользователь - client2.com.

Когда первый пользователь запускает свою почтовую программу:

• Клиентское приложение берет указанный в настройке "сервер" company.com, и использует A-запись в DNS для преобразования этого имени в IP-адрес 192.0.0.1.
• Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя аккаунта info.
• Сервер определяет, что указано простое имя аккаунта info и соединение установлено через адрес 192.0.0.1.
• Сервер определяет, что этот IP адрес соответствует Главному Домену и добавляет имя Главного Домена company.com к указанному простому имени.
• Сервер формирует корректное полное имя пользователя info@company.com.

Когда второй пользователь запускает своё клиентское приложение:

• Клиентское приложение берет указанный в настройке "сервер" client1.com, и использует A-запись в DNS для преобразования этого имени в IP-адрес 192.0.0.2.
• Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info.
• Сервер определяет, что указано простое имя пользователя info и соединение установлено через адрес 192.0.0.2.
• Сервер определяет, что этот IP адрес соответствует домену client1.com и добавляет имя этого домена к указанному простому имени.
• Сервер формирует корректное полное имя пользователя info@client1.com.

Когда третий пользователь запускает своё клиентское приложение:

• Клиентское приложение берёт указанный в настройке "сервер" client2.com и использует A-запись в DNS для того, чтобы преобразовать это имя в IP адрес 192.0.0.1.
• Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info.
• Сервер определяет, что указано простое имя пользователя info и соединение установлено через адрес 192.0.0.1.
• Сервер определяет, что этот IP адрес соответствует Главному Домену и добавляет имя Главного Домена company.com к указанному простому имени.
• Сервер формирует некорректное полное имя пользователя info@company.com.

Это происходит, потому что клиентское приложение (обычно - старый POP или IMAP почтовый клиент, FTP клиент и тому подобное) не передал информацию об имени "сервера", указанную в его настройках, и единственной информацией, которой располагал Сервер для определения полного имени аккаунта, был IP адрес соединения.

Чтобы решить эту проблему, третий пользователь должен указывать имя пользователя в виде info%client2.com, а не просто info. В этом случае, когда пользователь запускает своё клиентское приложение:

• Клиентское приложение берёт указанный в настройке "сервер" client2.com и использует A-запись в DNS для того, чтобы преобразовать это имя в IP адрес 192.0.0.1.
• Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info%client2.com.
• Сервер определяет, что указанно полное имя пользователя info%client2.com и не обращает внимания на IP адрес. Он конвертирует символ % в символ @.
• Сервер формирует корректное полное имя пользователя info@client2.com.

Обратите внимание: большинство FTP клиентов работает аналогично почтовым программам, использующим POP/IMAP и, в тех случаях, когда FTP пользователь не используют для установления соединения выделенный для его домена IP адрес, он должен будет указывать полное имя пользователя.

Обратите внимание: MAPI Коннектор всегда посылает полное имя пользователя: если пользователь указывает имя без знака @ или %, Коннектор добавляет к указанному имени знак '@' и значение, указанное в настройке Имя сервера.

Обратите внимание: XMPP клиенты отправляют имя 'домена пользователя' вместе с именем пользователя. Если указанное имя пользователя не содержит символов @ или %, то Сервер добавляет символ '@' и имя домена к имени пользователя.

После того, как полное имя пользователя сформировано, это имя (адрес) передаётся в Маршрутизатор.

• Если Маршрутизатор сообщает об ошибке, клиент не считается аутентифицированным и сообщение об ошибке возвращается клиентскому приложению. Обычная ошибка - Unknown user, но встречаются и другие, которые Маршрутизатор или другие модули могут выдать при преобразовании адреса.
• Если Маршрутизатор успешно обработал адрес и в результате этой обработки адрес не подлежит направлению в модуль Местной Доставки, то клиент не аутентифицируется и клиентскому приложению направляется сообщение об ошибке. Это случается, если пользователь указал в качестве имени аккаунта имя списка рассылки или указанное имя пользователя, согласно правилам маршрутизации, должно перенаправляться на другой хост (например, по протоколу SMTP).
• Если Маршрутизатор направляет адрес на какого-нибудь Пользователя в некотором локальном домене, то происходит открытие доступа к этому Пользователю, и осуществляется проверка пароля этого Пользователя.

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

Пример:

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

Пример:

Пользователь john был переведён из главного домена company.com в домен client1.com, и был переименован в j.smith. Администратор создал правило маршрутизации (запись в Маршрутизаторе):
<john> = j.smith@client1.com;
все сообщения и Сигналы, адресованные на john@company.com будут посылаться в аккаунт j.smith в домене client1.com;
пользователь все ещё может указывать в своём клиентском приложении john в настройке "имя пользователя" и company.com в настройке "сервер" - но Сервер будет работать с ним как с пользователем j.smith в домене client1.com.

Обратите внимание:

не создавайте никакие правила маршрутизации (записи в Маршрутизаторе), которые перенаправляют пользователя postmaster Главного Домена. Вы можете оказаться не в состоянии управлять настройками Сервера, если имя пользователя postmaster перенаправлено в Пользователя, не обладающего необходимыми Правами администратора Master.
Если вы хотите, чтобы все сообщения и Сигналы для аккаунта Postmaster перенаправлялись бы на другой адрес, используйте для этого не Маршрутизатор, а Правила для пользователя postmaster.