Служба каталогов Active Directory и использование групповых политик

Служба каталогов

Общие сведения о службе каталогов На заре компьютеризации все управление пользователями сводилось к администрированию одного единственного сервера. Со временем ситуация стала меняться, во-первых, предприятия приобретали все большее количество серверов, во-вторых, вопросам безопасности стало уделяться все больше внимания, что потребовало большего контроля каждого действия пользователя (как следствие, введения строгой аутентификации для каждого значимого для системы действия). Со временем это привело к тому, что администратор был вынужден создавать учетную запись пользователя на каждом сервере в сети предприятия, а также на каждой рабочей станции, которой имеет право пользоваться сотрудник. Пользователь, в свою очередь, должен был постоянно предоставлять аутентифицирующую информацию (каждому сервису корпоративной сети). Решением этой проблемы стало создание так называемых служб каталогов — систем централизованного хранения информации о пользователях. Международная организация по стандартизации (ISO) предложила стандарт X.500, который описывал функционирование такой системы. Однако протокол взаимодействия, описанный в рамках стандарта, оказался слишком перегруженным для сетей TCP/IP. По этой причине какое-то время службы каталога создавались производителями с использованием различных протоколов взаимодействия (NDS, NIS, NT4 domain). Такое разнообразие реализаций привело к тому, что независимые разработчики сетевых сервисов либо совсем не обеспечивали совместимости со службами каталогов, либо обеспечивали совместимость с какой-то конкретной реализацией. Как следствие, каждый производитель службы каталога должен был обеспечить клиентов и базовым набором служб (например, собственным файл-сервером). Ситуация изменилась только тогда, когда Интернет-сообщество опубликовало «облегченный» вариант стандарта X.500 — протокол LDAP (Lightweight Directory Access Protocol, RFC 4510). Протокол обеспечивал простой доступ к каталогу в рамках TCP-соединения, касался также вопросов аутентификации и собственно структуры каталога. Позже стандарт претерпел некоторое количество редакций и в настоящее время поддерживается практически любым сетевым приложением и реализован в любой службе каталога. Развитие протокола продолжается и сегодня. Уже используется версия 3 данного протокола, а также опубликован целый ряд расширений (например, поддержка language tags, позволяющая хранить имя пользователя, записанное на нескольких языках, и отправлять клиенту имя на его родном языке). Многие современные сетевые приложения также обладают встроенной поддержкой LDAP (почтовые клиенты способны производить поиск адреса по имени пользователя, web-серверы и СУБД могут извлекать список пользователей из каталога LDAP, распределенные приложения могут хранить свои настройки в каталоге LDAP и т. п.) После того как все данные о пользователях, группах, в которые они входят, и их правах доступа переместились в централизованное хранилище, разработчики стали задумываться и о решении другой проблемы современных компьютерных систем — о постоянной необходимости пользователей в аутентификации. Производители стали выпускать системы с концепцией единого входа в сеть (так называемые системы SSO — single sign on), т. е. пользователь при однократном вводе пароля получал доступ ко всем ресурсам сети. На практике это работало только с сервисами самого производителя, поскольку слишком различались протоколы сетевой аутентификации у различных приложений. Те способы решения проблемы, которые пытались предложить конкретные производители, не были универсальны. Решения от Microsoft позволяли хранить пароль пользователя не в виде хэша, а в восстанавливаемом виде (т. е. практически в открытом), Novell позволял хранить пароль различными способами (зашифрованный хэшем пароля секретный ключ для сервисов Novell, NTLM-хэш для доступа к сервисам Microsoft). Такие решения позволяли пользователю не вводить свой пароль лишний раз, но не были ни безопасными, ни универсальными. Ситуация вновь изменилась благодаря открытым стандартам. С небольшим промежутком времени появились описания методов, позволяющих разделить сам сетевой сервис и процесс аутентификации пользователя, что позволяло использовать любой сетевой сервис с нужным методом аутентификации. Однако использование универсальных механизмов лишь частично решает проблему единой аутентификации при входе в сеть. Необходим также некоторый безопасный протокол, который аутентифицирует клиента перед сервером (сервисом), с учетом того, что сам сервер ничего о пользователе не знает и должен использовать в качестве посредника сервер службы каталогов. В качестве универсального протокола аутентификации можно использовать инфраструктуру открытых ключей (например, на базе сертификатов X.509) или протокол Kerberos. Служба Active Directory состоит из целого набора сервисов, связанных между собой. Основой Active Directory является система разрешения имен, при помощи которой рабочие станции способны прозрачно обнаруживать серверы домена, например LDAP-серверы. В существующей реализации сервиса каталога в качестве службы разрешения имен выбрана система DNS (в отличие от предыдущих версий, которые использовали систему имен NetBIOS). Для хранения каталога LDAP, а также для обеспечения аутентификации по протоколу Kerberos в сети Microsoft выделяются специальные сервера, которые называются контроллерами домена. В целом контроллер домена — это выделенный сервер, предназначенный для обеспечения сервисов LDAP и KDC (Key Distribution Center).