• автоматичного створення користувачів на підставі будь-яких даних із зовнішніх джерел
• допомоги в операціях маршрутизатора
• допомоги в управлінні Користувачами.

Ім'я програми для Зовнішньої Аутентифікації і її додаткові параметри задаються через Веб Інтерфейс Адміністратора на сторінці Помічники. Через Веб Інтерфейс Адміністратора відкрийте в області Установки сторінку Помічники:

Детально ці опції описуються в розділі Програми-Помічники .

Адреса, на яку в Системний Журнал Сервера модулем Зовнішньої Аутентифікації, мають мітку EXTAUTH.

Якщо програма, що здійснює Зовнішню Аутентифікацію, не запущено, то всі запити на Зовнішню Аутентифікацію відкидаються.

Для того, щоб створити власну програму для Зовнішньої Аутентифікації, ознайомтеся в розділі помічники з описом інтерфейсу і протоколу для Зовнішньої Аутентифікації.

З прикладом програми і сценаріїв для Зовнішньої Аутентифікації можна ознайомитися на сайті CommuniGate Systems в розділі Помічники для Аутентифікації .

Деякі спамери Використовують "атаку грубою силою" на поштові системи, відправляючі віпадкові імена и паролі на POP, IMAP и інші порти доступу. Якщо система відправляє різні повідомлення про помилки в ситуаціях "невідомого імені" або "неправильного пароля", то, грунтуючись на цій інформації, атакуючий може зібрати досить багато імен користувачів з цієї системи і потім використовувати ці імена для розсилки на них спаму.

Для того, щоб налаштувати опцію Безпека Входів, використовуйте Веб Інтерфейс Адміністратора. Відкрийте в області Установки сторінку Загальна, потім на сторінці Інше знайдіть панель Безпека Входів:

Сервер CommuniGate Pro може тимчасово блокувати всі типи операцій входу на сервер для Користувача, у якого було занадто багато невдалих спроб входу на сервер. ця настройка Користувача дозволяє вказати інтервал часу і число невдалих спроб входу, яке користувач (або користувачі) можуть зробити до блокування для цього Користувача. Вхід на Сервер буде дозволений для цього Користувача через такий же інтервал часу.

Зазвичай, для того, щоб контролювати роботу Сервера CommuniGate Pro, спостерігати і обслуговувати його, досить Користувача Postmaster. Але ви також можете надати іншим користувачам право адмініструвати Сервер CommuniGate Pro: наприклад, ви можете надати Оператору право перегляду Журналів Роботи Сервера, котрі дають йому всіх прав адміністрування, наявних у Користувача Postmaster.

Для того, щоб надавати іншим користувачам необхідні Права Доступу, ви повинні увійти на Сервер як Postmaster або інший Користувач, який має права "Може Все".

Щоб надати Користувачеві права і / або забрати права, відкрийте для цього користувача сторінку установки Користувача , Потім натисніть на лінк Права Доступу. З'явиться сторінка з Правами Доступу.

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

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

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

Спочатку, користувач Postmaster в головному домені має Права Доступу Може Все.

Виберіть необхідні Права Доступу та натисніть на кнопку Модифікувати.

Права Доступу зберігаються в індивідуальному для кожного домена файлі; цей файл Access.settings зберігається в піддиректорії директорії домену. Це дозволяє легко перевіряти, кому надані права на Адміністрування Сервера.

Якщо ви не плануєте обслуговувати мобільних користувачів, то, можливо, ви захочете обмежити доступ до даних користувачів на Сервері. Використовуйте для цього наступну опцію Мережеві Адреси Клієнтів на сторінці Установки-> Мережа-> Клієнти:

Коли модуль доступу приймає з'єднання з невизначеного в цьому списку мережевого адреси, модуль відправляє клієнтського додатку повідомлення про помилку і з'єднання негайно закривається. Зв'язок з іншим Інтернетом буде використовуватися тільки для цілей передачі Пошти , обміну сигналами Реального Часу і для HTTP доступу до сховища файлів Користувача.

Коли ця опція має значення Заборонити, операція SMTP AUTH може використовуватися, тільки якщо клієнтська поштова програма або сервер з'єднуються з мережевої адреси, вказаної в списку Мережеві Адреси Клієнтів.

Коли ця опція має значення Заборонити, будь-яка з операцій з обміну Сигналами, що вимагає аутентифікації буде здійснюватися, тільки якщо клієнтський пристрій або сервер встановили з'єднання з мережевої адреси, вказаної в списку Мережеві Адреси Клієнтів.
Зверніть увагу: До того, як ви оберете в опцію в положення Заборонити, переконайтеся, що мережеву адресу, які ви використовуєте в даний час, включений в список Мережевих Адрес Клієнтів: в іншому випадку ви негайно втратите доступ до Сервера навіть через Веб Інтерфейс Адміністратора.

Також ви можете встановити обмеження на доступ до сервера на більш низькому рівні TCP-з'єднань. Для кожного сервісу (модуля), відкрийте сторінку приймач і вкажіть адреси, з яких цей сервіс (модуль) повинен (або не повинен) приймати з'єднання. Якщо з'єднання встановлюється з адреси, яка не включений в число адрес, доступ з яких Дозволено, або ця адреса включений в число адрес, доступ з яких Заборонено, то з'єднання негайно закривається, і ніяких операцій на рівні модуля не виконується.

Сервер CommuniGate Pro підтримує можливість роботи під чужими правами - особливий режим входу на сервер, при якому одному користувачеві (аутентифицироваться Користувачеві) надаються повноваження іншого Користувача (Авторизованого Користувача).
Ця можливість також може використовуватися для Реєстрацій Реального Часу .

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

При використанні Дії від чужого імені, Сервер перевіряє, чи є відповідні повноваження у аутентифицированного користувача, і чи дозволено для цього користувача ця послуга. Він також перевіряє, чи є у аутентифицироваться Користувача Право Може виступати від імені інших в Права Доступу Домену .

Сервер CommuniGate Pro підтримує спеціальний метод Аутентифікації SessionID. У цьому методі замість пароля Користувача використовується ідентифікаційний номер WebUser або XIMSS сесії.
Цей метод корисний для CGI -скріптов або програм.
За замовчуванням, цей метод вимкнений (дивіться вище).

Цей метод є SASL-методом і вимагає "безпосереднього" вказівки параметрів у командах аутентификационного протоколу. Перший параметр - це ім'я Користувача, другий, відокремлений прогалиною, це ідентифікаційний номер сесії.
Для PWD модуля операція аутентифікації SESSIONID виглядає як:

Якщо у користувача [email protected] відкрита WebUser сесія з ідентифікаційним номером 114-bXaKw92JK1pZVB5taj1r, то наступна команда PWD:
AUTH SESSIONID [email protected] 114-bXaKw92JK1pZVB5taj1r
відкриє PWD сесію для користувача [email protected].

Користувач - власник ресурсу може надати певні права іншим користувачам: право доступу до певних папок , Право управляти настройками ТМЗК і т.д.

Кожен елемент в Списку Прав Доступу містить ім'я і набір прав доступу, які надаються цьому імені.

Ім'я елемента ACL може бути:

Ім'я елемента ACL може мати префікси + або -.

Користувачі - власники завжди мають повні Права Доступу до всіх своїх об'єктах (папки, функцій).

Для будь-якого іншого Користувача someaccount перевіряються діючі права доступу.

• Якщо існує елемент ACL для імені someaccount (без префіксів + або -), то в якості діючого права доступу використовується право Доступу, зазначеної в цьому елементі ACL.
  інакше,
• Всі елементи ACL без префіксів + або -, відповідні імені someaccount об'єднуються для формування "прямих" прав доступу.
• Всі елементи ACL відповідні імені someaccount з префіксом - об'єднуються для формування "збираних" прав доступу.
• Всі елементи ACL відповідні імені someaccount з префіксом + об'єднуються для формування "додаються" прав доступу.
• "Прибирають" права доступу видаляються з "прямих" прав доступу.
• "Додаються" права доступу об'єднуються з "прямими" правами доступу.
• Утворені "прямі" права доступу використовуються як діючі права доступу.

При наданні прав доступу, повинні використовуватися справжні імена користувачів, а не Псевдоніми. Якщо Користувач j.smith має два псевдоніма john.smith і jonny, то право доступу має надаватися для імені j.smith.

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

Керівництво CommuniGate® Pro. Copyright © 1998-2019, Stalker Software, Inc.

CommuniGate Pro: Безпека

версія 6.2

Сервер 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 аутентифікації:

Сервер CommuniGate Pro підтримує такі безпечні методи SASL аутентифікації:

• CRAM-MD5
• DIGEST-MD5
• GSSAPI

Сервер CommuniGate Pro підтримує наступні GSSAPI методи аутентифікації:

Сервер CommuniGate Pro підтримує наступні SASL-EXTERNAL методи аутентифікації:

Сервер CommuniGate Pro підтримує нестандартні SASL методи NTLM і MSN, використовувані в продуктах Microsoft®.

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

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

Використовуючи Веб Інтерфейс Адміністратора відкрийте сторінку установки Домену і знайдіть панель Способи Аутентифікації:

Ці опції Сповіщення впливають тільки на послуги "сесійного" типу (SMTP, POP, IMAP, ACAP, PWD, FTP), і ніяк не роблять ніякого ефекту на послуги "транзакційного" типу (HTTP, SIP).
Ці опції Сповіщення задають тільки те, як Сервер сповіщає про доступні методи входу. Клієнтські програми можуть використовувати будь-які методи, навіть якщо оповіщення про їх доступності з боку Сервера було вимкнено.

Один пароль - це "власний пароль" CommuniGate Pro. Пароль зберігається як елемент в Установках Користувача, і може використовуватися тільки Сервером CommuniGate Pro.

Для Користувача можуть бути задані додаткові варіанти внутрішнього пароля з мітками. При аутентифікації з використанням цих паролів мітка передається разом з ім'ям облікового запису через символ $: user $ tag.

Інший пароль - це "Пароль з ОС". Користувач може бути зареєстрований в ОС Сервера і Сервер CommuniGate Pro може звіряти отриманий пароль з паролем, використовуваним цим користувачем для входу в ОС.

Для Користувача можна задати 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-Пароль. Ця можливість може бути використана при міграції користувачів з діючих поштових систем, коли у вас немає можливості створити список користувачів з незашифрованими паролями.

Коли Сервер перевіряє Пароль з ОС, він створює рядок ім'я користувача, використовуючи налаштування Ім'я в ОС . Коли використовується рядок за замовчуванням *, то створювана рядок Ім'я в ОС буде відповідати імені Користувача. Змінюючи налаштування Ім'я в ОС, ви можете використовувати різні імена користувачів в ОС для користувачів з різних доменів CommuniGate Pro.

Аргумент командного рядка --BatchLogon може бути використаний для завдання Сервера методу аутентифікації LOGON_BATCH (якщо опція не задана, буде використовуватися метод LOGON_NETWORK).

Сервер перевіряє, чи містить створене ім'я користувача ОС символ відсоток (%). Якщо такий символ є, то частина Імені Користувача перед цим символом розглядається як ім'я користувача в Windows, а частина після вважатиметься доменним ім'ям Windows.
Якщо для користувачів з домена CommuniGate Pro company1.dom опція Ім'я в ОС встановлена ​​в *% comp1, то ім'я користувача в ОС для користувача CommuniGate Pro joe, буде joe% comp1, і Сервер CommuniGate Pro буде використовувати Windows API LogonUser для того, щоб аутентифицировать поштового клієнта як користувача Windows joe з домену Windows comp1.

Пароль з ОС є односторонньо зашифрованими паролями. Як наслідок, вони не можуть використовуватися для Методів Безпечної Аутентифікації .

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

• автоматичного створення користувачів на підставі будь-яких даних із зовнішніх джерел
• допомоги в операціях маршрутизатора
• допомоги в управлінні Користувачами.

Ім'я програми для Зовнішньої Аутентифікації і її додаткові параметри задаються через Веб Інтерфейс Адміністратора на сторінці Помічники. Через Веб Інтерфейс Адміністратора відкрийте в області Установки сторінку Помічники:

Детально ці опції описуються в розділі Програми-Помічники .

Адреса, на яку в Системний Журнал Сервера модулем Зовнішньої Аутентифікації, мають мітку EXTAUTH.

Якщо програма, що здійснює Зовнішню Аутентифікацію, не запущено, то всі запити на Зовнішню Аутентифікацію відкидаються.

Для того, щоб створити власну програму для Зовнішньої Аутентифікації, ознайомтеся в розділі помічники з описом інтерфейсу і протоколу для Зовнішньої Аутентифікації.

З прикладом програми і сценаріїв для Зовнішньої Аутентифікації можна ознайомитися на сайті CommuniGate Systems в розділі Помічники для Аутентифікації .

CommuniGate Pro: Безпека

версія 6.2

Сервер 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 аутентифікації:

Сервер CommuniGate Pro підтримує такі безпечні методи SASL аутентифікації:

• CRAM-MD5
• DIGEST-MD5
• GSSAPI

Сервер CommuniGate Pro підтримує наступні GSSAPI методи аутентифікації:

Сервер CommuniGate Pro підтримує наступні SASL-EXTERNAL методи аутентифікації:

Сервер CommuniGate Pro підтримує нестандартні SASL методи NTLM і MSN, використовувані в продуктах Microsoft®.

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

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

Використовуючи Веб Інтерфейс Адміністратора відкрийте сторінку установки Домену і знайдіть панель Способи Аутентифікації:

Ці опції Сповіщення впливають тільки на послуги "сесійного" типу (SMTP, POP, IMAP, ACAP, PWD, FTP), і ніяк не роблять ніякого ефекту на послуги "транзакційного" типу (HTTP, SIP).
Ці опції Сповіщення задають тільки те, як Сервер сповіщає про доступні методи входу. Клієнтські програми можуть використовувати будь-які методи, навіть якщо оповіщення про їх доступності з боку Сервера було вимкнено.

Один пароль - це "власний пароль" CommuniGate Pro. Пароль зберігається як елемент в Установках Користувача, і може використовуватися тільки Сервером CommuniGate Pro.

Для Користувача можуть бути задані додаткові варіанти внутрішнього пароля з мітками. При аутентифікації з використанням цих паролів мітка передається разом з ім'ям облікового запису через символ $: user $ tag.

Інший пароль - це "Пароль з ОС". Користувач може бути зареєстрований в ОС Сервера і Сервер CommuniGate Pro може звіряти отриманий пароль з паролем, використовуваним цим користувачем для входу в ОС.

Для Користувача можна задати 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-Пароль. Ця можливість може бути використана при міграції користувачів з діючих поштових систем, коли у вас немає можливості створити список користувачів з незашифрованими паролями.

Коли Сервер перевіряє Пароль з ОС, він створює рядок ім'я користувача, використовуючи налаштування Ім'я в ОС . Коли використовується рядок за замовчуванням *, то створювана рядок Ім'я в ОС буде відповідати імені Користувача. Змінюючи налаштування Ім'я в ОС, ви можете використовувати різні імена користувачів в ОС для користувачів з різних доменів CommuniGate Pro.

Аргумент командного рядка --BatchLogon може бути використаний для завдання Сервера методу аутентифікації LOGON_BATCH (якщо опція не задана, буде використовуватися метод LOGON_NETWORK).

Сервер перевіряє, чи містить створене ім'я користувача ОС символ відсоток (%). Якщо такий символ є, то частина Імені Користувача перед цим символом розглядається як ім'я користувача в Windows, а частина після вважатиметься доменним ім'ям Windows.
Якщо для користувачів з домена CommuniGate Pro company1.dom опція Ім'я в ОС встановлена ​​в *% comp1, то ім'я користувача в ОС для користувача CommuniGate Pro joe, буде joe% comp1, і Сервер CommuniGate Pro буде використовувати Windows API LogonUser для того, щоб аутентифицировать поштового клієнта як користувача Windows joe з домену Windows comp1.

Пароль з ОС є односторонньо зашифрованими паролями. Як наслідок, вони не можуть використовуватися для Методів Безпечної Аутентифікації .

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

• автоматичного створення користувачів на підставі будь-яких даних із зовнішніх джерел
• допомоги в операціях маршрутизатора
• допомоги в управлінні Користувачами.

Ім'я програми для Зовнішньої Аутентифікації і її додаткові параметри задаються через Веб Інтерфейс Адміністратора на сторінці Помічники. Через Веб Інтерфейс Адміністратора відкрийте в області Установки сторінку Помічники:

Детально ці опції описуються в розділі Програми-Помічники .

Адреса, на яку в Системний Журнал Сервера модулем Зовнішньої Аутентифікації, мають мітку EXTAUTH.

Якщо програма, що здійснює Зовнішню Аутентифікацію, не запущено, то всі запити на Зовнішню Аутентифікацію відкидаються.

Для того, щоб створити власну програму для Зовнішньої Аутентифікації, ознайомтеся в розділі помічники з описом інтерфейсу і протоколу для Зовнішньої Аутентифікації.

З прикладом програми і сценаріїв для Зовнішньої Аутентифікації можна ознайомитися на сайті CommuniGate Systems в розділі Помічники для Аутентифікації .

CommuniGate Pro: Безпека

версія 6.2

Сервер 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 аутентифікації:

Сервер CommuniGate Pro підтримує такі безпечні методи SASL аутентифікації:

• CRAM-MD5
• DIGEST-MD5
• GSSAPI

Сервер CommuniGate Pro підтримує наступні GSSAPI методи аутентифікації:

Сервер CommuniGate Pro підтримує наступні SASL-EXTERNAL методи аутентифікації:

Сервер CommuniGate Pro підтримує нестандартні SASL методи NTLM і MSN, використовувані в продуктах Microsoft®.

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

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

Використовуючи Веб Інтерфейс Адміністратора відкрийте сторінку установки Домену і знайдіть панель Способи Аутентифікації:

Ці опції Сповіщення впливають тільки на послуги "сесійного" типу (SMTP, POP, IMAP, ACAP, PWD, FTP), і ніяк не роблять ніякого ефекту на послуги "транзакційного" типу (HTTP, SIP).
Ці опції Сповіщення задають тільки те, як Сервер сповіщає про доступні методи входу. Клієнтські програми можуть використовувати будь-які методи, навіть якщо оповіщення про їх доступності з боку Сервера було вимкнено.

Один пароль - це "власний пароль" CommuniGate Pro. Пароль зберігається як елемент в Установках Користувача, і може використовуватися тільки Сервером CommuniGate Pro.

Для Користувача можуть бути задані додаткові варіанти внутрішнього пароля з мітками. При аутентифікації з використанням цих паролів мітка передається разом з ім'ям облікового запису через символ $: user $ tag.

Інший пароль - це "Пароль з ОС". Користувач може бути зареєстрований в ОС Сервера і Сервер CommuniGate Pro може звіряти отриманий пароль з паролем, використовуваним цим користувачем для входу в ОС.

Для Користувача можна задати 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-Пароль. Ця можливість може бути використана при міграції користувачів з діючих поштових систем, коли у вас немає можливості створити список користувачів з незашифрованими паролями.

Коли Сервер перевіряє Пароль з ОС, він створює рядок ім'я користувача, використовуючи налаштування Ім'я в ОС . Коли використовується рядок за замовчуванням *, то створювана рядок Ім'я в ОС буде відповідати імені Користувача. Змінюючи налаштування Ім'я в ОС, ви можете використовувати різні імена користувачів в ОС для користувачів з різних доменів CommuniGate Pro.

Аргумент командного рядка --BatchLogon може бути використаний для завдання Сервера методу аутентифікації LOGON_BATCH (якщо опція не задана, буде використовуватися метод LOGON_NETWORK).

Сервер перевіряє, чи містить створене ім'я користувача ОС символ відсоток (%). Якщо такий символ є, то частина Імені Користувача перед цим символом розглядається як ім'я користувача в Windows, а частина після вважатиметься доменним ім'ям Windows.
Якщо для користувачів з домена CommuniGate Pro company1.dom опція Ім'я в ОС встановлена ​​в *% comp1, то ім'я користувача в ОС для користувача CommuniGate Pro joe, буде joe% comp1, і Сервер CommuniGate Pro буде використовувати Windows API LogonUser для того, щоб аутентифицировать поштового клієнта як користувача Windows joe з домену Windows comp1.

Пароль з ОС є односторонньо зашифрованими паролями. Як наслідок, вони не можуть використовуватися для Методів Безпечної Аутентифікації .

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

• автоматичного створення користувачів на підставі будь-яких даних із зовнішніх джерел
• допомоги в операціях маршрутизатора
• допомоги в управлінні Користувачами.

Ім'я програми для Зовнішньої Аутентифікації і її додаткові параметри задаються через Веб Інтерфейс Адміністратора на сторінці Помічники. Через Веб Інтерфейс Адміністратора відкрийте в області Установки сторінку Помічники:

Детально ці опції описуються в розділі Програми-Помічники .

Адреса, на яку в Системний Журнал Сервера модулем Зовнішньої Аутентифікації, мають мітку EXTAUTH.

Якщо програма, що здійснює Зовнішню Аутентифікацію, не запущено, то всі запити на Зовнішню Аутентифікацію відкидаються.

Для того, щоб створити власну програму для Зовнішньої Аутентифікації, ознайомтеся в розділі помічники з описом інтерфейсу і протоколу для Зовнішньої Аутентифікації.

З прикладом програми і сценаріїв для Зовнішньої Аутентифікації можна ознайомитися на сайті CommuniGate Systems в розділі Помічники для Аутентифікації .

CommuniGate Pro: Безпека

версія 6.2

Сервер 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 аутентифікації:

Сервер CommuniGate Pro підтримує такі безпечні методи SASL аутентифікації:

• CRAM-MD5
• DIGEST-MD5
• GSSAPI

Сервер CommuniGate Pro підтримує наступні GSSAPI методи аутентифікації:

Сервер CommuniGate Pro підтримує наступні SASL-EXTERNAL методи аутентифікації:

Сервер CommuniGate Pro підтримує нестандартні SASL методи NTLM і MSN, використовувані в продуктах Microsoft®.

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

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

Використовуючи Веб Інтерфейс Адміністратора відкрийте сторінку установки Домену і знайдіть панель Способи Аутентифікації:

Ці опції Сповіщення впливають тільки на послуги "сесійного" типу (SMTP, POP, IMAP, ACAP, PWD, FTP), і ніяк не роблять ніякого ефекту на послуги "транзакційного" типу (HTTP, SIP).
Ці опції Сповіщення задають тільки те, як Сервер сповіщає про доступні методи входу. Клієнтські програми можуть використовувати будь-які методи, навіть якщо оповіщення про їх доступності з боку Сервера було вимкнено.

Один пароль - це "власний пароль" CommuniGate Pro. Пароль зберігається як елемент в Установках Користувача, і може використовуватися тільки Сервером CommuniGate Pro.

Для Користувача можуть бути задані додаткові варіанти внутрішнього пароля з мітками. При аутентифікації з використанням цих паролів мітка передається разом з ім'ям облікового запису через символ $: user $ tag.

Інший пароль - це "Пароль з ОС". Користувач може бути зареєстрований в ОС Сервера і Сервер CommuniGate Pro може звіряти отриманий пароль з паролем, використовуваним цим користувачем для входу в ОС.

Для Користувача можна задати 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-Пароль. Ця можливість може бути використана при міграції користувачів з діючих поштових систем, коли у вас немає можливості створити список користувачів з незашифрованими паролями.

Коли Сервер перевіряє Пароль з ОС, він створює рядок ім'я користувача, використовуючи налаштування Ім'я в ОС . Коли використовується рядок за замовчуванням *, то створювана рядок Ім'я в ОС буде відповідати імені Користувача. Змінюючи налаштування Ім'я в ОС, ви можете використовувати різні імена користувачів в ОС для користувачів з різних доменів CommuniGate Pro.

Аргумент командного рядка --BatchLogon може бути використаний для завдання Сервера методу аутентифікації LOGON_BATCH (якщо опція не задана, буде використовуватися метод LOGON_NETWORK).

Сервер перевіряє, чи містить створене ім'я користувача ОС символ відсоток (%). Якщо такий символ є, то частина Імені Користувача перед цим символом розглядається як ім'я користувача в Windows, а частина після вважатиметься доменним ім'ям Windows.
Якщо для користувачів з домена CommuniGate Pro company1.dom опція Ім'я в ОС встановлена ​​в *% comp1, то ім'я користувача в ОС для користувача CommuniGate Pro joe, буде joe% comp1, і Сервер CommuniGate Pro буде використовувати Windows API LogonUser для того, щоб аутентифицировать поштового клієнта як користувача Windows joe з домену Windows comp1.

Пароль з ОС є односторонньо зашифрованими паролями. Як наслідок, вони не можуть використовуватися для Методів Безпечної Аутентифікації .

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

• автоматичного створення користувачів на підставі будь-яких даних із зовнішніх джерел
• допомоги в операціях маршрутизатора
• допомоги в управлінні Користувачами.

Ім'я програми для Зовнішньої Аутентифікації і її додаткові параметри задаються через Веб Інтерфейс Адміністратора на сторінці Помічники. Через Веб Інтерфейс Адміністратора відкрийте в області Установки сторінку Помічники:

Детально ці опції описуються в розділі Програми-Помічники .

Адреса, на яку в Системний Журнал Сервера модулем Зовнішньої Аутентифікації, мають мітку EXTAUTH.

Якщо програма, що здійснює Зовнішню Аутентифікацію, не запущено, то всі запити на Зовнішню Аутентифікацію відкидаються.

Для того, щоб створити власну програму для Зовнішньої Аутентифікації, ознайомтеся в розділі помічники з описом інтерфейсу і протоколу для Зовнішньої Аутентифікації.

З прикладом програми і сценаріїв для Зовнішньої Аутентифікації можна ознайомитися на сайті CommuniGate Systems в розділі Помічники для Аутентифікації .

Деякі спамери Використовують "атаку грубою силою" на поштові системи, відправляючі віпадкові імена и паролі на POP, IMAP и інші порти доступу. Якщо система відправляє різні повідомлення про помилки в ситуаціях "невідомого імені" або "неправильного пароля", то, грунтуючись на цій інформації, атакуючий може зібрати досить багато імен користувачів з цієї системи і потім використовувати ці імена для розсилки на них спаму.

Для того, щоб налаштувати опцію Безпека Входів, використовуйте Веб Інтерфейс Адміністратора. Відкрийте в області Установки сторінку Загальна, потім на сторінці Інше знайдіть панель Безпека Входів:

Сервер CommuniGate Pro може тимчасово блокувати всі типи операцій входу на сервер для Користувача, у якого було занадто багато невдалих спроб входу на сервер. ця настройка Користувача дозволяє вказати інтервал часу і число невдалих спроб входу, яке користувач (або користувачі) можуть зробити до блокування для цього Користувача. Вхід на Сервер буде дозволений для цього Користувача через такий же інтервал часу.

Зазвичай, для того, щоб контролювати роботу Сервера CommuniGate Pro, спостерігати і обслуговувати його, досить Користувача Postmaster. Але ви також можете надати іншим користувачам право адмініструвати Сервер CommuniGate Pro: наприклад, ви можете надати Оператору право перегляду Журналів Роботи Сервера, котрі дають йому всіх прав адміністрування, наявних у Користувача Postmaster.

Для того, щоб надавати іншим користувачам необхідні Права Доступу, ви повинні увійти на Сервер як Postmaster або інший Користувач, який має права "Може Все".

Щоб надати Користувачеві права і / або забрати права, відкрийте для цього користувача сторінку установки Користувача , Потім натисніть на лінк Права Доступу. З'явиться сторінка з Правами Доступу.

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

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

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

Спочатку, користувач Postmaster в головному домені має Права Доступу Може Все.

Виберіть необхідні Права Доступу та натисніть на кнопку Модифікувати.

Права Доступу зберігаються в індивідуальному для кожного домена файлі; цей файл Access.settings зберігається в піддиректорії директорії домену. Це дозволяє легко перевіряти, кому надані права на Адміністрування Сервера.

Якщо ви не плануєте обслуговувати мобільних користувачів, то, можливо, ви захочете обмежити доступ до даних користувачів на Сервері. Використовуйте для цього наступну опцію Мережеві Адреси Клієнтів на сторінці Установки-> Мережа-> Клієнти:

Коли модуль доступу приймає з'єднання з невизначеного в цьому списку мережевого адреси, модуль відправляє клієнтського додатку повідомлення про помилку і з'єднання негайно закривається. Зв'язок з іншим Інтернетом буде використовуватися тільки для цілей передачі Пошти , обміну сигналами Реального Часу і для HTTP доступу до сховища файлів Користувача.

Коли ця опція має значення Заборонити, операція SMTP AUTH може використовуватися, тільки якщо клієнтська поштова програма або сервер з'єднуються з мережевої адреси, вказаної в списку Мережеві Адреси Клієнтів.

Коли ця опція має значення Заборонити, будь-яка з операцій з обміну Сигналами, що вимагає аутентифікації буде здійснюватися, тільки якщо клієнтський пристрій або сервер встановили з'єднання з мережевої адреси, вказаної в списку Мережеві Адреси Клієнтів.
Зверніть увагу: До того, як ви оберете в опцію в положення Заборонити, переконайтеся, що мережеву адресу, які ви використовуєте в даний час, включений в список Мережевих Адрес Клієнтів: в іншому випадку ви негайно втратите доступ до Сервера навіть через Веб Інтерфейс Адміністратора.

Також ви можете встановити обмеження на доступ до сервера на більш низькому рівні TCP-з'єднань. Для кожного сервісу (модуля), відкрийте сторінку приймач і вкажіть адреси, з яких цей сервіс (модуль) повинен (або не повинен) приймати з'єднання. Якщо з'єднання встановлюється з адреси, яка не включений в число адрес, доступ з яких Дозволено, або ця адреса включений в число адрес, доступ з яких Заборонено, то з'єднання негайно закривається, і ніяких операцій на рівні модуля не виконується.

Сервер CommuniGate Pro підтримує можливість роботи під чужими правами - особливий режим входу на сервер, при якому одному користувачеві (аутентифицироваться Користувачеві) надаються повноваження іншого Користувача (Авторизованого Користувача).
Ця можливість також може використовуватися для Реєстрацій Реального Часу .

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

При використанні Дії від чужого імені, Сервер перевіряє, чи є відповідні повноваження у аутентифицированного користувача, і чи дозволено для цього користувача ця послуга. Він також перевіряє, чи є у аутентифицироваться Користувача Право Може виступати від імені інших в Права Доступу Домену .

Сервер CommuniGate Pro підтримує спеціальний метод Аутентифікації SessionID. У цьому методі замість пароля Користувача використовується ідентифікаційний номер WebUser або XIMSS сесії.
Цей метод корисний для CGI -скріптов або програм.
За замовчуванням, цей метод вимкнений (дивіться вище).

Цей метод є SASL-методом і вимагає "безпосереднього" вказівки параметрів у командах аутентификационного протоколу. Перший параметр - це ім'я Користувача, другий, відокремлений прогалиною, це ідентифікаційний номер сесії.
Для PWD модуля операція аутентифікації SESSIONID виглядає як:

Якщо у користувача [email protected] відкрита WebUser сесія з ідентифікаційним номером 114-bXaKw92JK1pZVB5taj1r, то наступна команда PWD:
AUTH SESSIONID [email protected] 114-bXaKw92JK1pZVB5taj1r
відкриє PWD сесію для користувача [email protected].

Користувач - власник ресурсу може надати певні права іншим користувачам: право доступу до певних папок , Право управляти настройками ТМЗК і т.д.

Кожен елемент в Списку Прав Доступу містить ім'я і набір прав доступу, які надаються цьому імені.

Ім'я елемента ACL може бути:

Ім'я елемента ACL може мати префікси + або -.

Користувачі - власники завжди мають повні Права Доступу до всіх своїх об'єктах (папки, функцій).

Для будь-якого іншого Користувача someaccount перевіряються діючі права доступу.

• Якщо існує елемент ACL для імені someaccount (без префіксів + або -), то в якості діючого права доступу використовується право Доступу, зазначеної в цьому елементі ACL.
  інакше,
• Всі елементи ACL без префіксів + або -, відповідні імені someaccount об'єднуються для формування "прямих" прав доступу.
• Всі елементи ACL відповідні імені someaccount з префіксом - об'єднуються для формування "збираних" прав доступу.
• Всі елементи ACL відповідні імені someaccount з префіксом + об'єднуються для формування "додаються" прав доступу.
• "Прибирають" права доступу видаляються з "прямих" прав доступу.
• "Додаються" права доступу об'єднуються з "прямими" правами доступу.
• Утворені "прямі" права доступу використовуються як діючі права доступу.

При наданні прав доступу, повинні використовуватися справжні імена користувачів, а не Псевдоніми. Якщо Користувач j.smith має два псевдоніма john.smith і jonny, то право доступу має надаватися для імені j.smith.

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

Керівництво CommuniGate® Pro. Copyright © 1998-2019, Stalker Software, Inc.