КОМПЬЮТЕР-ИНФОРМ Главная страница || Статьи 9'2001 || Новости СПб || Новости России || Новости мира
Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Аутентификация в Active Directory
Виктор Ашик, инструктор учебного центра Эврика V_ashik@eureca.ru
В данной статье рассматриваются протоколы аутентификации, которые используются в операционной системе 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 апреля 2001 г.
Перепечатка материалов
без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 718-6666, 718-6555.
Адрес: 196084, СПб, ул.Заставская, д.23, БЦ "Авиатор", 3-й этаж, офис 307
e-mail: editor@ci.ru
Для пресс-релизов и новостей news@ci.ru