Using Samba [Chapter 1] 1.4 Реалізація Microsoft

1.4.1 Домени Windows
Малюнок 1.11: Простий домен Windows
1.4.1.1 Контролери Домену
Малюнок 1.12: Використання контролера домену для аутеніфікаціі
1.4.2 Перегляд
1.4.2.1 Рівні перегляду
Малюнок 1.13: Домен Windows з головним і вторинним браузером
1.4.2.2 Вибори браузерів
1.4.3 Чи може робоча група Windows розділена на декілька підмереж?
Малюнок 1.14: Робоча група, яка знаходиться в більш ніж однієї підмережі
1.4.4 Служба імен Інтернет Windows (WINS)
1.4.5 Що може робити Samba?

Нарешті, ми можемо говорити про версії Microsoft щодо мережевого протоколу CIFS / SMB. І, як ви напевно вже уявляєте, є кілька моментів, які необхідно обговорити.

1.4.1 Домени Windows

Нагадаємо, що робоча група - це набір комп'ютерів в мережі SMB, які знаходяться в одній підмережі і представлені однією робочою групою SMB. Домен Windows йде далі цього. Це робоча група комп'ютерів SMB з одним доповненням: сервером, виступаючому в ролі контролера домену. Для того, щоб мати домен Windows, вам необхідно мати також контролер домену []. Інакше, це буде всього лише робоча група. Погляньте на малюнок 1.11 .

Малюнок 1.11: Простий домен Windows

Нарешті, ми можемо говорити про версії Microsoft щодо мережевого протоколу CIFS / SMB

Всього існує два різних протоколу, які використовує контролер домену (сервер входу): один для з'єднання з комп'ютерами під управлінням Windows 95/98 і один для з'єднання з комп'ютерами під управлінням Windows NT. У той час, як Samba на поточний момент підтримує протокол контролера домену для Windows 95/98 (який дозволяє їй виступати у вигляді контролера домену для комп'ютерів Windows 9 x), в той же час він повністю не підтримує протокол для комп'ютерів з Windows NT. Проте, команда розробників Samba обіцяє підтримку протоколу контролера домену для Windows NT в Samba 2.1.

У чому вся складність? Протокол, який використовує контролер домену Windows для з'єднання зі своїми клієнтами та іншими контролерами домену, закритий Microsoft. Це призвело команду розробників Samba до використання так званої "зворотної розробки" протоколу контролера домену, для того, щоб дізнатися, який код яку виконує завдання.

1.4.1.1 Контролери Домену

Контролер домену - це нервовий центр домена Windows, точно також, як і сервер NIS - це нервовий центр мережевої інформаційної служби Unix. Контролер домену виконує кілька обов'язків. Одна з обов'язків пов'язана з аутеніфікаціей. Аутеніфікація - це процес визначити, чи потрібно доступу користувача до ресурсу на іншому мережевому комп'ютері, зазвичай здійснюється за допомогою пароля.

Кожен контролер домену використовує менеджер безпеки (SAM) для роботи з комбінаціями ім'я користувача-пароль. Потім контролер домену формує центральний репозитарій паролів, які прив'язані до імен користувачів (один пароль на користувача), що більш ефективно, ніж використання кожного комп'ютера клієнта для утримання сотні паролів на кожен доступний мережевий ресурс.

В домені Windows, коли ВОНО НЕ БУДЕ клієнт запитує доступ до ресурсів сервера, сервер подумає і запитає контролер домену, авторизований користувач. Якщо це так, то сервер встановить сесійне з'єднання з правами доступу, які він має для даної служби і користувача. Якщо немає, то в з'єднанні буде відмовлено. Після того, як користувач одного разу пройшов аутеніфікацію в контролері домену, клієнту буде повернутий спеціальний ідентифікатор, після чого користувачеві не доведеться знову проходити авторизацію в домені для доступу до ресурсів. З цього моменту, користувач вважається "увійшов" в домен. Подивіться на малюнок 1.12 .

Малюнок 1.12: Використання контролера домену для аутеніфікаціі

Малюнок 1.13: Домен Windows з головним і вторинним браузером

Далі показано як порахувати мінімальну кількість вторинних браузерів, які можуть перебувати в робочій групі:

Якщо присутній від 1 до 32 робочих станцій під управлінням Windows NT в мережі або від 1 до 16 комп'ютерів з Windows 95/98 в мережі, головний локальний браузер створить один вторинний браузер на додаток до головного локальному браузеру.

Якщо кількість робочих станцій Windows NT від 33 до 64 або кількість Windows 95/98 від 17 до 32, головний локальний браузер створить два вторинних браузера.
Для кожної групи з 32 робочих станцій NT або 16 комп'ютерів з Windows 95/98, головний локальний браузер створить один вторинний браузер.

Взагалі не існує будь-якого краю вторинних браузерів, які можуть бути створені головними локальними браузерами.

1.4.2.2 Вибори браузерів

Перегляд - це критичний аспект будь-якої робочої групи Windows. Тим не менш, не все працює ідеально в мережі. На приклад, давайте уявимо, що Windows NT Server на робочому столі CEO маленької компанії є головним локальним браузером - до тих пір, поки його не вимкнуть. З цього моменту Windows NT Workstation погоджується прийняти на себе його роботу. Проте, цей комп'ютер зараз працює над великою, погано написаною програмою, яка сильно завантажила його процесор. Мораль: перегляд вельми відчутний до серверів, які входять і виходять з мережі. Оскільки практично кожен комп'ютер Windows може служити браузером, повинен існувати спосіб того, хто візьме на себе цю роботу. Цей процес прийняття рішення називається виборами.

Алгоритм виборів вбудований практично в усі версії ОС Windows, тому кожна з них може погодитися хто стане головним локальним браузером, а хто вторинним. Вибори можуть бути проведені в будь-який час. На приклад, давайте уявимо, що CEO закінчив роботу з повідомленням та перезавантажує сервер. Як тільки сервер з'являється в мережі, він анонсує свою присутність і виробляються вибори для того, щоб побачити чи може комп'ютер в іншому відділі виконувати роль головного браузера.

Під час проведення виборів, кожен комп'ютер широкомовно розсилає датаграми про себе. У них міститься наступна інформація:

Ці значення описують яка ОС має пріоритет і буде виконувати роль головного локального браузера. ( Розділ 6, Користувачі, Безпека і Домени , Описує процес виборів більш детально.) Розроблена архітектура архівування цих даних виконана досить погано і має вбудовані проблеми з безпекою. У той час, як домен перегляду може бути поєднаний з доменом безпеки, алгоритм виборів не входить у взаємодію з комп'ютерами, які стають браузерами. Тому можливо, що якщо будь-який комп'ютер з працюючою службою браузера для власної реєстрації проходить процедуру виборів і (після перемоги) може виконувати зміни в списку перегляду. Проте, перегляд - це ключова особливість мережі Windows, мережа і зворотна сумісність реалізовані і використовуються вже кілька років.

1.4.3 Чи може робоча група Windows розділена на декілька підмереж?

Так, але більшість людей, які працюють з цим мають головний біль. Розбиття на декілька підмереж з самого початку не було задумано при розробці Windows NT 3.5 або Windows for Workgroups. В результаті, домен Windows який працює в одній або більше підмереж, насправді "склеює" разом дві або більше робочих груп, які мають однакову назву. Гарна новина полягає в тому, що ви все ще можете використовувати головний контролер домену для стеження за аутеніфікаціей в кожній підмережі. Погані новини полягають в тому, що не все так просто з переглядом.

Як було зазначено раніше, кожна підмережа повинна мати свій власний головний локальний браузер. Коли домен Windows працює в декількох подсетях, системний адміністратор повинен вибрати один з комп'ютерів в якості головного браузера домену. Головний браузер домену збереже список перегляду для домену Windows. Цей список перегляду створюється шляхом періодичної синхронізації списку для кожного головного локального браузера зі списком перегляду головного браузера домену. Після синхронізації, головний локальний браузер і головний браузер домену будуть містити однакові записи. Погляньте на малюнок 1.14 в якості ілюстрації.

Малюнок 1.14: Робоча група, яка знаходиться в більш ніж однієї підмережі

Звучить добре? Тим не менш, це не зовсім нірвана з кількох причин:

Якщо існує головний контролер домену, то він завжди грає роль головного браузера домену. За задумом Microsoft, два типу ресурсу NetBIOS <1B> не можуть (на жаль) бути розділені.