Для работы со службами POP3 и IMAP4 используются три параметра проверки подлинности. Эти параметры настраиваются с помощью консоли управления или с помощью командлетов Set-PopSettings и Set-ImapSettings в командной консоли. Порты по умолчанию зависят от выбранного параметра проверки подлинности.
В следующей таблице приведены различные методы проверки подлинности, которые могут использоваться для служб POP3 и IMAP4, а также порты по умолчанию для каждого метода.
Параметры проверки подлинности для POP3 и IMAP4
TLS-шифрование для порта 110 не требуется.
Имя пользователя и пароль отправляются в зашифрованном виде, если базовое соединение не зашифровано с применением TLS или SSL.
В отношении IMAP4 это соответствует применению команды «login» для проверки подлинности для компьютера Exchange 2010, на котором установлена роль сервера почтовых ящиков.
TLS-шифрование для портов 110 и 143 не требуется. Однако обычная проверка подлинности разрешена только для порта, на котором используется TLS-шифрование или SSL-шифрование.
Клиент серверная архитектура / Урок 20 / Тестировщик с нуля
В отношении IMAP4 это соответствует команде authenticate для проверки подлинности на сервере почтовых ящиков.
Для проверки подлинности при соединении через порт 110 и порт 143 должно применяться TLS-шифрование.
| Встроенная проверка подлинности Windows (NTLM) не поддерживается для подключения клиентов через POP3 или IMAP4. Дополнительные сведения см. в подразделе «Компоненты клиентского доступа» раздела Устаревшие возможности и сокращенная функциональность. |
Источник: unifiedpeople.ru
Способы проверки подлинности используемые программой клиентом
Сведения о сценариях, в которых используются эти методы, см. в разделе Общие сведения о проверке подлинности в Forefront TMG.
Проверка подлинности HTTP
Forefront TMG поддерживает следующие типы проверки подлинности HTTP:
Обычная проверка подлинности
Обычная проверка подлинности – широко применяемый метод, который состоит в сборе таких сведений, как имя пользователя и пароль. При обычной проверке подлинности сведения о пользователе отправляют и получают в виде текстовых символов, которые можно прочитать. Хотя пароли и имена пользователей подлежат шифрованию, при обычной проверке подлинности шифрование не используется.
Ниже описывается, как происходит проверка подлинности клиента при обычной проверке подлинности.
-
Пользователю предлагается ввести имя и пароль для входа в учетную запись Windows.
Преимущество обычной проверки подлинности состоит в том, что она поддерживается практически всеми HTTP-клиентами. Недостатком является то, что при использовании обычной проверки подлинности веб-обозреватели передают пароли в незашифрованной форме. Наблюдая за действиями пользователя в сети, взломщик или пользователь-злоумышленник может перехватить и раскодировать пароли с помощью общедоступных средств. Поэтому не рекомендуется использовать обычную проверку подлинности, если пользователь не уверен, что связь защищена, например, при пользовании выделенной линией или соединением по SSL-протоколу.
КАК УБРАТЬ ПРОВЕРКУ ПОДЛИННОСТИ НА WINDOWS БЕЗ ПРОГРАММ 2019
Проверка подлинности Digest и WDigest
Дайджест-проверка подлинности предлагает такие же возможности, как и обычная проверка подлинности, но отличается более защищенным способом передачи учетных данных.
Проверка подлинности дайджест использует протокол HTTP 1.1 согласно определению RFC 2617 (http://go.microsoft.com/fwlink/?LinkId=160622). Этот протокол поддерживается не всеми обозревателями. Если обозреватель, не поддерживающий протокол HTTP 1.1, запрашивает файл при включенной проверке подлинности Digest, запрос отклоняется. Проверка подлинности Digest может использоваться только в доменах Windows.
Дайджест-проверка подлинности успешно применима, если на контроллере домена в доменной службе Active Directory хранится обратимая зашифрованная (текстовая) копия запроса пароля пользователя. Чтобы разрешить хранение паролей в незашифрованном текстовом виде, необходимо в доменной службе Active Directory активировать настройку Хранить пароль с использованием обратимого шифрования на вкладке Учетная запись. Также пользователь может включить данную функцию, установив соответствующую групповую политику. После настройки этого параметра необходимо установить новый пароль для активации этой функции, так как старый пароль не может быть определен.
W-дайджест, обновленная форма проверки подлинности дайджест, используется, если Forefront TMG установлен в домене Windows Server 2008. Проверка подлинности W-дайджест не требует, чтобы в доменной службе Active Directory хранилась обратимая зашифрованная копия пароля пользователя.
Проверка подлинности Digest и WDigest осуществляется следующим образом:
-
Клиент делает запрос.
встроенная проверка подлинности Windows
Встроенная проверка подлинности Windows использует методы проверки подлинности NTLM, Kerberos и Negotiate. Это более безопасные формы проверки подлинности, поскольку имя пользователя и пароль хэшируются до отправления их по сети. Если включена проверка подлинности NTLM, Kerberos или Negotiate, обозреватель пользователя подтверждает пароль при помощи обмена криптографическими данными с сервером Forefront TMG и хэширования.
Ниже описывается, как происходит проверка подлинности клиента при встроенной проверке подлинности Windows.
-
В зависимости от настроек обозревателя проверка подлинности может не запрашивать изначально имя пользователя и пароль. Если изначально не удается идентифицировать пользователя, обозреватель запрашивает имя пользователя и пароль для входа в учетную запись Windows, которые он обрабатывает с помощью встроенной проверки подлинности Windows. Веб-браузер продолжает запрашивать имя пользователя и пароль до тех пор, пока пользователь не введет достоверные сведения или не закроет диалоговое окно с запросом. Имя пользователя необходимо вводить в формате: доменимя_пользователя
Проверка подлинности на основе форм
Проверка подлинности на основе форм в Forefront TMG может использоваться для входящих запросов на опубликованные веб-серверы.
Существует три типа проверки подлинности на основе форм:
-
Форма для ввода пароля. В эту форму вводятся имя пользователя и пароль. Эти типы учетных данных необходим для проверки подлинности с помощью доменной службы Active Directory, LDAP и RADIUS.
Проверка подлинности сертификата клиента
Проверка подлинности сертификата клиента не поддерживается для исходящих веб-запросов.
Для входящих запросов на опубликованные ресурсы требование сертификата клиента может повысить безопасность опубликованного сервера пользователя. Пользователи могут получить сертификаты клиента в коммерческом (CA) или внутреннем центре сертификации организации пользователя. Сертификаты могут быть в виде смарт-карт или использоваться мобильными устройствами так, чтобы они могли подключаться к Microsoft ActiveSync.
Сертификат должен согласовываться с учетной записью пользователя. Когда пользователи делают запросы на опубликованные ресурсы, сертификат клиента, отправленный в Forefront TMG, передается на контроллер домена, который определяет соответствие между сертификатами и учетными записями. Forefront TMG должен являться членом домена.
Сведения передаются обратно на Forefront TMG для применения соответствующих правил политики межсетевого экрана. Примечание. Forefront TMG не может передавать сертификаты клиента на внутренний веб-сервер.
Источник: certsrv.ru
Основные сведения о проверке подлинности HTTP
Проверка подлинности — это процесс определения того, кто является клиентом. Обычно это позволяет определить, имеет ли клиент доступ к ресурсу. Протокол HTTP поддерживает проверку подлинности как средство согласования доступа к защищенному ресурсу.
Исходный запрос от клиента как правило является анонимными и не содержит информацию для проверки подлинности. Приложения HTTP-сервера могут отклонять анонимный запрос, указывая, что требуется проверка подлинности. Серверные приложения отправляют заголовки WWW-Authentication для указания поддерживаемых схем проверки подлинности. В этой статье описывается несколько схем проверки подлинности для HTTP и рассматривается их поддержка в Windows Communication Foundation (WCF).
Схемы проверки подлинности HTTP
Сервер может указать несколько схем проверки подлинности для клиента. В следующей таблице описаны некоторые схемы проверки подлинности, которые обычно встречаются в приложениях Windows.
Выбор схемы проверки подлинности
При выборе потенциальной схемы проверки подлинности для HTTP-сервера необходимо учитывать несколько моментов.
- Рассмотрите, требуется ли защита ресурса. Использование проверки подлинности HTTP требует передачи большего объема данных и может ограничить взаимодействие с клиентами. Разрешить анонимный доступ к ресурсам, которые не нужно защищать.
- Если требуется защита ресурса, проанализируйте, какая схема проверки подлинности обеспечит требуемый уровень безопасности. Самая слабая стандартная схема проверки подлинности, описанная здесь, — обычная проверка подлинности. Обычная проверка подлинности не защищает учетные данные пользователя. Самая стойкая стандартная схема проверка подлинности — проверка подлинности Negotiate, реализованная в протоколе Kerberos.
- Сервер не должен содержать, например, в заголовках WWW-Authentication) схему, которую он не готов принять или которая не обеспечивает надлежащую защиту защищенного ресурса. Клиент свободен в выборе любой схемы проверки подлинности, предоставляемой сервером. Некоторые клиенты выбирают по умолчанию слабую схему проверки подлинности или первую схему проверки подлинности в списке сервера.
См. также раздел
- Общие сведения о безопасности транспорта
- Использование олицетворения при обеспечении безопасности транспорта
- Делегирование и олицетворение
Источник: learn.microsoft.com