Настройте политику паролей в AD и проверяйте пароли пользователей
какой-нибудь утилитой, возможно по словарю.
Обсудите политику использования паролей со своим руководителем.
Предоставте доступ к почтовому серверу после подключения по VPN.
Способов решения вашей проблемы много, и клиентские сертификаты IMHO
неоптимален.
11 июля 2009 г. 23:05 пользователь Igor Muratov <migor@xxxxxxxxxxxx
<mailto:migor@xxxxxxxxxxxx>> написал:
Приветствую.
Вот прочитал в документации по модулю mail ssl:
> This module ensures SSL/TLS support for POP3/IMAP/SMTP.
Configuration
> is practically identical to the configuration of the HTTP SSL
<http://wiki.nginx.org/NginxHttpSslModule> module, but
> checking client certificates is not supported
Хочу спросить. Поддержка еще не сделана или она даже не планируется?
Если не планируется то каковы причины такого решения?
Опишу простую ситуацию. Есть толпа пользователей которые сами
могут себе менять пароли. К сожалению самым популярным паролем
становится 123. Самые продвинутые используют свои трехбуквенные
инициалы или клички собак. Более того, когда крупные менеджеры
заявляют что у них есть масса других вещей которые нужно помнить и
поэтому им не до паролей, а отвечать за безопасность их данных
всеравно мне. То в такой ситуации выставлять корпоративный
почтовый сервер в инет совершенно не хочется, но приходится.
Как вариант, можно было бы сделать двухстороннюю авторизацию SSL и
тогда мне уже будет без разницы какой пароль использует
пользователь для POP3/IMAP, заодно появится возможность давать
своим людям SMTP даже когда они в разъездах и пишут из
какой-нибудь гостинницы.
Вот в такой ситуации проверка сертификата пользователя была бы
очень кстати.