Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Аутентификация в Active Directory
Виктор Ашик, инструктор учебного центра ╚Эврика╩
В данной статье рассматриваются протоколы аутентификации, которые используются в операционной системе Microsoft Windows 2000 и службе каталогов Active Directory.
Аутентификация есть процесс проверки подлинности пользователя, т.═е. подтверждение того, что пользователь действительно имеет учетную запись и может ее использовать при обращении к службам и ресурсам. Так, аутентификация выполняется при входе (logon) пользователя в домен путем предъявления имени пользователя и пароля или смарт-карты и ее PIN (Personal Identification Number). Далее, при обращении пользователя к ресурсу или службе через сеть, также может выполняться аутентификация пользователя для определения его прав доступа. Как возникла сама задача аутентификации?
На заре развития информационных технологий компьютер был громоздкой и дорогой машиной, доступ к ней имел только специальный обслуживающий персонал, в задачи которого входило принимать от ╚пользователей╩ составленные программы и вводить их для обработки. Таким образом, доступ к системе контролировали люди. Потом у компьютера появились терминальные устройства в виде монитора с клавиатурой, и таких устройств у него могло быть несколько. Допускать к терминалам стали не только обслуживающий персонал, но и простых смертных. Так возникла задача аутентификации пользователя: нужно, чтобы перед началом работы человека компьютер определил его личность и права доступа. Для этого каждому пользователю стали присваивать имя, отличное от других, и пароль. Имя и пароль вводятся пользователем перед началом работы, имя ≈ чтобы идентифицировать пользователя, а пароль ≈ чтобы подтвердить его подлинность, т.═е. аутентичность. Имя пользователя обычно хранилось в открытом виде, а пароль ≈ в виде необратимой функции от имени пользователя и пароля, которую назвали хэш, т.═к. результат этой функции является мешаниной символов. При регистрации в системе пользователь предъявляет свое имя и пароль, из них вычисляется хэш и сравнивается с хранящимся в системе хэшем пароля этого пользователя. При совпадении аутентификация считается успешной, и для пользователя запускается его программная среда. Таким образом, в системе хранится база данных пользователей с их именами и хэшами паролей.
Потом компьютеры стали объединять в сети, и доступ пользователей к ресурсам компьютеров через сеть тоже нужно было контролировать. Прежний подход к аутентификации пользователей оказался пригоден и в сети, но у пользователя оказывалось несколько учетных записей: минимум по одной на каждой машине, к ресурсам которой он имел доступ.
Тогда базы с учетными записями пользователей решили централизовать, а хэш пароля передавать по сети. Так появились домены.
С появлением персональных компьютеров история повторилась в точности: от одиночных машин и их объединения в сети до централизации хранения баз данных с учетными записями. Одним из первых продуктов Microsoft, реализующим домен с учетными записями, стал Lan Manager.
От продукта Lan Manager в Windows NT перешел протокол аутентификации, который присутствует в этой системе в трех ипостасях: LM ≈ классический протокол аутентификации, очень низкая криптостойкость хэшей; NTLM ≈ средняя криптостойкость и NTLM v.2 (начиная с Service Pack 4) ≈ самый стойкий из этого семейства, появился после шумихи с программой L0pht Crack, щелкавшей пароли из хэшей NTLM, как орешки, оказалось, что в NTLM пароль делится на семисимвольные части, и эти части шифруются независимо.
Нововведением Windows NT стали доверительные отношения между доменами, которые предоставляют возможность пользователю одного домена получать доступ к ресурсам другого, не имея в последнем учетной записи.
Узким местом классической схемы доменов является доменный контроллер, испытывающий нагрузку, пропорциональную активности работы пользователя с сетевыми ресурсами: при каждом подключении пользователя к серверу домена последний должен обратиться за аутентификацией пользователя к доменному контроллеру. Введение резервных доменных контроллеров снижает нагрузку на отдельный контроллер, но создает в сети дополнительный трафик ≈ трафик репликации между ними.
При разработке Windows 2000 специалисты фирмы Microsoft наконец-то решили не изобретать велосипед и применили открытые стандарты, зарекомендовавшие себя в промышленном применении. В основу системы аутентификации был положен протокол Kerberos 5, решивший многие проблемы NTLM, для доступа к информации об объектах домена применили LDAP, а в качестве службы имен для поиска доменных контроллеров и обычных серверов применили DNS, снабженный возможностью динамического обновления. Для обеспечения обратной совместимости была сохранена поддержка NTLM и NTLM v.2, а также предусмотрен смешанный режим работы с наличием резервных контроллеров домена на базе Windows NT.
Протокол проверки подлинности в сетях Kerberos обязан своим названием трехголовому стражу ада из греческой мифологии, который был побежден Гераклом при совершении последнего, 12-го подвига. Более известна у нас латинская транскрипция этого имени ≈ Цербер.
Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) и предназначен для надежной аутентификации в клиент/серверных приложениях за счет применения криптографии с секретным ключом.
Спецификация протокола сделана свободной при условии сохранения авторских прав, подобно BSD и оконной системе X11. Исходные тексты Kerberos опубликованы, чтобы все специалисты по защите компьютерных систем могли с ними ознакомиться и убедиться в отсутствии брешей.
Протокол Kerberos стал доступен широкой общественности с версии 4, а его усовершенствованная версия Kerberos 5 описана в RFC 1510 и положена в основу Windows 2000.
В основу аутентификации по протоколу Kerberos положено знание обеими сторонами общего секрета до начала обмена. Этим секретом является пароль, а точнее, взятая от него функция.
Предположим, Аня и Ваня общаются через сеть и хотят удостовериться в подлинности друг друга. Если передать сам пароль или функцию от него, то секрет будет скомпрометирован в большей или меньшей степени. Кроме того, передаваемая информация должна зависеть от времени, чтобы избежать повторения злоумышленником сеанса передачи одной из сторон.
Поэтому вместо передачи самого пароля Аня передает некоторую информацию и метку времени, например, ╚Привет, это Аня, сейчас 12:25╩, зашифровав ее общим ключом. Ваня, получив зашифрованное сообщение, извлекает из него метку времени и вкладывает в свое сообщение: ╚Привет, это Ваня, твое время 12:25╩ и шифрует общим ключом. Аня, получив ответ Вани, извлекает из него свою метку времени. Раз Ваня смог извлечь ее метку времени, значит, он действительно знает пароль, и этот пароль совпадает с паролем Ани. Таким образом, производится взаимная аутентификация.
Так что же дает применение Kerberos в сети? В первую очередь, аутентификацию пользователей и серверов, причем нагрузка на доменный контроллер или центр дистрибуции ключей (KDC) существенно снижается за счет применения удостоверений (tickets), которые выдаются на право получения доступа к конкретному серверу на определенное время и на право получения таких удостоверений. Таким образом, для аутентификации пользователя не требуется каждый раз обращаться к доменному контроллеру.
Но такая аутентификация пользователя должна использоваться при работе всех приложений, а не только при файловом доступе и регистрации пользователя в системе, как сделано на данный момент в Windows 2000. Говоря специальным языком, все приложения должны быть ╚керберизованы╩. На сегодняшний день в Windows 2000 не ╚керберизованы╩ даже telnet и ftp.
При реализации протокола Kerberos в Windows 2000 были сделаны его нестандартные расширения для передачи дескриптора безопасности, отражающем информацию о членстве пользователя в группах: Privilege Attribute Certificate (PAC). Это расширение не нарушает совместимости с имеющимися реализациями, но способ его описания затрудняет построение новых реализаций, совместимых с Active Directory: документ, описывающий это расширение, доступен на сайте www.microsoft.com в формате саморазворачивающегося EXE-архива, который перед распаковкой требует принять лицензионное соглашение о неразглашении и нереализации данного расширения, т.═к. данное расширение является ╚коммерческой тайной╩.
Таким образом, какие дополнения внесены в протокол Kerberos при его реализации в Windows 2000, становится известно при ознакомлении с документом, но перед ознакомлением требуется принять обязательство их не реализовывать. Подобные прецеденты в истории уже были, так, например, фирма IBM публиковала спецификацию BIOS в IBM PC с подобной лицензией. Обходной путь был найден инженерами фирмы Compaq, которые провели обратное конструирование BIOS, не читая спецификации. При этом весь процесс работы инженеров тщательно документировался и снимался на видеопленку.
При использовании открытых стандартов разработчики фирмы Microsoft уделили немало внимания вопросам совместимости с эталонной реализацией MIT Kerberos: возможно использовать Windows 2000 в качестве стандартного KDC для клиентов MIT Kerberos и, наоборот, проводить аутентификацию пользователей из Windows 2000 через стандартный KDC. Также возможно устанавливать доверительные отношения между реалмом (термин, эквивалентный домену) Kerberos и доменом Active Directory, что позволяет использовать делегирование аутентификации между ними.
В условиях учебного центра ╚Эврика╩ были успешно смоделированы несколько сценариев взаимодействия между Windows 2000 Active Directory и реализацией MIT Kerberos в RedHat Linux 7.0. Самой интересной с практической точки зрения оказалась реализация аутентификации пользователей Linux в домен Windows 2000, когда пароль пользователя хранится только в одном месте ≈ в Active Directory. Такой подход позволяет организовать наличие одной учетной записи у пользователя и однократный ввод пароля стандартными средствами систем.
Анкета || Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (с 27.08.2021) - (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
Пейджер 238-6931(аб.3365)
e-mail:
Для пресс-релизов и новостей