Що таке Active Directory?
Служба доменів Active Directory - сервер каталогів Microsoft. Він надає механізми аутентифікації та авторизації, а також основу, в якій можуть бути розгорнуті інші пов'язані служби (Сертифікати AD, Служби AD Federated Services тощо). Це база даних, сумісна з LDAP, що містить об'єкти. Найчастіше використовувані об'єкти - це користувачі, комп'ютери та групи. Ці об'єкти можуть бути організовані в організаційні підрозділи (ОУ) на будь-яку кількість логічних або ділових потреб. Об'єкти групової політики (GPO) потім можуть бути пов’язані з OU для централізації параметрів для різних користувачів або комп'ютерів в організації.
Коли люди кажуть "Active Directory", вони зазвичай посилаються на "Служби домену Active Directory". Важливо зазначити, що існують інші ролі / продукти Active Directory, такі як Сертифікати, Послуги Федерації, Полежні служби каталогів, Послуги з управління правами тощо. Ця відповідь стосується конкретно Служб домену Active Directory.
Що таке домен і що таке ліс?
Ліс - межа безпеки. Об'єкти в окремих лісах не в змозі взаємодіяти один з одним, якщо адміністратори кожного окремого лісу не створять між ними довіри . Наприклад, обліковий запис адміністратора підприємства domain1.com
, який, як правило, є найбільш привілейованим обліковим записом лісу, не матиме жодних дозволів у другому лісі, який називається domain2.com
, навіть якщо ці ліси існують в межах однієї локальної мережі, якщо немає довіри на місце .
Якщо у вас є кілька непересічних бізнес-підрозділів або вам потрібні окремі межі безпеки, вам потрібно кілька лісів.
Домен - це межа управління. Домени - частина лісу. Перший домен у лісі відомий як домен кореневого лісу. У багатьох малих та середніх організаціях (і навіть у деяких великих) ви знайдете лише один домен в одному лісі. Домен кореня лісу визначає за замовчуванням простір імен для лісу. Наприклад, якщо названо перший домен у новому лісі domain1.com
, то це домен кореневого лісу. Якщо у вас є потреба в бізнесі для доменного домену, наприклад - філія в Чикаго, ви можете назвати дочірній домен chi
. FQDN дочірнього домену будеchi.domain1.com
. Ви можете бачити, що ім'я дочірнього домену було попередньо ім'ям доменного лісового кореня. Як правило, це працює. Ви можете мати непересічні простори імен в одному лісі, але це зовсім окрема банка глистів за інший час.
У більшості випадків вам потрібно спробувати зробити все можливе, щоб мати єдиний домен AD. Це спрощує управління, а сучасні версії AD дозволяють дуже легко делегувати контроль на основі ОУ, що зменшує потребу в дочірніх доменах.
Я можу назвати свій домен все, що хочу, правда?
Не зовсім. dcpromo.exe
, інструмент, який здійснює просування сервера до постійного струму, не є ідіотом. Це дозволяє вам приймати погані рішення з назви, тому зверніть увагу на цей розділ, якщо ви не впевнені. (Редагувати: dcpromo застаріло на сервері 2012. Використовуйте Install-ADDSForest
командлет PowerShell або встановіть AD DS від Server Manager.)
Перш за все, не використовуйте складені TLD, такі як .local, .lan, .corp чи будь-яке інше лайно. Ці TLD не зарезервовані. ICANN зараз продає TLD, тож ваш, mycompany.corp
який ви використовуєте сьогодні, фактично може належати комусь завтра. Якщо у вас є власник mycompany.com
, то розумною справою є використання чогось подібного internal.mycompany.com
або ad.mycompany.com
для вашого внутрішнього імені AD. Якщо ви користуєтесь mycompany.com
веб-сайтом, що вирішується ззовні, вам слід уникати використання його як свого внутрішнього імені AD, оскільки ви отримаєте DNS з розділеним мозком.
Контролери домену та глобальні каталоги
Сервер, який відповідає на запити на автентифікацію чи авторизацію, - це контролер домену (DC). У більшості випадків контролер домену зберігатиме копію Глобального каталогу . Глобальний каталог (GC) - це частковий набір об'єктів у всіх областях лісу. Це прямий пошук, що означає, що запити між доменами зазвичай можуть виконуватися в GC, не потребуючи перенаправлення на постійний струм у цільовому домені. Якщо на порт 3268 запитується постійний постійний струм (якщо використовується SSL 3269), то GC запитується. Якщо порт 389 (636, якщо використовується SSL), запитується, то використовується стандартний LDAP-запит, і об'єкти, що існують в інших доменах, можуть вимагати перенаправлення .
Коли користувач намагається увійти на комп'ютер, який приєднався до AD за допомогою своїх облікових даних AD, солоне та хешоване поєднання імені користувача та пароля надсилається до постійного струму як для облікового запису користувача, так і для облікового запису комп'ютера, який входить у систему. Так, комп'ютерні журнали теж. Це важливо, оскільки якщо з обліковим записом комп'ютера в AD щось трапляється, як-то хтось скидає обліковий запис або видаляє його, ви можете отримати помилку, яка говорить про те, що між комп’ютером та доменом не існує довірчих відносин. Незважаючи на те, що ваші мережеві дані є нормальними, комп'ютеру більше не довіряють входити в домен.
Побоювання доступності контролера домену
Я чую, що "у мене є первинний контролер домену (PDC) і хочу встановити резервний контролер домену (BDC)" набагато частіше, в що я хотів би повірити. Концепція PDC та BDC померла з Windows NT4. Останній бастіон для PDC був у перехідному змішаному режимі Windows 2000 AD, коли у вас ще були постійні постійні струми NT4. В основному, якщо ви не підтримуєте 15-річну установку, яка ніколи не оновлювалася, у вас дійсно немає PDC або BDC, у вас просто два контролери домену.
Кілька постійних постійних струмів здатні одночасно відповідати на запити автентифікації від різних користувачів та комп'ютерів. Якщо один не вдасться, то інші продовжуватимуть пропонувати послуги аутентифікації, не роблячи одного "основного", як ви мали б зробити протягом NT4 днів. Найкращою практикою є щонайменше два постійних токів на домен. Ці постійні токи повинні обидві містити копію GC, і обидва повинні бути DNS-серверами, які зберігають також копію з інтегрованих DNS-зон DNS для вашого домену.
Ролі FSMO
"Отже, якщо немає PDC, чому існує роль PDC, яку може мати лише один DC?"
Я це багато чую. Є роль емулятора PDC . Це інакше, ніж бути PDC. Насправді є 5 гнучких одноосібних головних операцій (FSMO) . Вони також називаються ролями майстра операцій. Два терміни взаємозамінні. Що вони і що роблять? Гарне питання! 5 ролей та їх функції:
Майстер імен домену - Є лише один майстер імен домену на ліс. Майстер імен домену гарантує, що коли новий домен додається до лісу, він є унікальним. Якщо сервер, який займає цю роль, не працює в режимі офлайн, ви не зможете внести зміни до простору імен AD, що включає такі речі, як додавання нових дочірніх доменів.
Майстер схеми - у лісі є лише один майстер операцій із схеми. Він несе відповідальність за оновлення схеми Active Directory. Для таких завдань, як підготовка AD до нової версії Windows Server, що функціонує як постійний струм, або встановлення Exchange, потрібні зміни схеми. Ці зміни повинні бути виконані у Майстра схеми.
Майстер інфраструктури - Є один майстер інфраструктури на домен. Якщо у вас є лише один домен у вашому лісі, вам не потрібно про це хвилюватися. Якщо у вас є декілька лісів, то ви повинні переконатися, що цю роль не виконує сервер, який також є власником GC, якщо кожен постійний струм у лісі не є GC . Майстер інфраструктури несе відповідальність за правильне посилання на міждоменні посилання. Якщо користувача в одному домені додано до групи в іншому домені, майстер інфраструктури для відповідних доменів переконайтеся, що з ним правильно обробляється. Ця роль не буде функціонувати правильно, якщо вона є у глобальному каталозі.
Майстер RID - Мастер відносного ідентифікатора (Master RID) відповідає за видачу пулів RID в постійні токи. На один домен існує один майстер RID. Будь-який об’єкт у домені AD має унікальний ідентифікатор безпеки (SID). Складається з комбінації ідентифікатора домену та відносного ідентифікатора. Кожен об’єкт у даному домені має однаковий ідентифікатор домену, тому відносний ідентифікатор - це те, що робить об’єкти унікальними. Кожен DC має пул відносних ідентифікаторів для використання, тому коли цей DC створює новий об'єкт, він додає RID, який він ще не використовував. Оскільки ДК видаються пулами, що не перекриваються, кожен RID повинен залишатися унікальним протягом тривалості життя домену. Коли постійний постійний струм потрапляє до ~ 100 RID, залишених у своєму пулі, він вимагає нового пулу від головного RID. Якщо майстер RID не працює в режимі офлайн протягом тривалого періоду часу, створення об'єкта може не вдатися.
PDC Emulator - Нарешті, ми дістаємося до найбільш нерозуміної з них усіх, ролі PDC Emulator. Є один емулятор PDC на домен. Якщо є невдала спроба аутентифікації, вона передається в Емулятор PDC. Емулятор PDC функціонує як "вимикач", якщо пароль був оновлений на одному постійному струмі і ще не повторився на інші. Емулятор PDC - це також сервер, який контролює синхронізацію часу в домені. Усі інші постійні мережі синхронізують свій час з емулятора PDC. Усі клієнти синхронізують свій час із постійного струму, в який вони увійшли. Важливо, щоб все залишалося протягом 5 хвилин один від одного, інакше Керберос ламається, і коли це станеться, всі плачуть.
Важливо пам’ятати, що сервери, на яких виконуються ці ролі, не встановлені в камені. Зазвичай тривіально переміщувати ці ролі, тому, хоча деякі постійні виконавці працюють трохи більше, ніж інші, якщо вони знижуються на короткий проміжок часу, все зазвичай нормально функціонує. Якщо вони тривалий час вниз, то легко прозоро переносити ролі. Це набагато приємніше, ніж дні PDC / BDC NT4, тому, будь ласка, перестаньте телефонувати вашим постійним клієнтам за тими старими назвами. :)
Отже, гм ... як ДК діляться інформацією, якщо вони можуть функціонувати незалежно один від одного?
Реплікація, звичайно . За замовчуванням постійні джерела постійного струму, що належать одному домену в одному веб-сайті, будуть реплікувати свої дані один одному через інтервали 15 секунд. Це гарантує, що все є відносно сучасним.
Є деякі "невідкладні" події, які викликають негайну реплікацію. Це такі події: Обліковий запис заблоковано для занадто великої кількості невдалих реєстрацій, вноситься зміна домену пароля або політики блокування, змінюється секрет LSA, змінюється пароль в обліковому записі комп'ютера постійного струму або передається роль головного RID до нового постійного струму. Будь-яка з цих подій спричинить негайну подію реплікації.
Зміни пароля потрапляють десь між терміновими та невідкладними та обробляються однозначно. Якщо пароль користувача буде ввімкнено, DC01
і користувач намагається увійти в комп'ютер, на якому відбувається автентифікація, DC02
перш ніж відбудеться реплікація, ви очікуєте, що це не вдасться, правда? На щастя, цього не відбувається. Припустимо, що тут також називається третій DC, DC03
який виконує роль емулятора PDC. Після DC01
оновлення нового пароля користувача ця зміна також негайно повторюється DC03
. Коли спроба аутентифікації завершиться DC02
невдачею, DC02
тоді вона пересилає цю спробу аутентифікації DC03
, яка підтверджує, що вона справді добра, і вхід дозволений.
Поговоримо про DNS
DNS має вирішальне значення для належно функціонуючого AD. Офіційна лінія партії Microsoft полягає в тому, що будь-який DNS-сервер можна використовувати, якщо він правильно налаштований. Якщо ви намагаєтеся використовувати BIND для розміщення зон AD, ви високі. Серйозно. Дотримуйтесь використання DNS-інтегрованих DNS-зон і використовуйте умовні або глобальні перенаправники для інших зон, якщо потрібно. Усі ваші клієнти повинні бути налаштовані на використання ваших серверів AD DNS, тому тут важливо мати надмірність. Якщо у вас є два постійних постійного струму, вони обидва запускають DNS і налаштовуйте своїх клієнтів на використання обох для вирішення імен.
Крім того, ви хочете переконатися, що якщо у вас є більше одного постійного струму, вони не будуть перераховувати себе першими для роздільної здатності DNS. Це може призвести до ситуації, коли вони знаходяться на "острові реплікації", коли вони від'єднані від решти топології реплікації AD і не можуть відновитись. Якщо у вас є два сервера DC01 - 10.1.1.1
і DC02 - 10.1.1.2
, то їх список DNS - сервер повинен бути налаштований таким чином:
Сервер: DC01 (10.1.1.1)
Первинний DNS - 10.1.1.2
Вторинний DNS - 127.0.0.1
Сервер: DC02 (10.1.1.2)
Первинний DNS - 10.1.1.1
Вторинний DNS - 127.0.0.1
Гаразд, це здається складним. Чому я взагалі хочу використовувати AD?
Тому що коли ти знаєш, що ти робиш, життя стає нескінченно кращим. AD дозволяє здійснювати централізацію управління користувачами та комп'ютерами, а також централізацію доступу та використання ресурсів. Уявіть ситуацію, коли у вас в офісі 50 користувачів. Якщо ви хочете, щоб кожен користувач мав свій власний логін для кожного комп'ютера, вам доведеться налаштувати 50 локальних облікових записів користувачів на кожному ПК. З AD вам потрібно зробити лише один раз обліковий запис користувача, і він за замовчуванням може увійти до будь-якого ПК у домені. Якщо ви хочете посилити безпеку, вам доведеться зробити це 50 разів. Сорт кошмару, правда? Також уявіть, що у вас є спільний доступ до файлів, на який ви хочете потрапити лише половині людей. Якщо ви не використовуєте AD, вам потрібно буде або копіювати їх ім’я користувача та паролі вручну на сервері, щоб надати доступ, здавалося б, або ви ' я повинен зробити спільний обліковий запис і дати кожному користувачеві ім’я користувача та пароль. Один із способів означає, що ви знаєте (і повинні постійно оновлювати) паролі користувачів. Інший спосіб означає, що у вас немає сліду аудиту. Не добре, правда?
Ви також отримуєте можливість використовувати групову політику, коли ви встановили AD. Групова політика - це сукупність об'єктів, пов'язаних з ОУ, які визначають налаштування для користувачів та / або комп'ютерів у цих ОУ. Наприклад, якщо ви хочете зробити так, щоб "Завершення роботи" не було в меню "Пуск" для 500 лабораторних ПК, ви можете зробити це в одному налаштуванні в груповій політиці. Замість того, щоб витрачати години або дні на налаштування належних записів реєстру вручну, ви створюєте об’єкт групової політики один раз, пов'язуєте його з правильними OU або OU, і ніколи більше не потрібно думати про це. Існують сотні GPO, які можна налаштувати, а гнучкість групової політики є однією з головних причин того, що Microsoft настільки домінуючий на корпоративному ринку.