Типові завдання адміністрування мережі Windows 2000 h2>
Як
відомо, в Active Directory реалізована реплікація в режимі multi-master. У той
Водночас деякі операції вигідніше проводити в режимі з одним головним
сервером, тобто в режимі single-master (з виділеним основним контролером
операцій). Цей контролер відповідає за виконання конкретних функцій,
званих ролями контролера операцій. Оскільки ці ролі не мають жорсткої прив'язки
до конкретного сервера в рамках домену або лісу, їх називають переміщуваними
(FSMO, Flexible Single Master Operations). Таких ролей в мережі Windows 2000
п'ять, і розподіляються вони за двома різними групами. p>
Ролі, унікальні в рамках лісу h2>
Schema
Master p>
Роль,
відповідальна за управління змінами і модифікаціями схеми. У рамках лісу
існує єдиний сервер, який зберігає доступну для запису копію схеми.
Відповідно, для внесення до неї змін необхідно зв'язатися з цим
контролером домену. p>
Domain
Naming Master p>
Роль,
управляє всіма доменними іменами в рамках лісу і відслідковує додавання і
видалення доменів. У разі його недосяжності створення нового домену в рамках
лісу стає неможливим. p>
Ролі, унікальні в
рамках домену p>
PDC (Primary Domain controller)
Emulator p>
Найбільш
часто використовується у роботі контролер. Відповідає за роботу з обліковими записами
користувачів, групові політики та оновлення інформаційних баз резервних
контролерів домену. Крім того, за наявності в мережі резервних контролерів
домену NT 4.0 грає роль головного контролера домену. При цьому у випадку, якщо
призначений для користувача пароль відкинутий резервним контроллером, то перед тим, як
відкинути запити на доступ до ресурсу, цей запит буде переданий PDC
Emulator'у, і тільки після підтвердження відмови користувач побачить стандартне
повідомлення про невірність пароля. p>
Infrastructure
Master p>
Цей
контролер відповідає за всі междоменние відносини, зокрема управляє
членством в междоменних групах. Наприклад, у разі зміни імені члена
групи або його видалення з групи цей контролер оновлює всі посилання з
групи на цього користувача. При цьому всі зміни вносяться в режимі
multi-master, що змушує розносити на різні фізичні сервери роль
Infrastructure Master і сервер глобального каталогу. p>
Relative
ID (RID) Master p>
Цей
контролер надає новим користувачам і групам користувачів
відносні ідентифікатори (RID). Даний ідентифікатор необхідний для
формування унікального ідентифікатора безпеки (SID) для кожного нового
об'єкта типу «користувач», «група користувачів» або «комп'ютер». p>
Управління носіями ролей FSMO h2>
Як
ми бачимо, у порівнянні з доменом NT 4.0 кількість службових контролерів
зросло. Якщо запорукою стабільної роботи домену NT 4.0 була наявність головного
контролера домену (PDC) і сервера динамічного розподілу IP-адрес
(DHCP), то кількість потенційних вузьких місць мережі Windows 2000 представляється
помітно зросте. Відповідно збільшилося і кількість утиліт адміністрування,
використовуються в повсякденній роботі, досконале знання яких є
запорукою стійкої роботи мережі. Крім успадкованих і звичних утиліт Server
manager і User Manager зі складу NT 4.0, для адміністрування мережі Windows
2000 застосовуються додатково ще шість програмних засобів, розгляду
які ми й присвятимо цей розділ. p>
Монітор реплікації (Replication monitor) h2>
Ця
утиліта, що входить до складу Windows 2000 Support Tools, дозволяє переглянути
поточний розподіл ролей FSMO і перевірити доступність відповідного
контролера. Її функції носять інформаційно-допоміжний характер, оскільки
з її допомогою неможливо передати роль іншого контролера домену. Найважливішою
і корисною функцією цієї утиліти є можливість визначення доступності
носіїв ролі. p>
Утиліта командного рядка NetDom.exe h2>
Ця
утиліта командного рядка також входить до складу Windows 2000 Support Tools. При
всій своїй невитіюватість і убогому інтерфейсі (хоча яким ще може бути
інтерфейс у MS-DOS-додатків?) ця програма є потужним інструментом
адміністрування, особливо у випадку, коли використання нових графічних
адміністративних утиліт ще не стало автоматичним. Найбільш важливими є
можливості перегляду носіїв ролей, перенесення робочих станцій і серверів
між доменами і управління довірчими відносинами між доменами. Ця
програма варта того, щоб її використовувати. p>
Утиліта командного рядка NTDSUtil.exe h2>
Цю
утиліту можна сміливо назвати NetDom extended, оскільки крім функцій утиліти
NetDom.exe вона містить функції перерозподілу носіїв ролей FSMO. Ця
програма дуже ефективна, але гідно оцінити її зможуть тільки ті, для
кого командні рядка MS-DOS і UNIX shell до цих пір є улюбленими
інструментами адміністрування мережі. Найбільшою перевагою цієї утиліти
є те, що вона дозволяє переносити всі п'ять ролей. Це дуже важливо,
оскільки завдання зміни носіїв ролей FSMO, виконана розглянутими
нижче GUI-додатками, вимагає застосування двох утиліт. p>
Оснащення b> Active directory Users and
Computers b> p>
Ця
оснащення є подальшим розвитком ідей, закладених у утиліти User
Manager і Server Manager зі складу NT 4.0. Вона дозволяє повністю керувати
доменом як на рівні користувачів і груп, так і на рівні розподілу
ролей у рамках домену. Її використання дозволяє переміщати ролі PDC Emultor,
Rid Master і Infrastructure Master з граничною простотою. P>
Оснащення b> Active Directory Domains and
Trusts b> p>
Використання
цієї оснащення дає можливість переміщати роль Domain Naming Master.
Ідеологічно можна було б очікувати від даної оснащення та управління роллю
Schema Master, однак ця функція надійно захована в надрах Windows 2000
Support Tools. Бажаючі поекспериментувати з настройками Schema Master повинні
в ручному режимі додати snap-in управління схемою до консолі адміністрування.
Перш ніж почати діяти, візьміть до уваги, що всі зміни схеми
незворотні! p>
Ролі FSMO і стабільність мережі Windows 2000 h2>
Тепер
поговоримо про проблему стійкості нашої мережі і про те значення, яке кожна
з ролей має для стабільності мережі в цілому. По роботі з мережею NT 4.0 ми
пам'ятаємо, що вихід з ладу DHCP-, WINS-і DNS-серверів приводив до серйозних
проблем при роботі з мережею. Однак за роки управління мережами NT 4.0 системні
фахівці набули досвід, що дозволяє в мінімальні терміни відновити
працездатність мережі. Все нижческазане пропонується як інформація до
роздумів на тему визначення уразливих місць мережі Windows 2000. p>
Унікальні ролі лісу. h2>
Як
ми вже говорили, в рамках ліси існують дві унікальні ролі: Schema Master і
Domain Naming Master. Як правило, носієм цих двох ролей є одна
фізичний сервер. Крім того, оскільки ці ролі досить статичні і будь-яке
зміна в них має виходити від провідного системного фахівця,
представляється розумним розмістити їх поблизу від мережевого департаменту. p>
Schema
Master p>
З
всіх ролей FSMO ця роль створює менше всього проблем у разі тимчасового
обриву зв'язку. За великим рахунком, цей сервер потрібен тільки для внесення
будь-яких змін в схему, що трапляється досить рідко. Однак для
установки ряду серверних додатків (наприклад, таких як Microsoft Exchange
2000) наявність цієї ролі в мережі обов'язково. За будь-яких модифікаціях схеми
необхідно пам'ятати, що будь-яке її зміна є незворотнім. Тому, якщо ви не
впевнені в правильності дій, передайте роль майстра схеми на контролер
домену та ізолюйте його від іншої мережі. Тоді всі зміни, які ви
зробите в схемі, не поширяться відразу по лісу, а у вас буде можливість
відновити status-quo. p>
Domain
Naming Master p>
Це
єдина роль рівня лісу, що має права на зміну об'єктів домену. Її
участь є необхідним не тільки при створенні і видалення домену в лісі,
але й при операціях з перехресними посиланнями на зовнішні каталоги. У межах
лісу лише один сервер може бути носієм даної ролі. Найчастіше причиною
неможливості скористатися утилітою DCPromo є недоступність сервера
DNM. Носії ролей Domain Naming Master і Schema Master слід розміщувати на
одному контролері домену. Після закінчення етапу впровадження та доопрацювання мережі ці
ролі втратять свою споконвічно високу значимість. Проте необхідно
забезпечити гарантовано високу якість зв'язку між їх носіями і сервером
глобального каталогу. Ідеальним варіантом буде їх розміщення на одному
фізичному сервері, що висуває підвищені вимоги як до матеріальної
частини цього комп'ютера, так і до якості його сполуки. p>
Унікальні ролі домену h2>
PDC
emulator p>
Недоступність
носія цієї ролі тягне за собою максимум неприємностей як для
користувачів, так і для служби технічної підтримки. Типовими ознаками його
відмови є неможливість доступу до масиву облікових записів домену та
параметрів Group Policy. Таким чином, у разі виходу з ладу цього сервера
вся робота домену може бути паралізована. У конференціях неодноразово
висувалася пропозиція знизити роль цього сервера шляхом перекладу домену в
native-режим. Мотивується цей крок тим, що в однорідному домені потреба в
PDC emulator відпадає. При цьому не враховується, що навіть після переведення домену
в native-режим PDC Emulator як і раніше продовжує відпрацьовувати всі зміни
паролів. p>
Крім
того, не слід забувати, що ця роль здатна сильно знизити
продуктивність контролера домену. Коли цей факт отримує підтвердження,
слід перемістити роль PDC Emulator на інший сервер, що не несе на собі
будь-яких додаткових ролей. p>
RID
master p>
Ця
роль дуже специфічна. Як було сказано вище, її основна функція полягає
у формуванні відносного ідентифікатора безпеки (RID, relative
identifier), що використовується операційною системою для формування нового
об'єкта захисту. На сервері цій ролі є база з кількома мільйонами RID,
унікальних в межах існуючого лісу. При створенні нового контролера
домену RID Master виділяє йому деякий масив RID-ідентифікаторів, які
можуть бути використані при створенні нових об'єктів захисту. Відповідно,
якщо цей запас підійде до кінця, і при цьому RID Master виявиться недоступний, то
створення нових об'єктів захисту буде неможливо. У нашій пілотної мережі такий
відмова одного разу стався при збої зв'язку між контролером домену і сервером RID
Master. При цьому робота в режимі без зв'язку з RID Master тривала майже
тиждень, що дозволяє з тим або іншим ступенем впевненості встановити час
реакції на відмову RID Master в 2-3 дня в залежності від інтенсивності створення
нових об'єктів захисту. p>
Infrastructure
master p>
Це
сама «незрозуміла» роль мережі Windows 2000. І як тільки її не називають в
конференціях - і сервер центральної захисту лісу, і головний сервер
безпеки, який контролює те, що відбувається в лісі ... Насправді цей сервер
відповідає за перетворення імен при междоменних взаємодіях. Прикладом
такої взаємодії може бути приєднання користувача з домену А до
групі домену Б. p>
Важливою
особливістю носія цієї ролі є те, що на одному фізичному сервері
не можна розміщувати Infrastructure Master і сервер глобального каталогу. У
Інакше через сусідство з глобальним каталогом IM завжди буде
містити самі останні дані, не маючи потребу у відновленні. У цьому випадку IM
ніколи не отримає посилання на об'єкт, що не обслуговується цим контролером домену.
Отже, якщо не примусити IM шукати посилання на невідомий об'єкт, то він
ніколи не буде оновлювати свою інформацію. Зрозуміло, в однодоменном режимі
необхідність у IM мінімальна. p>
Мабуть,
найбільшу складність в процесі міграції представляє усвідомлення
необхідності того чи іншого сервера в рамках конкретної мережевої структури. До
жаль, непоодинокими є випадки, коли системні адміністратори кидають всі сили на
відновлення функціонування другорядного сервера, необхідність якого
в їх мережі досить сумнівна. p>
1.
Ролі Schema Master і Domain Naming Master слід розміщувати на одному
комп'ютері. Причому на цьому ж фізичному сервері повинен бути розміщений сервер
глобального каталогу. Якщо на ньому відбудеться відмову, то перехоплювати цю роль
слід тільки у разі необхідності внесення будь-яких змін в схему або
створення нового домену. p>
2.
Роль PDC Emulator висуває підвищені вимоги до апаратного забезпечення
сервера і є явним кандидатом на розміщення на окремому контролері
домену. У випадку виходу його з ладу для нормального функціонування мережі
необхідний перехоплення цієї ролі. p>
3.
Роль Infrastructure Master повинна бути однією на домен, при цьому вона не повинна
фізично розташовуватися на тому ж сервері, що і сервер глобального каталогу. p>
Список літератури h2>
Для
підготовки даної роботи були використані матеріали з сайту http://www.hostmake.ru/
p>