Active Directory без проблем | Windows IT Pro / RE | Видавництво «Відкриті системи»

Active Directory без проблем Протягом останніх восьми років я допомагав планувати, впроваджувати...
Active Directory без проблем
Active Directory без проблем
Active Directory без проблем
Active Directory без проблем
Active Directory без проблем
Active Directory без проблем
Active Directory без проблем

Active Directory без проблем
Протягом останніх восьми років я допомагав планувати, впроваджувати та експлуатувати різні інфраструктури 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 - потужна служба каталогів і перевірки автентичності. Її модель реплікації з декількома власниками забезпечує високу готовність. Але іноді деякі особливості її функціонування не відповідають очікуванням споживачів, і цей недолік найбільше клопоту адміністраторам. Заздалегідь знаючи про ці недоліки, можна запобігти їх вплив на інфраструктуру компанії.
Гвідо Грілленмейер ( [email protected] ) - головний спеціаліст з технологій в підрозділі 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 can not 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] <option1> <option2> ... <\ / option2> <\ / option1>
Незабаром Френк зрозумів, що це не спеціалізована утиліта, а універсальний інструмент, за допомогою якого вдасться повернутися в графічний інтерфейс і відновити службу електронної пошти. Він знав, що сервер не відповідає на ім'я комп'ютера, але відповідає на запит 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 були активні і електронна пошта працювала. Френку вдалося вибратися з «острова Командного рядка» і піднятися на борт корабля «Графічний інтерфейс». Висновок: мати під рукою правильно підібраний інструментарій - все одно що плавати в морі з рятувальним жилетом. Він може не знадобитися, але дуже стане в нагоді, якщо налетить шторм.
Курт Спанбург ( [email protected] ) - консультант, працює в компанії Solutions Consulting Group, має звання MVP по Microsoft Dynamics CRM

Active Directory без проблем

Протягом останніх восьми років я допомагав планувати, впроваджувати та експлуатувати різні інфраструктури 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).