В течение последних восьми лет я помогал планировать, внедрять и эксплуатировать различные инфраструктуры Active Directory (AD). При всех преимуществах AD эта служба имеет ряд досадных недостатков, которые порой мешают нормальной работе. В данной статье я хочу рассмотреть некоторые из этих недостатков и предложить оптимальные пути их обхода.
Трудности с оборудованием
В общем, все домены AD весьма устойчивы к аппаратным неполадкам, которые приводят к отказу одного контроллера домена (DC). Конечно, это утверждение верно, только если в каждом домене развернуто более одного DC и выполняется постоянный мониторинг репликации изменений между контроллерами доменов. Таким образом, если один DC по какой-то причине выходит из строя, клиенты, проходящие проверку подлинности в домене, найдут в сети другой DC через DNS. При нормальной работе проблем не возникает, даже если контроллеры домена с какой-либо специализированной ролью Flexible Single-Master Operation (FSMO) выходят из строя на несколько часов или даже дней. Для нормальной работы AD не требуется, чтобы все контроллеры домена FSMO были доступны в любое время. Очевидно, необязательно обновлять схему или в массовом порядке создавать новые объекты в домене при отказе конкретных контроллеров домена FSMO. Но обычные операции, такие как изменение пользователями паролей или добавление администратором нового объекта в домен, будут выполняться по-прежнему. Это одно из главных достоинств AD и модели репликации с несколькими владельцами.
Но иногда причиной проблемы является не аппаратный отказ DC. Порой неполадки начинаются лишь после ремонта оборудования и перезагрузки DC — особенно если DC является эмулятором основного контроллера домена (PDC). По умолчанию все DC в домене AD синхронизируют время с эмулятором PDC соответствующего домена. Компьютеры и серверы в домене синхронизируют время с контроллером домена, используемым ими для проверки подлинности (обычно это DC в их сайте AD). Для проверки подлинности Kerberos все клиенты и контроллеры домена должны быть синхронизированы. Клиенты и серверы Windows 2000 Server и более поздних версий в домене AD используют Kerberos по умолчанию. В случае слишком большой разницы во времени между клиентом и сервером, на котором расположен нужный ресурс, такой как общая папка, проверка подлинности на сервере ресурса завершается неудачей. По умолчанию приемлемое рассогласование по времени в лесу AD — пять минут. Поэтому, даже если пользователь или компьютер успешно проходит проверку подлинности в домене, попытка доступа к серверу может завершиться неудачей из-за разницы во времени.
Какое отношение это имеет к аппаратному отказу DC в домене, возможно, даже основного DC? Очень простое: если в процессе ремонта оборудования была заменена системная плата сервера, обычно заменяется и встроенный в нее таймер. Маловероятно, чтобы время системного таймера новой платы совпадало со временем остального леса AD. Если после этого просто перезагрузить PDC, когда он подключен к сети, то другие контроллеры домена синхронизируют время с PDC, обнаружив, что он вновь присутствует в сети. В результате может появиться рассогласование времени на различных компьютерах, недопустимое для Kerberos. Хотя PDC может быть настроен на репликацию с внешним источником времени, в сеть внесена временная ошибка, которая вызовет неполадки, например невозможность серверов Microsoft Exchange Server использовать глобальные каталоги (GC) в своих сайтах для преобразований LDAP или пользователям не удастся получить доступ к общим каталогам. Может оказаться, что положение не нормализуется в течение нескольких часов или дней и даже потребуется ручное вмешательство.
Решение здесь простое: если нужно заменить системную плату DC, особенно вышедшего из строя DC, на котором размещена роль FSMO эмулятора PDC, удалите сетевой кабель перед перезагрузкой DC. После успешной перезагрузки DC (для которой может потребоваться больше времени, чем обычно, так как DC не сможет найти другие контроллеры домена для репликации), необходимо зарегистрироваться локально и установить время на DC. Затем можно вновь подключить сетевой кабель. Другой вариант: если PDC отвечает, можно временно перенести роль PDC на другой контроллер домена и выполнить обратный перенос после замены системной платы. Эти методы предотвращают проблемы временной синхронизации, которые в свою очередь нарушают процесс проверки подлинности в сети.
Проверка подлинности между лесами
Большинство администраторов AD смутно представляют, как клиенты используют DNS для обнаружения контроллеров домена в собственном лесу или домена в своей сети. Поэтому, прежде чем рассмотреть процесс между различными лесами AD и сетями, познакомимся с процедурой обнаружения DC внутри домена AD.
Клиент Windows 2000 или более поздней версии, который никогда ранее не проходил проверку подлинности в домене AD, направляет запрос DNS, чтобы получить сведения о любом DC, ответственном за собственный домен. При этом клиент запрашивает с сервера DNS список всех контроллеров домена, которые зарегистрировали типовую запись локатора DC (которая по умолчанию включает все контроллеры домена в домене AD). Чтобы извлечь эти записи, клиент сначала запрашивает типовые записи службы LDAP в зоне _msdcs иерархии DNS. Для домена AD с именем MyCompany.net типовые записи находятся в следующей иерархии DNS: _ldap._tcp.dc._msdcs.MyCompany.net.
Затем клиент устанавливает контакт с несколькими контроллерами домена из списка, полученного с сервера DNS, оповещает их о необходимости пройти проверку подлинности и ожидает ответа от первого DC. Но контроллеры домена достаточно интеллектуальны, чтобы оценить ситуацию, и поэтому проверяют IP-адрес, указанный клиентом в запросе. Они обнаруживают, что клиент присоединен к домену и сравнивают IP-адрес клиента с данными сайта и подсети, сохраненными в разделе конфигурации AD. С помощью этих данных контроллеры домена определяют сайт клиента и сообщают клиенту о необходимости подключиться к серверу DNS и сделать запрос о DC для проверки подлинности в собственном сайте. Затем клиент запрашивает нужную запись службы Kerberos.
Предположим, что клиент находится в офисе филиала домена AD MyCompany.net и имя сайта AD — BranchSite. Клиент запрашивает DNS о записях службы Kerberos, зарегистрированных для данного сайта. Эти записи находятся в следующей иерархии DNS: _kerberos._tcp .BranchSite._sites.dc._msdcs.MyCompany.net. На экране 1 также показана иерархия в оснастке DNS консоли управления Microsoft Management Console (MMC).
Затем сервер DNS возвращает сведения только о контроллерах домена, ответственных за сайт клиента, а клиент, в свою очередь, обращается к ним для проверки подлинности в домене. К счастью, клиент хранит в реестре информацию о последнем сайте AD, к которому он принадлежал, и сразу использует эту информацию в следующий раз при необходимости обнаружить DC. Имя сайта AD, записанное клиентом, находится в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNetlogonParameters DynamicSiteName.
Даже после того, как пользователь пройдет проверку в собственном домене, требуется сделать несколько дополнительных шагов, чтобы обеспечить доступ к ресурсам через границы доменов в лесу со многими доменами. Часто процесс обнаружения DC повторяется при обращении пользователя к ресурсам в другом домене леса. Хотя все домены в лесу доверяют друг другу, билет Kerberos на право получения билетов Ticket Granting Ticket (TGT), извлеченный клиентом из собственного DC при регистрации, действителен только для запроса билета службы, который, в свою очередь, предоставляет доступ к ресурсам в собственном домене клиента. Когда пользователь обращается к ресурсу в другом домене того же леса (например, к серверу файлов), клиент вновь сначала запрашивает DNS, чтобы найти DC домена файл-сервера и запросить билет TGT, действительный в этом домене. Удобно, что клиент немедленно находит нужный DC. Поскольку клиенту известно, в каком сайте он находится, он использует запрос DNS для конкретного сайта (аналогичный описанному выше) для поиска DC другого домена.
Одна из причин высокой эффективности этого процесса в лесу без обращений к типовым записям локатора DC другого домена заключается в том, что все домены одного леса реплицируют и используют один раздел конфигурации AD. В этом разделе также содержится информация о сайте и подсети, поэтому контроллеры из любых доменов леса правильно регистрируют записи локатора для соответствующих сайтов AD. Если сайт AD не располагает контроллером домена или не имеет DC для каждого домена леса, то механизм AutoSiteCoverage гарантирует, что ближайший DC зарегистрирует запись локатора в DNS. То есть в пределах своего леса клиент всегда может найти DC для конкретного сайта в любом домене лесе. Клиенту не приходится использовать типовые записи локатора DC, которые могут направить клиента для проверки подлинности на контроллер домена в другом полушарии. Но следует помнить, что процесс подразумевает доступность DC конкретного сайта; в противном случае клиент использует типовые записи локатора DC, что может привести к замедлению проверки подлинности и обработки объектов групповой политики (GPO).
Предположим, что одна компания приобрела другую, с собственным лесом AD. Для эффективной организации совместной работы сотрудников двух компаний решено установить доверительные отношения между обоими лесами. Возможно, в будущем планируется консолидировать оба леса; но часто доверительные отношения между лесами — первый шаг к доступу к ресурсам в различных лесах обоих частей объединенной компании.
Досадный недостаток проверки подлинности между лесами заключается в том, что клиенту часто не удается обнаружить нужный DC в доверенном лесе, и вместо этого происходит проверка подлинности на случайном DC, нередко отличном от предпочтительного. К счастью, эту проблему легко устранить.
Аналогично описанному процессу обнаружения DC между доменами, при обращении к ресурсу в доверенном лесе клиент запрашивает серверы DNS доверенного леса о подходящих контроллерах домена для проверки подлинности. Важно уяснить, что клиент вновь запрашивает в DNS записи службы Kerberos для конкретного сайта. Для этого клиент объединяет имя сайта из собственного домена MyCompany.net с именем домена доверенного леса OtherCompany.net и таким образом запрашивает следующую иерархию DNS: _kerberos._tcp.BranchSite._sites.dc._ msdcs.OtherCompany.net. Если такого сайта AD не существует в доверенном лесе (весьма вероятно для леса, спроектированного другой группой разработчиков), то запрос DNS заканчивается неудачей и клиент должен запросить типовые записи локатора DC. Затем подлинность клиента может быть проверена контроллерами домена доверенного леса. Этот способ явно не идеален и замедляет доступ к данным и приложениям между лесами.
Чтобы предотвратить эту проблему, достаточно создать в обоих лесах сайты AD с одинаковыми именами. Эти новые сайты можно рассматривать как «теневые» сайты доверенного леса. Нет необходимости добавлять к этим сайтам новые IP-подсети, и «теневые» сайты могут не содержать настоящих контроллеров домена. Создайте выделенное соединение сайта между каждым «теневым сайтом для MyCompany» и ближайшим «настоящим сайтом OtherCompany». Убедитесь, что к этому соединению сайта не присоединено никаких других сайтов, а сами теневые сайты не присоединены ни к каким другим связям сайтов. Такой подход гарантирует, что нужный DC леса OtherCompany.net добавит необходимые записи типа SRV к соответствующему теневому сайту через AutoSiteCoverage. Теневые сайты обеспечивают использование клиентами верных и ближайших контроллеров домена для проверки подлинности при обращении к ресурсам в доверенном лесу.
Удобная модель с наименьшими привилегиями
По мере того как компании предъявляют более строгие требования к информационной безопасности, администраторы AD начали использовать по крайней мере две учетные записи с различными правами: одну для регистрации на клиентских системах и выполнения повседневных задач (у этой учетной записи нет никаких административных прав в AD) и другую — с достаточными правами в AD для таких административных задач, как управление пользователями и группами. Работать с несколькими учетными записями неудобно даже при обращении к различным функциям операционной системы, например щелкая правой кнопкой мыши на оснастке Directory Users and Computers консоли MMC и выбирая Run для запуска команды из административной учетной записи. Хотя этот метод приемлем, досадно, что диалоговое окно Run, используемое для ввода административных учетных данных, никогда не помнит моей учетной записи для AD. Приходится вводить ее каждый раз, когда нужно расширить свои права.
Хорошее решение проблемы — развернуть централизованный сервер терминалов, на котором установлены все необходимые административные инструменты. Администраторы AD могут подключиться к серверу терминалов, пройти проверку подлинности с административной учетной записью и выполнить необходимые административные задачи в сеансе сервера терминалов. Нет необходимости использовать Run as, и можно даже разместить на настольном компьютере файлы RDP с нужным именем учетной записи. Конечно, не следует хранить пароль административной учетной записи в RDP-файлах. С помощью центрального сервера терминалов администраторы могут подключаться и выполнять свои обязанности с любого клиента — пакет инструментов Windows Server Administration Tools Pack (adminpak.msi) не обязательно устанавливать локально на клиенте. Однако инфраструктура многих предприятий слишком мала, чтобы устанавливать сервер терминалов исключительно для административных целей; могут существовать и другие причины для запуска инструментов управления AD с локального компьютера.
Другая возможность избежать монотонного щелканья правой кнопкой мыши на значках и ввода учетных данных — создать собственный ярлык для прямого запуска утилиты Runas, что позволит полностью задействовать параметры как командной строки, так и оснасток. Если учетные записи администратора отличаются от обычной учетной записи пользователя явным префиксом, то процесс управления ярлыками для нескольких пользователей можно упростить с помощью таких простых приемов, как расширение переменных среды USERNAME.
Например, мою обычную учетную запись пользователя (непривилегированную) можно назвать GUIDOG, а административную учетную запись — ADM.GUIDOG. Чтобы несколько администраторов могли использовать один ярлык на разных компьютерах, необходимо развернуть различные переменные среды в созданном ярлыке, для чего следует поместить соответствующую переменную среды между двумя символами процентов. Ниже приведен образец команды для ярлыка, который используется для запуска оснастки Active Directory Users and Computers с административной учетной записью, и запроса, привязанного к конкретному DC в моем домене:
%windir%system32 unas /env /
user:%userdomain%adm.%username%
«mmc %windir%system32dsa.msc /
server=w2k8core01»
При создании ярлыка для этой команды можно создать предупреждение и напомнить самому себе, что выполняется переход на учетную запись с расширенными правами, применяя для этой цели цветные обозначения в самом ярлыке; в командной строке можно настроить цвета фона и шрифта ярлыка. На экране 2 показано окно, которое выводится при двойном щелчке на ярлыке пользователя GUIDOG. Красный цвет фона командной строки предупреждает, что готовится расширение прав. Поскольку команда Run as в ярлыке соответственно расширена %userdomain% ADM.%username%, мне более не приходится вводить имя учетной записи. Вместо этого появляется приглашение для ввода пароля учетной записи CORPADM.GUIDOG.
Ярлыки Windows являются настоящими файлами (с расширением .lnk), поэтому их можно скопировать в соответствующий общий раздел, доступный любому администратору леса AD. И если другой пользователь, например JOER, также имеет административную учетную запись с тем же соглашением об именовании, он может использовать такой же ярлык для запуска оснастки Active Directory Users and Computers и пройдет проверку подлинности как CORPADM.JOER.
64-разрядные версии Windows
В настоящее время наблюдается мощная тенденция перехода к 64-разрядным версиям Windows, особенно для приложений, которые выигрывают от расширенного пространства памяти 64-разрядной операционной системы. AD — одно из таких приложений. Если база данных AD не умещается в рамках, налагаемых на память 32-разрядными версиями Windows Server (см. таблицу), то перевод контроллеров домена в 64-разрядную среду Windows на оборудовании с достаточной физической памятью существенно увеличивает производительность AD, а также производительность зависимых от AD прикладных программ (например, Exchange).
В данной статье не обсуждается подробно, при каких условиях выгодно применять 64-разрядную версию Windows на контроллерах домена. Как правило, при объединении 32- и 64-разрядных DC в лесу AD (например, Windows Server 2003 x64) проблем не возникает. Для 64-разрядной среды не требуется специальных расширений схемы, а репликация между 32- и 64-разрядными контроллерами домена проходит успешно. Конечно, необходимы подходящие версии драйверов, антивирусные программы и агенты мониторинга, совместимые с 64-разрядной Windows. Правда, могут перестать функционировать некоторые инструменты управления Microsoft для AD. Самые важные из них — инструмент AD Replication Monitor (Replmon), консоль управления групповой политикой Group Policy Management Console (GPMC) и сервер экспорта паролей Password Export Server (PES) инструмента миграции Active Directory Migration Tool (ADMT). Большинство 32-разрядных приложений работает без проблем с 64-разрядной операционной системой Windows благодаря 64-разрядному режиму совместимости Windows-on-Windows (WoW64). Replmon, GPMC и ADMT PES — исключения из этого правила, так как у них есть другие зависимости, которые нельзя обеспечить с помощью WoW64. Replmon и GPMC безупречно функционируют на 32-разрядном сервере, члене домена и, таким образом, могут быть задействованы в 64-разрядном лесе AD и дистанционно подключаться к 64-разрядным контроллерам домена. ADMT PES необходимо установить на DC, поэтому нужно выделить 32-разрядный DC для этой службы или дождаться следующей версии ADMT, выпустить которую планируется вместе с Windows Server 2008. В ее состав войдет 64-разрядная служба PES.
Предупрежден —значит вооружен
AD — мощная служба каталогов и проверки подлинности. Ее модель репликации с несколькими владельцами обеспечивает высокую готовность. Но иногда некоторые особенности ее функционирования не соответствуют ожиданиям потребителей, и этот изъян доставляет больше всего хлопот администраторам. Заранее зная об этих недостатках, можно предотвратить их влияние на инфраструктуру компании.
Гвидо Грилленмейер (guido.grillenmeier@hp.com ) — главный специалист по технологиям в подразделении Advanced Technology Group компании Hewlett-Packard. MVP по Microsoft Directory Services и Microsoft Certified Architect
SC пможет восстановить сервер
Как компьютерному консультанту мне часто приходится встречаться с системными администраторами, попавшими в затруднительное положение из-за невозможности работать через графический интерфейс. Благодаря множеству хороших инструментов командной строки и обширной информации о них в таких изданиях, как Windows IT Pro, в распоряжении администраторов есть богатый набор методов для устранения неполадок
Рассмотрим, например, историю администратора по имени Фрэнк. Он решал задачи управления в основном с помощью административного инструментария Windows с графическим интерфейсом. Но однажды из-за отсутствия доступа к важнейшему серверу в центре обработки данных компании ему пришлось искать альтернативный инструмент командной строки. Далее произошло следующее.
Потеря RPC-сервера
Во вторник было запланировано применение программных исправлений на серверах в центре обработки данных. Исправления удобнее применять через дистанционное соединение, поэтому примерно в 21.00 Фрэнк зарегистрировался в системе и применил исправления ко всем серверам, в том числе к контроллеру домена (DC) с ролью Global Catalog (GC).
После перезагрузки все серверы ответили на команду ping. Но при попытке посмотреть электронную почту Microsoft Office Outlook не смог найти сервер Exchange. Администратор попытался зарегистрироваться на DC, но получил сообщение о недоступности RPC-сервера: The system cannot log you on due to the following error: The RPC server is unavailable. Все средства графического интерфейса оказались неэффективными: получить доступ к роли GC не удавалось. Без этой роли на контроллере домена Active Directory функционирование Exchange невозможно.
Фрэнк пытался выяснить, что произошло с сервером, и вспомнил об оснастке консоли Microsoft Management Console (MMC), с помощью которой можно читать журналы другого сервера. Поэтому он зарегистрировался на сервере, члене домена, и попытался запустить оснастку, но так и не смог обратиться к DC. Фрэнк оказался на «острове» без возможности добраться до «материка» DC и не мог получить никакой информации из компьютера, чтобы решить проблему.
Пытаясь найти выход из положения, он ходил из угла в угол по комнате и споткнулся о сумку из-под ноутбука, словно выброшенную из океана на песок. Заглянув внутрь, он нашел номер Windows IT Pro. В растерянности он стал листать журнал.
Спасительный инструмент SC
Случайно ему попалась на глаза статья об инструменте командной строки, SC (sc.exe), который можно использовать для управления службами на локальном или удаленном компьютере. Это была статья «Универсальный диспетчер служб Service Controller» (Windows IT Pro/RE, март 2007 г.). Читая статью, Фрэнк понял, что этот инструмент и поможет ему выйти из затруднения.
Он вновь зарегистрировался на сервере, члене домена, и ввел команду SC в командном окне, чтобы определить синтаксис, который имел вид:
sc
[command] [service name] …
Вскоре Фрэнк понял, что это не специализированная утилита, а универсальный инструмент, с помощью которого удастся вернуться в графический интерфейс и восстановить службу электронной почты. Он знал, что сервер не отвечает на имя компьютера, но отвечает на запрос ping. Поэтому он ввел команду
sc 192.168.10.10 query
В тот же момент на экране стала прокручиваться информация обо всех службах сервера. Было необходимо сузить запрос до единственной службы. Судя по сообщению об ошибке соединения, служба удаленного вызова процедур RPC недоступна, поэтому Фрэнк ввел следующую команду, чтобы узнать о случившемся с RPC:
sc 192.168.10.10 query RPC
Команда вернула сообщение об ошибке: [SC] EnumQueryServices Status:OpenService FAILED 1060: The specified service does not exist as an installed service.
Из этого сообщения об ошибке Фрэнк сделал вывод, что команда SC не распознала отображаемое имя службы RPC (то есть RPC), поэтому он повторил команду со служебным именем RPC, rpcss. На этот раз результаты команды показали, что служба RPC функционирует, хотя ошибка при входе указывала, что служба недоступна. Фрэнк был в недоумении. Продолжая изучать результаты запроса, он заметил параметр State. Значение State, равное 4, свидетельствует о том, что служба функционирует.
Определение причин
Фрэнк запустил команду запроса вновь, не указывая службу, и выяснил состояние всех функционирующих служб. В конце концов он заметил, что служба Netlogon приостановлена. Вероятно, это была единственная причина, препятствующая доступу к серверу.
У него не было доступа к services.msc, чтобы запустить или остановить службу Netlogon, но был инструмент SC. Поэтому Фрэнк остановил службу Netlogon с помощью команды
sc 192.168.10.10 stop netlogon
Затем он направил запрос, чтобы посмотреть результат выполнения предыдущей команды:
sc 192.168.10.10 query netlogon
Теперь значение State для Netlogon было 2, то есть служба не работала. Затем он запустил Netlogon с помощью команды
sc 192.168.10.10 start netlogon
Чтобы узнать результаты этой команды, он вновь направил запрос к Netlogon и увидел, что служба функционирует! Затем Фрэнк запустил службу на всех компьютерах сети с помощью инструмента командной строки SC.
Теперь он мог зарегистрироваться на DC; все службы сервера GC были активны и электронная почта работала. Фрэнку удалось выбраться с «острова Командной строки» и подняться на борт корабля «Графический интерфейс». Вывод: иметь под рукой правильно подобранный инструментарий — все равно что плавать в море со спасательным жилетом. Он может не потребоваться, но очень пригодится, если налетит шторм.
Курт Спанбург (cspanburgh@scg.net ) — консультант, работает в компании Solutions Consulting Group, имеет звание MVP по Microsoft Dynamics CRM