• Главная
  • Карта сайта
Не найдено

CommuniGate Pro: Безпека

  1. CommuniGate Pro: Безпека
  2. Інтеграція з Microsoft Active Directory
  3. CommuniGate Pro: Безпека
  4. Інтеграція з Microsoft Active Directory
  5. CommuniGate Pro: Безпека
  6. Інтеграція з Microsoft Active Directory
  7. CommuniGate Pro: Безпека
  8. Інтеграція з Microsoft Active Directory
  9. CommuniGate Pro: Безпека
  10. Інтеграція з Microsoft Active Directory

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 .

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

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.

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

Операційна система Сервера Примітки про паролі з ОС Microsoft Windows 95/98 / ME Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде. Microsoft Windows 200x / XP / NT / Vista Використовується система аутентифікації в домені Windows NT. Користувач Windows, від імені якого запущено Сервер 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.

Операційні системи Unix Використовуються механізми аутентифікації passwd і shadow або інші, підтримувані OS. Система OS / 400 Використовується механізм аутентифікації user profile. Система OpenVMS Отримане ім'я користувача і парольний рядок перетворюються в великі літери, а потім використовуються механізми аутентифікації OpenVMS. BeOS Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде.

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

Сервер CommuniGate Pro підтримує метод аутентифікації користувачів через Kerberos. Методи Kerberos базується на "мандати" ( "ticket"), які клієнтську програму відправляє на сервер. Ці мандати видаються центрами Kerberos (Центри Поширення Ключів, KDC), які мають спільний з Сервером "ключ". Додаткову інформацію дивіться в документації на Kerberos.

Для підтримки Аутентифікації через Kerberos вам необхідно, індивідуально для кожного домена додати ключ (і) Сервера Kerberos в Сервер. Створіть "довірителя" сервера ( "principal") у вашій базі даних KDC. Ім'я довірителя має збігатися з ім'ям домена CommuniGate Pro або з ім'ям одного з псевдонімом Домену. Експортуйте створений ключ в файл keytab.

Через Веб Інтерфейс Адміністратора відкрийте сторінку Установки Домену, потім пройдіть по посиланнях Безпека і Kerberos. Буде показаний список Kerberos Ключів Домену:

Кожен Домен може мати кілька Kerberos Ключів. Для того, щоб додати ключі, натисніть на кнопку Browse і виберіть файл keytab, експортований з KDC. Для того, щоб додати ключі з файлу до Kerberos ключі Домену, натисніть на кнопку Імпортувати Ключі.

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

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

Коли Сервер отримує мандат Kerberos, він витягує з Мандата ім'я Сервера ( "sname"). Якщо Ім'я Сервера має тільки одну компоненту (domain.dom), то ця компонента використовується як ім'я цільового Домену (ticket-domain-name). Якщо Ім'я Сервера має дві або більше компоненти, (service /domain.dom), то використовується друга компонента. Потім Сервер створює фіктивну адресу LoginPage @ ticket-domain-name і намагається здійснити його маршрутизацію. При цьому використовується такий самий механізм маршрутизації, що і при знаходженні цільового Домену при HTTP запитах.

Якщо цільової Домен знайдений, Сервер шукає підходящий ключ у списку Ключів Kerberos для цього Домену. Якщо Ключ знайдений, і Мандат і авторизаційної інформація можуть бути розшифровані за допомогою цього Ключа, то користувач аутентифицирующей. Ім'я Користувача береться з Імені Клієнта, зазначеного в Мандату. Це ім'я повинні бути "простим", тобто не повинно містити символів @ або%.

CommuniGate Pro додає ім'я цільового Домену до отриманого імені користувача і використовує цю адресу як ім'я Користувача, до ресурсів якого необхідно надати доступ.

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

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

Інтеграція з Microsoft Active Directory

Можливо, вам буде потрібно, щоб Microsoft Active Directory виступала в ролі Центру Поширення Kerberos Ключів (KDC). Виконайте наступні дії:

Більш детальну інформацію ви можете прочитати в Базі Знань Microsoft, стаття Q324144.

Якщо ви хочете використовувати Аутентифікацію Kerberos (механізм єдиного входу на сервер) з браузерами Microsoft, будь ласка прочитайте статтю "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документації Microsoft, яка знаходиться на MSDN.

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

Якщо клієнт відправляє такий сертифікат, то адреса електронної пошти, вказану в елементі subjectAltName Сертифікату (якщо є) або в поле електронної пошти в елементі Subject може бути використаний для Аутентифікації по Сертифікату. Ця електронна адреса інтерпретується як ім'я Користувача, який повинен увійти на сервер CommuniGate Pro.

Зверніть увагу: після того як результуючий ім'я Користувача оброблено маршрутизатором, сервер перевіряє, що Користувач належить тому ж домену, що і сертифікат, щоб уникнути доступу в домени, які не контролюються адміністратором поточного домену.

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

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

Сервер CommuniGate Pro може використовувати програму Зовнішнього Помічника для аутентифікації користувачів. Ця програма створюється вашим технічним персоналом і в ній реалізуються необхідні для вашого сайту механізми аутентифікації, безпосередньо не підтримуються сервером CommuniGate Pro.

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

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

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

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

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

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

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

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

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

Ховати повідомлення Невідоме ім'я Якщо ця опція включена, то Сервер не буде відправляти повідомлення Невідоме ім'я і Невірний Пароль. Замість цих обох повідомлень буде відправлятися повідомлення Неправильне ім'я користувача або пароль.

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

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

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

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

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

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

Може Все (право Майстер) Якщо користувачеві надано це право, він має повний доступ до всіх компонентів Сервера. Може змінювати установки Сервера (право Налаштування) Це право дозволяє користувачеві змінювати конфігурацію всіх модулів і компонентів CommuniGate Pro (SMTP, POP, Маршрутизатор і т.д.)) може змінювати установки Довідника (право Довідник) Це право дозволяє користувачеві змінювати конфігурацію системного довідника Може змінювати установки Всіх доменів і користувачів (право Все Користувачі) Ця настройка вказує, чи може користувач створювати, перейменовувати і видаляти Домени, користувачів і інші Об'єкти, а також змінювати Установки доменів, користувачів та інших Об'єктів. Може спостерігати за Сервером (право Спостерігати) Ця настройка вказує, чи може користувач дивитися Системні Журнали Сервера, спостерігати за Чергами Сервера і т.д.

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

Може змінювати установки Цього Домену і його користувачів: Ця настройка вказує, чи може користувач створювати, перейменовувати і видаляти інших користувачів у своєму власному домені, а також змінювати деякі Установки Домену. Зазвичай ви надаєте такі права користувачеві ( "господареві домену"), який буде обслуговувати цей домен.

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

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

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

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

Вхід з не-Клієнтських Адрес Коли ця опція має значення Заборонити, всі операції "входу" (необхідні для POP, IMAP, SIP, XMPP, Веб Інтерфейсу Користувача, ACAP, PWD і т.д.) здійснюються тільки з комп'ютера, на якому працює сервер і з Мережевих Адрес Клієнтів .

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

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

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

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

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

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

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

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

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

AUTH SESSIONID userName session-ID
Для IMAP модуля операція аутентифікації SESSIONID виглядає як: AUTHENTICATE SESSIONID bindata
де bindata це такі дані, закодовані в base64: userName session-ID

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

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

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

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

null @ null Цей елемент ACL задає права доступу, що надаються "гостям" (всім нерозпізнаних користувачів). anyone Цей елемент ACL задає права доступу, що надаються кожному (всім аутентифицироваться користувачами). anyone @ Цей елемент ACL задає права доступу, які надаються всім Користувачам з цього ж домена CommuniGate Pro. anyone @ domainName Цей елемент ACL задає права доступу, які надаються всім Користувачам CommuniGate Pro з Домену domainName. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену. accountName Цей елемент ACL задає права доступу, що надаються Користувачеві accountName в тому ж домені CommuniGate Pro. Ім'я accountName має бути справжнім ім'ям Користувача і не може бути Псевдонімом Користувача або Переадресатором. accountname @ domainname Цей елемент ACL задає права доступу, що надаються Користувачеві CommuniGate Pro з іншого Домена. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену. # GroupName Цей елемент ACL задає права доступу, які надаються всім учасникам Групи groupName (з того ж Домену). # GroupName @ domainName Цей елемент ACL задає права доступу, які надаються всім учасникам Групи groupName з іншого Домена в CommuniGate Pro. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену.

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

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

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

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

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

Приклади: Надання прав доступу Бачити, Входити, Читати для всіх користувачів з цього ж Домену, крім користувача John, який має тільки право Бачити, і користувача Susan, яка повинна мати права Бачити, Входити, Читати і Видаляти: anyone @ Бачити, Входити, Читати -john Входити, читати + susan Видалити Надання прав доступу Бачити, Входити, читати для всіх користувачів з іншого домена company2.com, крім користувача [email protected], який не повинен мати прав доступу взагалі, і користувача Susan з третього домену company3 .com, яка повинна мати пр ава Бачити, Входити і Видаляти. [email protected] Бачити, Входити, Читати [email protected] Бачити, Входити, Читати [email protected] Бачити, Входити, Видалити

Список Прав Доступу може здаватися і змінюватися через Веб інтерфейс користувача , 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 .

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

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.

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

Операційна система Сервера Примітки про паролі з ОС Microsoft Windows 95/98 / ME Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде. Microsoft Windows 200x / XP / NT / Vista Використовується система аутентифікації в домені Windows NT. Користувач Windows, від імені якого запущено Сервер 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.

Операційні системи Unix Використовуються механізми аутентифікації passwd і shadow або інші, підтримувані OS. Система OS / 400 Використовується механізм аутентифікації user profile. Система OpenVMS Отримане ім'я користувача і парольний рядок перетворюються в великі літери, а потім використовуються механізми аутентифікації OpenVMS. BeOS Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде.

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

Сервер CommuniGate Pro підтримує метод аутентифікації користувачів через Kerberos. Методи Kerberos базується на "мандати" ( "ticket"), які клієнтську програму відправляє на сервер. Ці мандати видаються центрами Kerberos (Центри Поширення Ключів, KDC), які мають спільний з Сервером "ключ". Додаткову інформацію дивіться в документації на Kerberos.

Для підтримки Аутентифікації через Kerberos вам необхідно, індивідуально для кожного домена додати ключ (і) Сервера Kerberos в Сервер. Створіть "довірителя" сервера ( "principal") у вашій базі даних KDC. Ім'я довірителя має збігатися з ім'ям домена CommuniGate Pro або з ім'ям одного з псевдонімом Домену. Експортуйте створений ключ в файл keytab.

Через Веб Інтерфейс Адміністратора відкрийте сторінку Установки Домену, потім пройдіть по посиланнях Безпека і Kerberos. Буде показаний список Kerberos Ключів Домену:

Кожен Домен може мати кілька Kerberos Ключів. Для того, щоб додати ключі, натисніть на кнопку Browse і виберіть файл keytab, експортований з KDC. Для того, щоб додати ключі з файлу до Kerberos ключі Домену, натисніть на кнопку Імпортувати Ключі.

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

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

Коли Сервер отримує мандат Kerberos, він витягує з Мандата ім'я Сервера ( "sname"). Якщо Ім'я Сервера має тільки одну компоненту (domain.dom), то ця компонента використовується як ім'я цільового Домену (ticket-domain-name). Якщо Ім'я Сервера має дві або більше компоненти, (service /domain.dom), то використовується друга компонента. Потім Сервер створює фіктивну адресу LoginPage @ ticket-domain-name і намагається здійснити його маршрутизацію. При цьому використовується такий самий механізм маршрутизації, що і при знаходженні цільового Домену при HTTP запитах.

Якщо цільової Домен знайдений, Сервер шукає підходящий ключ у списку Ключів Kerberos для цього Домену. Якщо Ключ знайдений, і Мандат і авторизаційної інформація можуть бути розшифровані за допомогою цього Ключа, то користувач аутентифицирующей. Ім'я Користувача береться з Імені Клієнта, зазначеного в Мандату. Це ім'я повинні бути "простим", тобто не повинно містити символів @ або%.

CommuniGate Pro додає ім'я цільового Домену до отриманого імені користувача і використовує цю адресу як ім'я Користувача, до ресурсів якого необхідно надати доступ.

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

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

Інтеграція з Microsoft Active Directory

Можливо, вам буде потрібно, щоб Microsoft Active Directory виступала в ролі Центру Поширення Kerberos Ключів (KDC). Виконайте наступні дії:

Більш детальну інформацію ви можете прочитати в Базі Знань Microsoft, стаття Q324144.

Якщо ви хочете використовувати Аутентифікацію Kerberos (механізм єдиного входу на сервер) з браузерами Microsoft, будь ласка прочитайте статтю "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документації Microsoft, яка знаходиться на MSDN.

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

Якщо клієнт відправляє такий сертифікат, то адреса електронної пошти, вказану в елементі subjectAltName Сертифікату (якщо є) або в поле електронної пошти в елементі Subject може бути використаний для Аутентифікації по Сертифікату. Ця електронна адреса інтерпретується як ім'я Користувача, який повинен увійти на сервер CommuniGate Pro.

Зверніть увагу: після того як результуючий ім'я Користувача оброблено маршрутизатором, сервер перевіряє, що Користувач належить тому ж домену, що і сертифікат, щоб уникнути доступу в домени, які не контролюються адміністратором поточного домену.

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

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

Сервер CommuniGate Pro може використовувати програму Зовнішнього Помічника для аутентифікації користувачів. Ця програма створюється вашим технічним персоналом і в ній реалізуються необхідні для вашого сайту механізми аутентифікації, безпосередньо не підтримуються сервером CommuniGate Pro.

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

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

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

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

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

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

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

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 .

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

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.

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

Операційна система Сервера Примітки про паролі з ОС Microsoft Windows 95/98 / ME Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде. Microsoft Windows 200x / XP / NT / Vista Використовується система аутентифікації в домені Windows NT. Користувач Windows, від імені якого запущено Сервер 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.

Операційні системи Unix Використовуються механізми аутентифікації passwd і shadow або інші, підтримувані OS. Система OS / 400 Використовується механізм аутентифікації user profile. Система OpenVMS Отримане ім'я користувача і парольний рядок перетворюються в великі літери, а потім використовуються механізми аутентифікації OpenVMS. BeOS Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде.

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

Сервер CommuniGate Pro підтримує метод аутентифікації користувачів через Kerberos. Методи Kerberos базується на "мандати" ( "ticket"), які клієнтську програму відправляє на сервер. Ці мандати видаються центрами Kerberos (Центри Поширення Ключів, KDC), які мають спільний з Сервером "ключ". Додаткову інформацію дивіться в документації на Kerberos.

Для підтримки Аутентифікації через Kerberos вам необхідно, індивідуально для кожного домена додати ключ (і) Сервера Kerberos в Сервер. Створіть "довірителя" сервера ( "principal") у вашій базі даних KDC. Ім'я довірителя має збігатися з ім'ям домена CommuniGate Pro або з ім'ям одного з псевдонімом Домену. Експортуйте створений ключ в файл keytab.

Через Веб Інтерфейс Адміністратора відкрийте сторінку Установки Домену, потім пройдіть по посиланнях Безпека і Kerberos. Буде показаний список Kerberos Ключів Домену:

Кожен Домен може мати кілька Kerberos Ключів. Для того, щоб додати ключі, натисніть на кнопку Browse і виберіть файл keytab, експортований з KDC. Для того, щоб додати ключі з файлу до Kerberos ключі Домену, натисніть на кнопку Імпортувати Ключі.

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

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

Коли Сервер отримує мандат Kerberos, він витягує з Мандата ім'я Сервера ( "sname"). Якщо Ім'я Сервера має тільки одну компоненту (domain.dom), то ця компонента використовується як ім'я цільового Домену (ticket-domain-name). Якщо Ім'я Сервера має дві або більше компоненти, (service /domain.dom), то використовується друга компонента. Потім Сервер створює фіктивну адресу LoginPage @ ticket-domain-name і намагається здійснити його маршрутизацію. При цьому використовується такий самий механізм маршрутизації, що і при знаходженні цільового Домену при HTTP запитах.

Якщо цільової Домен знайдений, Сервер шукає підходящий ключ у списку Ключів Kerberos для цього Домену. Якщо Ключ знайдений, і Мандат і авторизаційної інформація можуть бути розшифровані за допомогою цього Ключа, то користувач аутентифицирующей. Ім'я Користувача береться з Імені Клієнта, зазначеного в Мандату. Це ім'я повинні бути "простим", тобто не повинно містити символів @ або%.

CommuniGate Pro додає ім'я цільового Домену до отриманого імені користувача і використовує цю адресу як ім'я Користувача, до ресурсів якого необхідно надати доступ.

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

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

Інтеграція з Microsoft Active Directory

Можливо, вам буде потрібно, щоб Microsoft Active Directory виступала в ролі Центру Поширення Kerberos Ключів (KDC). Виконайте наступні дії:

Більш детальну інформацію ви можете прочитати в Базі Знань Microsoft, стаття Q324144.

Якщо ви хочете використовувати Аутентифікацію Kerberos (механізм єдиного входу на сервер) з браузерами Microsoft, будь ласка прочитайте статтю "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документації Microsoft, яка знаходиться на MSDN.

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

Якщо клієнт відправляє такий сертифікат, то адреса електронної пошти, вказану в елементі subjectAltName Сертифікату (якщо є) або в поле електронної пошти в елементі Subject може бути використаний для Аутентифікації по Сертифікату. Ця електронна адреса інтерпретується як ім'я Користувача, який повинен увійти на сервер CommuniGate Pro.

Зверніть увагу: після того як результуючий ім'я Користувача оброблено маршрутизатором, сервер перевіряє, що Користувач належить тому ж домену, що і сертифікат, щоб уникнути доступу в домени, які не контролюються адміністратором поточного домену.

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

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

Сервер CommuniGate Pro може використовувати програму Зовнішнього Помічника для аутентифікації користувачів. Ця програма створюється вашим технічним персоналом і в ній реалізуються необхідні для вашого сайту механізми аутентифікації, безпосередньо не підтримуються сервером CommuniGate Pro.

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

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

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

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

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

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

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

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 .

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

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.

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

Операційна система Сервера Примітки про паролі з ОС Microsoft Windows 95/98 / ME Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде. Microsoft Windows 200x / XP / NT / Vista Використовується система аутентифікації в домені Windows NT. Користувач Windows, від імені якого запущено Сервер 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.

Операційні системи Unix Використовуються механізми аутентифікації passwd і shadow або інші, підтримувані OS. Система OS / 400 Використовується механізм аутентифікації user profile. Система OpenVMS Отримане ім'я користувача і парольний рядок перетворюються в великі літери, а потім використовуються механізми аутентифікації OpenVMS. BeOS Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде.

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

Сервер CommuniGate Pro підтримує метод аутентифікації користувачів через Kerberos. Методи Kerberos базується на "мандати" ( "ticket"), які клієнтську програму відправляє на сервер. Ці мандати видаються центрами Kerberos (Центри Поширення Ключів, KDC), які мають спільний з Сервером "ключ". Додаткову інформацію дивіться в документації на Kerberos.

Для підтримки Аутентифікації через Kerberos вам необхідно, індивідуально для кожного домена додати ключ (і) Сервера Kerberos в Сервер. Створіть "довірителя" сервера ( "principal") у вашій базі даних KDC. Ім'я довірителя має збігатися з ім'ям домена CommuniGate Pro або з ім'ям одного з псевдонімом Домену. Експортуйте створений ключ в файл keytab.

Через Веб Інтерфейс Адміністратора відкрийте сторінку Установки Домену, потім пройдіть по посиланнях Безпека і Kerberos. Буде показаний список Kerberos Ключів Домену:

Кожен Домен може мати кілька Kerberos Ключів. Для того, щоб додати ключі, натисніть на кнопку Browse і виберіть файл keytab, експортований з KDC. Для того, щоб додати ключі з файлу до Kerberos ключі Домену, натисніть на кнопку Імпортувати Ключі.

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

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

Коли Сервер отримує мандат Kerberos, він витягує з Мандата ім'я Сервера ( "sname"). Якщо Ім'я Сервера має тільки одну компоненту (domain.dom), то ця компонента використовується як ім'я цільового Домену (ticket-domain-name). Якщо Ім'я Сервера має дві або більше компоненти, (service /domain.dom), то використовується друга компонента. Потім Сервер створює фіктивну адресу LoginPage @ ticket-domain-name і намагається здійснити його маршрутизацію. При цьому використовується такий самий механізм маршрутизації, що і при знаходженні цільового Домену при HTTP запитах.

Якщо цільової Домен знайдений, Сервер шукає підходящий ключ у списку Ключів Kerberos для цього Домену. Якщо Ключ знайдений, і Мандат і авторизаційної інформація можуть бути розшифровані за допомогою цього Ключа, то користувач аутентифицирующей. Ім'я Користувача береться з Імені Клієнта, зазначеного в Мандату. Це ім'я повинні бути "простим", тобто не повинно містити символів @ або%.

CommuniGate Pro додає ім'я цільового Домену до отриманого імені користувача і використовує цю адресу як ім'я Користувача, до ресурсів якого необхідно надати доступ.

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

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

Інтеграція з Microsoft Active Directory

Можливо, вам буде потрібно, щоб Microsoft Active Directory виступала в ролі Центру Поширення Kerberos Ключів (KDC). Виконайте наступні дії:

Більш детальну інформацію ви можете прочитати в Базі Знань Microsoft, стаття Q324144.

Якщо ви хочете використовувати Аутентифікацію Kerberos (механізм єдиного входу на сервер) з браузерами Microsoft, будь ласка прочитайте статтю "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документації Microsoft, яка знаходиться на MSDN.

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

Якщо клієнт відправляє такий сертифікат, то адреса електронної пошти, вказану в елементі subjectAltName Сертифікату (якщо є) або в поле електронної пошти в елементі Subject може бути використаний для Аутентифікації по Сертифікату. Ця електронна адреса інтерпретується як ім'я Користувача, який повинен увійти на сервер CommuniGate Pro.

Зверніть увагу: після того як результуючий ім'я Користувача оброблено маршрутизатором, сервер перевіряє, що Користувач належить тому ж домену, що і сертифікат, щоб уникнути доступу в домени, які не контролюються адміністратором поточного домену.

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

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

Сервер CommuniGate Pro може використовувати програму Зовнішнього Помічника для аутентифікації користувачів. Ця програма створюється вашим технічним персоналом і в ній реалізуються необхідні для вашого сайту механізми аутентифікації, безпосередньо не підтримуються сервером CommuniGate Pro.

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

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

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

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

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

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

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

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 .

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

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.

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

Операційна система Сервера Примітки про паролі з ОС Microsoft Windows 95/98 / ME Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде. Microsoft Windows 200x / XP / NT / Vista Використовується система аутентифікації в домені Windows NT. Користувач Windows, від імені якого запущено Сервер 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.

Операційні системи Unix Використовуються механізми аутентифікації passwd і shadow або інші, підтримувані OS. Система OS / 400 Використовується механізм аутентифікації user profile. Система OpenVMS Отримане ім'я користувача і парольний рядок перетворюються в великі літери, а потім використовуються механізми аутентифікації OpenVMS. BeOS Ця операційна система не підтримує паролі, опція Пароль з ОС працювати не буде.

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

Сервер CommuniGate Pro підтримує метод аутентифікації користувачів через Kerberos. Методи Kerberos базується на "мандати" ( "ticket"), які клієнтську програму відправляє на сервер. Ці мандати видаються центрами Kerberos (Центри Поширення Ключів, KDC), які мають спільний з Сервером "ключ". Додаткову інформацію дивіться в документації на Kerberos.

Для підтримки Аутентифікації через Kerberos вам необхідно, індивідуально для кожного домена додати ключ (і) Сервера Kerberos в Сервер. Створіть "довірителя" сервера ( "principal") у вашій базі даних KDC. Ім'я довірителя має збігатися з ім'ям домена CommuniGate Pro або з ім'ям одного з псевдонімом Домену. Експортуйте створений ключ в файл keytab.

Через Веб Інтерфейс Адміністратора відкрийте сторінку Установки Домену, потім пройдіть по посиланнях Безпека і Kerberos. Буде показаний список Kerberos Ключів Домену:

Кожен Домен може мати кілька Kerberos Ключів. Для того, щоб додати ключі, натисніть на кнопку Browse і виберіть файл keytab, експортований з KDC. Для того, щоб додати ключі з файлу до Kerberos ключі Домену, натисніть на кнопку Імпортувати Ключі.

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

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

Коли Сервер отримує мандат Kerberos, він витягує з Мандата ім'я Сервера ( "sname"). Якщо Ім'я Сервера має тільки одну компоненту (domain.dom), то ця компонента використовується як ім'я цільового Домену (ticket-domain-name). Якщо Ім'я Сервера має дві або більше компоненти, (service /domain.dom), то використовується друга компонента. Потім Сервер створює фіктивну адресу LoginPage @ ticket-domain-name і намагається здійснити його маршрутизацію. При цьому використовується такий самий механізм маршрутизації, що і при знаходженні цільового Домену при HTTP запитах.

Якщо цільової Домен знайдений, Сервер шукає підходящий ключ у списку Ключів Kerberos для цього Домену. Якщо Ключ знайдений, і Мандат і авторизаційної інформація можуть бути розшифровані за допомогою цього Ключа, то користувач аутентифицирующей. Ім'я Користувача береться з Імені Клієнта, зазначеного в Мандату. Це ім'я повинні бути "простим", тобто не повинно містити символів @ або%.

CommuniGate Pro додає ім'я цільового Домену до отриманого імені користувача і використовує цю адресу як ім'я Користувача, до ресурсів якого необхідно надати доступ.

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

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

Інтеграція з Microsoft Active Directory

Можливо, вам буде потрібно, щоб Microsoft Active Directory виступала в ролі Центру Поширення Kerberos Ключів (KDC). Виконайте наступні дії:

Більш детальну інформацію ви можете прочитати в Базі Знань Microsoft, стаття Q324144.

Якщо ви хочете використовувати Аутентифікацію Kerberos (механізм єдиного входу на сервер) з браузерами Microsoft, будь ласка прочитайте статтю "HTTP-Based Cross-Platform Authentication via the Negotiate Protocol" в документації Microsoft, яка знаходиться на MSDN.

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

Якщо клієнт відправляє такий сертифікат, то адреса електронної пошти, вказану в елементі subjectAltName Сертифікату (якщо є) або в поле електронної пошти в елементі Subject може бути використаний для Аутентифікації по Сертифікату. Ця електронна адреса інтерпретується як ім'я Користувача, який повинен увійти на сервер CommuniGate Pro.

Зверніть увагу: після того як результуючий ім'я Користувача оброблено маршрутизатором, сервер перевіряє, що Користувач належить тому ж домену, що і сертифікат, щоб уникнути доступу в домени, які не контролюються адміністратором поточного домену.

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

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

Сервер CommuniGate Pro може використовувати програму Зовнішнього Помічника для аутентифікації користувачів. Ця програма створюється вашим технічним персоналом і в ній реалізуються необхідні для вашого сайту механізми аутентифікації, безпосередньо не підтримуються сервером CommuniGate Pro.

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

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

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

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

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

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

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

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

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

Ховати повідомлення Невідоме ім'я Якщо ця опція включена, то Сервер не буде відправляти повідомлення Невідоме ім'я і Невірний Пароль. Замість цих обох повідомлень буде відправлятися повідомлення Неправильне ім'я користувача або пароль.

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

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

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

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

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

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

Може Все (право Майстер) Якщо користувачеві надано це право, він має повний доступ до всіх компонентів Сервера. Може змінювати установки Сервера (право Налаштування) Це право дозволяє користувачеві змінювати конфігурацію всіх модулів і компонентів CommuniGate Pro (SMTP, POP, Маршрутизатор і т.д.)) може змінювати установки Довідника (право Довідник) Це право дозволяє користувачеві змінювати конфігурацію системного довідника Може змінювати установки Всіх доменів і користувачів (право Все Користувачі) Ця настройка вказує, чи може користувач створювати, перейменовувати і видаляти Домени, користувачів і інші Об'єкти, а також змінювати Установки доменів, користувачів та інших Об'єктів. Може спостерігати за Сервером (право Спостерігати) Ця настройка вказує, чи може користувач дивитися Системні Журнали Сервера, спостерігати за Чергами Сервера і т.д.

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

Може змінювати установки Цього Домену і його користувачів: Ця настройка вказує, чи може користувач створювати, перейменовувати і видаляти інших користувачів у своєму власному домені, а також змінювати деякі Установки Домену. Зазвичай ви надаєте такі права користувачеві ( "господареві домену"), який буде обслуговувати цей домен.

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

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

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

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

Вхід з не-Клієнтських Адрес Коли ця опція має значення Заборонити, всі операції "входу" (необхідні для POP, IMAP, SIP, XMPP, Веб Інтерфейсу Користувача, ACAP, PWD і т.д.) здійснюються тільки з комп'ютера, на якому працює сервер і з Мережевих Адрес Клієнтів .

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

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

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

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

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

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

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

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

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

AUTH SESSIONID userName session-ID
Для IMAP модуля операція аутентифікації SESSIONID виглядає як: AUTHENTICATE SESSIONID bindata
де bindata це такі дані, закодовані в base64: userName session-ID

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

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

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

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

null @ null Цей елемент ACL задає права доступу, що надаються "гостям" (всім нерозпізнаних користувачів). anyone Цей елемент ACL задає права доступу, що надаються кожному (всім аутентифицироваться користувачами). anyone @ Цей елемент ACL задає права доступу, які надаються всім Користувачам з цього ж домена CommuniGate Pro. anyone @ domainName Цей елемент ACL задає права доступу, які надаються всім Користувачам CommuniGate Pro з Домену domainName. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену. accountName Цей елемент ACL задає права доступу, що надаються Користувачеві accountName в тому ж домені CommuniGate Pro. Ім'я accountName має бути справжнім ім'ям Користувача і не може бути Псевдонімом Користувача або Переадресатором. accountname @ domainname Цей елемент ACL задає права доступу, що надаються Користувачеві CommuniGate Pro з іншого Домена. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену. # GroupName Цей елемент ACL задає права доступу, які надаються всім учасникам групи groupName (з того ж Домену). # GroupName @ domainName Цей елемент ACL задає права доступу, які надаються всім учасникам групи groupName з іншого Домена в CommuniGate Pro. Ім'я domainName має бути справжнім ім'ям Домену і не може бути Псевдонімом Домену.

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

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

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

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

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

Приклади: Надання прав доступу Бачити, Входити, Читати для всіх користувачів з цього ж Домену, крім користувача John, який має тільки право Бачити, і користувача Susan, яка повинна мати права Бачити, Входити, Читати і Видаляти: anyone @ Бачити, Входити, Читати -john Входити, читати + susan Видалити Надання прав доступу Бачити, Входити, читати для всіх користувачів з іншого домена company2.com, крім користувача [email protected], який не повинен мати прав доступу взагалі, і користувача Susan з третього домену company3 .com, яка повинна мати пр ава Бачити, Входити і Видаляти. [email protected] Бачити, Входити, Читати [email protected] Бачити, Входити, Читати [email protected] Бачити, Входити, Видалити

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

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

Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью