Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Доменная авторизация это

Объявление

Доменная авторизация на внешних сайтах

  • Регистрация: 26.05.2004
  • Сообщений: 2054

Не припомню. Обычно все ратуют за единый сервер аутентификации.

Я бы добавил второй фактор — токен, или ОТП, или иное. А так, зачем плодить учётки?

Комментарий

  • Регистрация: 17.06.2008
  • Сообщений: 1933

Комментарий

  • Регистрация: 21.02.2012
  • Сообщений: 710

Не припомню. Обычно все ратуют за единый сервер аутентификации.

Я бы добавил второй фактор — токен, или ОТП, или иное. А так, зачем плодить учётки?

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

Админы-то в курсе, но в упор не хотят слушать. Зато кричат что использование в качестве логина адреса почту снизит безопасность в 2 раза (так как для взлома надо подобрать только пароль, а почту можно из открытых источников узнать). А то что у них сервис нельзя так подключать, так это дело второстепенное.

Комментарий

  • Регистрация: 26.05.2004
  • Сообщений: 2054

Комментарий

  • Регистрация: 15.06.2004
  • Сообщений: 607

Комментарий

  • Регистрация: 21.02.2012
  • Сообщений: 710

Комментарий

  • Регистрация: 26.05.2004
  • Сообщений: 2054

Комментарий

  • Регистрация: 17.06.2008
  • Сообщений: 1426

Ну так там же хеши ходят, т.е. если сайт ломанут, можно смело считать, что пароли всех логинившихся доменных пользователей утекли (что в общем не зависит Керберос или НТЛМ)
Да и Микрософт не рекомендует, вообще, доменную аутентификацию для интернет сайтов —

Windows authentication is best suited for an intranet environment for the following reasons:+

  • Client computers and Web servers are in the same domain.
  • Administrators can make sure that every client browser is Internet Explorer 2.0 or later.
  • HTTP proxy connections, which are not supported by NTLM, are not required.
  • Kerberos version 5 requires a connection to Active Directory, which is not feasible in an Internet environment.

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Пошаговый ввод в домен Windows 10

Погружение в Iptables – теория и настройка

Топ – 25 худших паролей за 2019 год

Установка SSL сертификата на IIS – сервере

Что такое Active Directory и LDAP?

Работаем с каталогами

4 минуты чтения

Active Directory, который является службой каталогов играет такую важную роль в структуре ИТ-инфраструктуры большинства организаций.

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

Коротко говоря: AD — это база данных служб каталогов, а LDAP — один из протоколов, которые вы можете использовать для общения с ней. LDAP — это протокол, а Active Directory — это сервер.

Что такое 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 (Lightweight Directory Access Protocol) — это открытый и кроссплатформенный протокол, используемый для аутентификации служб каталогов.

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

Как Active Directory и LDAP работают вместе?

Active Directory поддерживает LDAP, что означает, что вы можете объединить их, чтобы улучшить управление доступом. Фактически, многие различные службы каталогов и решения для управления доступом могут понимать LDAP, что делает его широко используемым в средах без Active Directory.

Что такое аутентификация LDAP?

В LDAP v3 есть два варианта аутентификации LDAP — простой и SASL (Simple Authentication and Security Layer).

Простая аутентификация допускает три возможных механизма аутентификации:

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

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

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

Что такое запрос LDAP?

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

Синтаксис не очень простой, но в официальном вики можно найти много примеров.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Читать еще:  Обновление доменной политики команда

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Обзор возможностей Active Directory: фундамент для инфраструктуры

Службы Active Directory (AD) — решение от компании Microsoft позволяющее объединить различные объекты сети (компьютеры, сервера, принтера, различные сервисы) в единую систему. В данном случае AD выступают в роли каталога (базы данных), в котором хранится информация о пользователях, ПК, серверах, сетевых и периферийных устройствах.

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

Давайте разберемся в возможностях Active Directory, а также особенностях реализации, необходимых для надежной работы.

Единая точка аутентификации

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

Удобное управление политиками

С помощью Active Directory можно поделить компьютеры на различные рабочие группы (организационные подразделения). Это существенно упрощает использование инфраструктуры в двух случаях:

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

В зависимости от пользователя (учетной записи, которая используется) и его группы можно ввести ограничение на использование функционала операционной системы. Например, вы можете ограничить установку приложений всем кроме администраторов.

Безопасность

Службы Active Directory существенно увеличивают защиту корпоративной сети. Так, все данные (учетные записи) хранятся на контроллерах доступа, которые защищены от внешнего доступа. Кроме того, для аутентификации в AD используется протокол Kerberos (протокол для взаимной аутентификации клиента и сервера перед установкой соединения, в нем учтена перехвата и модификации пакетов, что повышает его надежность), который значительно безопаснее аналога в рабочих группах.

Удобный обмен файлами

С помощью AD достаточно легко реализуется технология Distributed File System (DFS), которая используется для управления файлами. Фактически, это распределенная сеть для хранения файлов — физически они располагаются на нескольких серверах, но логически находятся в одном месте.

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

Интеграция сервисов и оборудования

Службы Active Directory позволяют организовать все оборудование и сервисы в единую систему. Например, присутствует поддержка стандарта LDAP (протокол для доступа к службе каталогов X.500), который позволяет работать с почтовыми и прокси серверами (Exchange Server и ISA Server соответственно). Поддерживаются не только продукты Microsoft, но и сторонние решения:

  • IP-телефония;
  • 1С;
  • шлюз удаленных рабочих столов (Remote Desktop Gateway).

Стоит отметить, возможность интеграции с Windows Server используя протокол RADIUS. Благодаря которому можно использовать VPN подключение для работы вне офиса.

Особенности Active Directory

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

Наличие дублирующего контроллера доменов

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

Регулярные бэкапы

Надежная система резервного копирования позволяет быстро восстановить работоспособность сервера. При использовании одного контроллера доменов резервное копирование не позволяет избежать простоя, но значительно снижает временные затраты на восстановление сервера.

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

Внедрение Active Directory

Как видим, работоспособность служб AD влияет на возможность использовать всю IT-инфраструктуру компании. Поэтому рациональнее обратиться к квалифицированным специалистам, что позволит достичь максимальной надежности. Наши сотрудники обладают большим опытом работы с Active Directory (службы используются внутри компании) и оказывают услуги по внедрению (разработке с нуля), настройке и поддержке AD. Кроме того, специалисты IT-Lite могут выполнить миграцию со старых версий Active Directory на новые.

Отключение NTLM аутентификации в домене Windows

NTLM (NT LAN Manager) – это довольно старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим особенности процесс отключения протокола NTLMv1 и NTLMv2, и перехода на Kerberos в домене Active Directory.

Основные проблема NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA, который может извлечь различными утилитами (типа mimikatz) и использовать хэш для дальнейших атак, отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.

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

Переключаемся на использование NTLMv2

Если вы задумались полностью отказаться от NTLM в своем домене, сначала нужно убедиться, что у вас не используется его более уязвимая версия- NTLMv1. Вероятно в вашей сети имеется ряд устаревших устройств или служб, которые все еще используют аутентификацию NTLMv1 вместо NTLMv2 (или Kerberos). Поэтому прежде, чем прибегнуть к его полному отключению прочитайте раздел этой статьи по аудиту событий авторизации с помощью NTLM.

Читать еще:  Понижение контроллера домена

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

Тип аутентификации можно задать с помощью доменной (или локальной) политики. Откройте консоль управления доменными политиками и отредактируйте Default Domain Policy. Перейдите в раздел Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options и найдите политику

Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).

В настройках политики есть 6 опций:

  • Send LM & NTLM responses;
  • Send LM & NTLM responses – use NTLMv2 session security if negotiated;
  • Send NTLM response only;
  • Send NTLMv2 response only;
  • Send NTLMv2 response only. Refuse LM;
  • Send NTLMv2 response only. Refuse LM& NTLM.

Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.

Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.

Также вы можете отключить NTLMv1 через реестр. Для этого в ветке

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».

Не забудьте применить эту политику для контроллеров домена.

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

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

Аудит событий NTLM аутентификации в домене

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

Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. В разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.

Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.

После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM.

Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.

Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.

Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.

Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:

$ADDCs = Get-ADDomainController -filter * -Server winitpro.ru
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = «c:psEvents$($Yesterday.ToString(‘yyyyMMdd’))_AD_NTLMv1_events.log»
function GetEvents($DC)<
Write-Host «Searching log on » $DC.HostName
$Events = Get-EventLog «Security» -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message «*V1*» -instanceid 4624
foreach($Event in $Events)<
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject «$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)» -Append
>
>
foreach($DC in $ADDCs)

После того, как вы нашли пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для работы Kerberos авторизации (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.

Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.

Полное отключение NTLM в домене Active Directory

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

Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.

Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.

В этой политике доступно 5 опций:

  • Disable: политика отключена (NTLM аутентификация в домене разрешена);
  • Deny for domain accounts to domain servers: контролеры домена запрещают попытки аутентификации NTLM для всех серверов под доменными аккаунтами, возвращается ошибка «NTLM заблокирован»;
  • Deny for domain accounts: контролеры домена запрещают попытки NTLM аутентификации для всех учетных записей домена, возвращается ошибка «NTLM заблокирован»;
  • Deny for domain servers: запрещены запросы NTLM аутентификации для всех серверов;
  • Deny all: контроллеры домена блокируют все запросы NTLM для всех серверов и учетных записей.
Читать еще:  Основной контроллер домена

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

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

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

Интегрированная аутентификация Windows поддерживает как протокол Kerberos v5, так и протокол NTLM (NT LAN Manager ) для аутентификации посредством пакета Negotiate . При наличии Active Directory и соответствующей поддержке браузером (IE 5 или выше на платформе Windows 2000) используется протокол Kerberos, иначе – протокол NTLM . Как Kerberos, так и NTLM имеют некоторые ограничения. Интересен тот факт, что преимущества одного соответствуют слабым местам другого. Kerberos, как правило, работает с прокси-серверами, но с межсетевыми экранами его функционирование не столь эффективно. NTLM обычно работает через межсетевые экраны, но достаточно посредственно взаимодействует с прокси-серверами.

Несколько слов о Microsoft Negotiate

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

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

NTLM представляет собой расширенную версию старого протокола аутентификации LM ( LAN Manager ). NTLM работает посредством вопросов/ответов между сервером и клиентом без передачи пароля пользователя через сеть в открытом виде. Клиент должен подтвердить то, что он знает пароль пользователя, посредством отправки зашифрованного хэша.

NTLM функционирует следующим образом.

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

Аутентификация 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 .

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×