НОУ ИНТУИТ | Лекция | Аутентификация

Что такое active directory?

Active Directory – это реализация служб каталогов, которая предоставляет все виды функций, таких как аутентификация, управление группами и пользователями, администрирование политик и многое другое. Active Directory служит единым хранилищем данных для быстрого доступа к данным для всех пользователей и контролирует доступ для пользователей на основе политики безопасности каталога.

Active Directory (AD) поддерживает как Kerberos, так и LDAP – Microsoft AD на сегодняшний день является наиболее распространенной системой служб каталогов, используемой сегодня. AD обеспечивает Single-SignOn (SSO) и хорошо работает в офисе и через VPN.

AD и Kerberos не являются кроссплатформенными, что является одной из причин, по которой компании внедряют программное обеспечение для управления доступом для управления входами с разных устройств и платформ в одном месте. AD поддерживает LDAP, что означает, что он все еще может быть частью вашей общей схемы управления доступом.

Active Directory – это только один пример службы каталогов, которая поддерживает LDAP. Также есть и другие варианты: служба каталогов Red Hat, OpenLDAP, сервер каталогов Apache и другие.

А еще Active Directory можено интегрировать с Asterisk

Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными

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

В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.

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

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

Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать

В одном из моих прошлых постов

описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.

Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало.

Введение

Сразу отмечу, что в качестве Веб-интерфейса я использую OpenSearch-Dashboards. И в основном именно для OpenSearch-Dashboards мне нужна доменная авторизация.

Для того, чтобы настроить аутентификацию и авторизацию доменных пользователей Active Directory в OpenSearch по протоколу LDAP необходимо сконфигурировать файл «/plugins/opensearch-security/securityconfig/config.yml» (в моем случае полный путь к этому файлу такой «/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml»).

Что такое ldap?

LDAP (Lightweight Directory Access Protocol) – это открытый и кроссплатформенный протокол, используемый для аутентификации служб каталогов.

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

Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных

LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.

Коротко об объектах настройки конфиденциальности в OpenSearch

В OpenSearch, как и во многих других системах, для распределения привилегий в системе используются учетные записи.

Каждая учетная запись может иметь набор прав доступов, которые наделяют пользователя полномочиями.

Определенный набор прав доступов объединяется в роль. Пользователь может иметь как одну, так и несколько ролей. В случае, когда пользователю назначены несколько ролей, права доступов которых противоречат друг другу, преимущество имеют права, дающие пользователю больший доступ.

Например, если дать права администратора и наблюдателя одновременно, то фактически пользователь будет иметь права администратора.

А вот «Backend» роль сущность несколько абстрактная. «Обычная» роль может иметь «Backend» роль или даже несколько «Backend» ролей. Пользователь тоже может иметь «Backend» роль или даже несколько «Backend» ролей. Если «Backend» роль есть у пользователя, и эта же «Backend» роль есть у «обычной» роли, то такой пользователь становится обладателем этой «обычной» роли.

«Backend» роли становятся актуальными для использования при доменной авторизации. Потому как доменные пользователи не доступны для настройки прав или «обычных» ролей, они могут получить только «Backend» роль автоматически, в зависимости от настроенной конфигурации.

Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом

При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.

Ниже представлены примеры ужасов некорректной настройки.

  • Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
  • Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
  • Отправка паролей в открытом виде на 389-й порт.
  • Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?

Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.

Настройка LDAP

Для наглядности я сразу приведу уже сконфигурированный файл «config.yml» целиком (в моем случае это файл «/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml»).

/opt/opensearch/plugins/opensearch-security/securityconfig/config.yml

---
# This is the main OpenSearch Security configuration file where authentication
# and authorization is defined.

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    # Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index
    # Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default)
    # Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently
    #filtered_alias_mode: warn
    #do_not_fail_on_forbidden: false
    #kibana:
    # Kibana multitenancy
    #multitenancy_enabled: true
    #server_username: kibanaserver
    #index: '.kibana'
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192.168.0.10|192.168.0.11' # regex pattern
        #internalProxies: '.*' # trust all internal proxies, regex pattern
        #remoteIpHeader:  'x-forwarded-for'
        ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
        ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
        ###### and here https://tools.ietf.org/html/rfc7239
        ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
    authc:
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            # If true a lot of kerberos/security related debugging output will be logged to standard out
            krb_debug: false
            # If true then the realm will be stripped from the user name
            strip_realm_from_principal: true
        authentication_backend:
          type: noop
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      proxy_auth_domain:
        description: "Authenticate via proxy"
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          type: proxy
          challenge: false
          config:
            user_header: "x-proxy-user"
            roles_header: "x-proxy-roles"
        authentication_backend:
          type: noop
      jwt_auth_domain:
        description: "Authenticate via Json Web Token"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: jwt
          challenge: false
          config:
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            jwt_header: "Authorization"
            jwt_url_parameter: null
            roles_key: null
            subject_key: null
        authentication_backend:
          type: noop
      clientcert_auth_domain:
        description: "Authenticate via SSL client certificates"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: clientcert
          config:
            username_attribute: cn #optional, if omitted DN becomes username
          challenge: false
        authentication_backend:
          type: noop
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        order: 5
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - server-ad.my.big.domain:389
            bind_dn: 'cn=user_for_LDAP,ou=Service Accounts,ou=Moscow,dc=MY,dc=BIG,dc=DOMAIN'
            password: 'Au5dUJ9q!54S'
            users:
              1-userbase:
                base: 'CN=Пушкин Александр Сергеевич (PushkinAS),OU=Users,OU=Saint_Petersburg,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              2-userbase:
                base: 'CN=Горький Максим (GorkiiM),OU=Users,OU=Nizhny_Novgorod,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              3-userbase:
                base: 'CN=Толстой Лев Николаевич (TolstoiLN),OU=Users,OU=Yasnaya_Polyana,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
            username_attribute: 'cn'
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        authorization_backend:
          # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
              - server-ad.my.big.domain:389
            bind_dn: 'cn=user_for_LDAP,ou=Service Accounts,ou=Moscow,dc=MY,dc=BIG,dc=DOMAIN'
            password: 'Au5dUJ9q!54S'
            users:
              1-userbase:
                base: 'CN=Пушкин Александр Сергеевич (PushkinAS),OU=Users,OU=Saint_Petersburg,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              2-userbase:
                base: 'CN=Горький Максим (GorkiiM),OU=Users,OU=Nizhny_Novgorod,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
              3-userbase:
                base: 'CN=Толстой Лев Николаевич (TolstoiLN),OU=Users,OU=Yasnaya_Polyana,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(sAMAccountName={0})'
            username_attribute: 'cn'
            roles:
              1-rolebase:
                base: 'CN=Department05-Developers,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
              2-rolebase:
                base: 'CN=Department05-Admins,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
              3-rolebase:
                base: 'CN=Department05-Analysts,OU=Groups,OU=Moscow,DC=MY,DC=BIG,DC=DOMAIN'
                search: '(member={0})'
            userroleattribute: null
            userrolename: memberOf, SamAccountName
            rolename: "cn"
            resolve_nested_roles: false
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: ldap

Похожее:  Как зарегистрироваться и войти в личный кабинет Yota |


Описание всех параметров вы можете посмотреть на официальном сайте OpenSearch (

LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга

Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей).

Получаем полный путь к объектам в AD

Полный путь к группе в AD через PowerShell можно получить так:

$group = ([adsisearcher]“(&(objectcategory=group)(cn=name_of_group))”).Findall()
$group

Вместо «name_of_group» подставьте название нужной вам группы.


Полный путь к пользователю в AD через PowerShell можно получить так:

Проблема применения настроек

Выполнение команды для применения настроек удаляет все изменения, сделанные в OpenSearch-Dashboards в разделе «Security», то есть все настройки пользователей и ролей. И это является проблемой, так как в конфигурацию со временем будет необходимо добавлять новых пользователей и удалять старых пользователей.

Видимо разработчики OpenSearch всё же подразумевают, что все пользователи в AD лежат в одном каталоге и «лишних» пользователей там нет. Либо всё-таки подразумевается использование проксирующего LDAP сервера. Другого объяснения я не нашел.

Для того чтобы обойти эту проблему можно вносить изменения не в Web-интерфейсе (OpenSearch-Dashboards), а через файлы конфигураций.


Далее опишу настройку конфигурационных файлов.

Lan manager (lm)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

Исходя из современных требований к безопасности можно сказать, что LM-хэш практически не защищен и будучи перехвачен очень быстро расшифровывается. Сразу оговоримся, прямое восстановление хэша невозможно, однако в силу простоты алгоритма шифрования возможен подбор соответствующей паролю комбинации за предельно короткое время.

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

Ntlmv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число – запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Аутентификация kerberos

В древнегреческой мифологии Керберос – это сказочная трехглавая собака,
охранявшая подземный мир от людей. В настоящее время термином Kerberos
называется протокол безопасной аутентификации для доступа к ресурсам.
Kerberos основывается на аутентификации с секретным ключом, при которой
клиент и сервер используют один и тот же ключ для шифрования и
расшифровки.

Клиент доказывает знание ключа посредством шифрования
сообщения, а сервер доказывает знание ключа посредством расшифровки
этого сообщения. Затем сервер берет часть сообщения, шифрует ее и
отправляет клиенту. При сохранении целостности сообщения результат
аутентификации будет положительным.

Работа Kerberos основывается на центральном сервере, называемом Key
Distribution Center (KDC) (Центр распределения ключей), который
предоставляет все необходимые ключи. KDC выпускает так называемые
билеты TGT (Ticket-Granting Tickets) (“Билеты для получения билетов”) и
предоставляет их клиентам, запрашивающим доступ к ресурсу на сервере.

Ниже показан процесс получения клиентом начального билета TGT.

  1. Пользователь осуществляет вход на компьютер-клиент с указанием имени
    пользователя и пароля.
  2. Клиент шифрует пароль и сохраняет его.
  3. Клиент отправляет KDC сообщение с запросом на аутентификационные
    данные для службы TGT, а также зашифрованный пароль пользователя.
  4. KDC сравнивает зашифрованный пароль со своей эталонной копией для
    проверки их идентичности. Также осуществляется проверка временного
    штампа, приложенного клиентом к запросу, для подтверждения того, что
    указанное в штампе время находится в пределах пяти минут собственного
    времени KDC.
  5. В случае полного соответствия KDC создает запрошенные
    аутентификационные данные для службы TGT посредством генерации
    сеансового ключа входа и шифрования его на пользовательском ключе.
  6. KDC создает другой фрагмент аутентификационных данных посредством
    шифрования сеансового ключа входа и TGT пользователя своим собственным
    эталонным ключом.
  7. KDC отправляет оба фрагмента аутентификационных данных клиенту.
  8. Клиент расшифровывает сеансовый ключ входа из первого отрезка
    аутентификационных данных с помощью зашифрованного пароля и сохраняет
    этот сеансовый ключ входа в кэше своего билета.
  9. Клиент также сохраняет TGT в своем кэше билета.
Похожее:  Мосэнергосбыт личный кабинет для физических лиц

Теперь у клиента есть TGT, и он может использовать его для получения
билетов на доступ к ресурсам. Вот как это происходит.

  1. Клиент запрашивает у KDC билет на доступ к ресурсам на сервере.
    Клиент предоставляет свой TGT центру KDC вместе с именем нужного
    ресурса и аутентификационным сообщением, зашифрованным на сеансовом
    ключе входа.
  2. KDC расшифровывает TGT с помощью эталонного ключа, извлекает
    сеансовый ключ входа и использует его для расшифровки
    аутентификационного сообщения. Если оно совпадает с эталоном,
    подлинность клиента подтверждается.
  3. KDC создает сеансовый ключ службы для клиента, предназначенный для
    представления серверу при подаче запросов на ресурсы, и шифрует
    сеансовый ключ службы на сеансовом ключе входа клиента.
  4. KDC шифрует сеансовый ключ входа с использование эталонного ключа
    сервера, в результате чего создается билет.
  5. KDC передает клиенту оба фрагмента аутентификационных данных клиенту,
    который расшифровывает сеансовый ключ с помощью своего сеансового ключа
    входа и сохраняет сеансовый ключ службы и билет в своем кэше.

Теперь у клиента есть билет, с помощью которого он получает доступ к
ресурсам на сервере.

  1. Клиент передает серверу сеансовый билет и аутентификационное
    сообщение, зашифрованное на сеансовом ключе службы.
  2. Сервер расшифровывает сеансовый билет и проверяет временной штамп
    клиента на запросе (значение штампа должно находиться в пятиминутном
    интервале собственного времени сервера). Затем сервер получает из
    данного билета сеансовый ключ.
  3. Сервер шифрует временной штамп сеансового билета на сеансовом ключе,
    после чего отправляет его клиенту.
  4. Клиент расшифровывает сообщение и сравнивает временной штамп с
    оригиналом. Если все совпадает, процесс аутентификации считается
    успешно завершенным.

Это очень сложный процесс, но он обеспечивает подлинность каждого лица,
устанавливающего соединение. Очевидно, что KDC играет важную роль в
данном процессе, поэтому необходимо обеспечить безопасность центра KDC.

Аутентификация посредством .net passport

IIS 6 может использовать паспорт Microsoft .NETPassport для
аутентификации пользователей, запрашивающих ресурсы на веб-сайте или в
виртуальном каталоге веб-сайта.

Преимуществом данного подхода является
то, что аутентификационные данные сохраняются и управляются другим
сервером, за работу которого пользователь не несет никакой
ответственности. Пользователи проходят аутентификацию с помощью службы
.NETPassport и затем осуществляют доступ к веб-сайту, расположенному
на сервере WS03.

Тем не менее, данная служба не обеспечивает контроль
доступа или авторизацию сайта. Сервер .NETPassport может лишь
подтверждать тот факт, что веб-потребитель, представляющий себя в
качестве лица, имеющего профиль на сервере .NETPassport, успешно
прошел аутентификацию как лицо, представленное имеющимся профилем.

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

Паспорт обеспечивает удобную систему аутентификации для всех
пользователей, вовлеченных в работу с интернетом, поскольку
предоставляет простую процедуру входа на любой веб-сайт, аутентификация
на котором осуществляется при помощи .NETPassport.

Преимуществом этого
подхода является тот факт, что стороне, обеспечивающей работу сайта, не
требуется создавать и поддерживать работу своей системы или своего
сервера аутентификации, однако за пользование услугами Microsoft .NETPassport ей придется платить определенную сумму.

После создания учетной
записи в службе .NETPassport нужно создать веб-страницу на сервере,
содержащем сайт, обеспечивающую аутентификацию пользователей. Для этого
придется затратить не больше усилий, чем для любого “казенного”
механизма регистрации и аутентификации, работа которого не зависит от
расположения аутентификационных данных зарегистрированных
пользователей. Но в данном случае взаимодействие осуществляется только
с аутентифицированными пользователями.

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

Существующие в
интернете электронные магазины и порталы без особого энтузиазма
воспринимают .NETPassport, поскольку уже имеют собственные системы
аутентификации. Преимущества единой системы аутентификации в интернете
сводятся к нулю, когда веб-потребителю приходится проходить
аутентификацию на других подконтрольных ему сайтах.

Интегрированная аутентификация windows

Интегрированная аутентификацияWindows является наиболее безопасным
методом аутентификации, однако она доступна только в Internet Explorer.
Этот тип аутентификации раньше был известен как аутентификацияNTLM и
аутентификацияWindows NT вопрос/ответ.

Интегрированная аутентификацияWindows поддерживает как протокол
Kerberos v5, так и протокол NTLM (NT LAN Manager) для аутентификации
посредством пакета Negotiate.

При наличии ActiveDirectory и
соответствующей поддержке браузером (IE 5 или выше на платформе Windows
2000) используется протокол Kerberos, иначе – протокол NTLM.

Как
Kerberos, так и NTLM имеют некоторые ограничения. Интересен тот факт,
что преимущества одного соответствуют слабым местам другого. Kerberos,
как правило, работает с прокси-серверами, но с межсетевыми экранами его
функционирование не столь эффективно. NTLM обычно работает через
межсетевые экраны, но достаточно посредственно взаимодействует с
прокси-серверами.

Использование нескольких методов аутентификации

При использовании нескольких методов аутентификации, IIS и браузер
клиента предпочитают одни схемы аутентификации другим. Применение схем
аутентификации осуществляется в следующем порядке.

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

Выполняется интегрированная аутентификацияWindows, если она включена и
совместима с браузером.

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

Наконец, если не удалось применить ни один из указанных выше методов
аутентификации, используется базоваяаутентификация.

Обратите внимание, что в данном списке отсутствует аутентификация .NETPassport. Дело в том, что это особый тип аутентификации. Если метод
аутентификации .NETPassport включен, то все остальные способы
аутентификации недоступны (хотя по-прежнему можно использовать
анонимныйдоступ).

Как работает ldap-аутентификация

Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время.

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

Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.

К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.

В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы.

Похожее:  МОСЭНЕРГОСБЫТ Личный кабинет - Вход и Регистрация

К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.

Какие есть варианты?

Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями.

Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.

Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией.

Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.

В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации.

Настройка сайта на работу с системой .net passport

Если веб-сайт или виртуальный каталог настроен на аутентификацию
пользователей посредством системы .NET Passport, то при первом запросе
пользователем файла на этом сайте появится запрос аутентификационных
данных .NET Passport.

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

Для реализации на сайте IIS аутентификации .NET Passport выполните
следующие шаги.

  1. Откройте оснастку IIS MMC и разверните узел Web Sites (Веб-узлы) в
    левой части консоли.
  2. Щелкните правой кнопкой мыши на соответствующем веб-сайте или
    виртуальном каталоге, для которого необходимо реализовать
    аутентификацию .NET Passport. Выберите Properties (Свойства).
  3. В окне Properties откройте вкладку Directory Security (Безопасность
    каталога).
  4. Нажмите на кнопку Edit (Изменить), расположенную в области
    Authentication And Access Control (Аутентификация и контроль доступа).
    Откроется окно Authentication Methods (Методы аутентификации).
  5. В области Authenticated Access (Аутентифицируемый доступ) включите
    опцию .NET Passport Authentication (Аутентификация .NET Passport).
    После выбора той опции все остальные методы аутентификации будут
    недоступны. Тем не менее, вы по-прежнему сможете выбрать анонимный
    доступ.
  6. При необходимости введите имя домена в текстовом поле Default Domain
    (Домен по умолчанию). Это домен, которому будут принадлежать имена
    пользователей на главном сервере после прохождения ими аутентификации
    .NET Passport. Для определения организации или домена при
    взаимодействии с системой, разработанной другой компанией (не
    Microsoft) можно задать Realm (Область).
  7. Нажмите на кнопку OK для закрытия окна Authentication Methods (Методы
    аутентификации). Затем нажмите на кнопку OK для закрытия окна
    Properties (Свойства).

Если служба .NET Passport настроена правильно, то пользователям
отобразится запрос .NET Passport (см. рис. 7.2), за тем исключением,
что в нем будут указаны настройки, из таблицы 7.1, а не значения по
умолчанию, показанные на рисунке 7.2.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера – Конфигурация Windows – Политики безопасности – Локальные политики – Параметры безопасности, в этом разделе найдем политикуСетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORDс именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройкиКлиентский компьютерКонтроллер доменаLm Compatibility Level
Отправлять LM- и NTLM-ответыКлиентские компьютеры используют LM и NTLMаутентификацию, и никогда не используют сеансовую безопасность NTLMv2.Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.1
Отправлять только NTLM-ответКлиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.2
Отправлять только NTLMv2-ответКлиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.3
Отправлять только NTLMv2-ответ. Отказывать LM.Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.Контроллеры домена отказываются приниматьаутентификацию LM иNTLM, и будут принимать только NTLMv2.5

Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя.

Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Я надеюсь, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Материал сайта vhod-v-lichnyj-kabinet.ru

Несколько слов о microsoft negotiate

Microsoft Negotiate представляет собой пакет, обслуживающий
интерфейс между различными поставщиками услуг по поддержке безопасности.
Он может осуществлять выбор между различными пакетами аутентификации.
IIS использует пакет Negotiate для аутентификации, и в этом случае
происходит выбор протокола Kerberos или протокола NTLM.

В данный пакет
также добавлена поддержка будущих аутентификационных пакетов, что
является преимуществом Negotiate. По умолчанию Negotiate выбирает
Kerberos как наиболее безопасный протокол.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован.

Adblock
detector