СЛУЖБИ КАТАЛОГІВ

71 Загальні відомості про служби каталогів

На зорі компютеризації підприємств навантаження на адміністраторів компютерних систем була невелика Справа була не стільки в количествен-них характеристиках (загальне число серверів, мережевого обладнання, робочих станцій і тп було значно нижче в ті часи), скільки в качествен-них – до появи досить потужних і дешевих персональних компю-теров робота в системі велася через термінали З точки зору адміністра-тора це означало, що все управління користувачами зводилося до адмініст-рірованіі одного єдиного сервера З часом ситуація стала ме-няться, по-перше, підприємства набували все більшу кількість серве-рів, по-друге, питань безпеки стало приділятися все більше уваги, що вимагало більшого контролю кожної дії користувача (як наслідок, введення строгої аутентифікації для кожного значущого для сис-теми дії)

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

Рішенням цієї проблеми стало створення так званих служб ката-

логів – Систем централізованого зберігання інформації про користувачів Міжнародна організація по стандартизації (ISO) запропонувала стандарт X500, який описував функціонування такої системи Однак прото- кіл взаємодії, описаний в рамках стандарту, виявився занадто пере-вантаженим для мереж TCP / IP З цієї причини якийсь час служби ката-логу створювалися виробниками з використанням різних протоколів взаємодії (NDS, NIS, NT4 domain) Така різноманітність реалізацій при-вело до того, що незалежні розробники мережевих сервісів або зовсім не забезпечували сумісності зі службами каталогів, або забезпечували со-місткість з якоюсь конкретною реалізацією Як наслідок, кожен про-изводителей служби каталогу повинен був забезпечити клієнтів і базовим на-бором служб (наприклад, власним файл-сервером)

Ситуація змінилася тільки тоді, коли Інтернет-спільнота опуб-раділо «полегшений» варіант стандарту X500 – протокол LDAP (Lightweight Directory Access Protocol1, RFC 4510) Протокол забезпечував про-стій доступ до каталогу в рамках TCP-зєднання, стосувався також питань ау-тентіфікаціі і власне структури каталогу Пізніше стандарт зазнав

1 Назва так і перекладається: полегшений протокол доступу до каталогу

деяка кількість редакцій і в даний час підтримується практи-

тично будь-яким мережним додатком і реалізований в будь-якій службі каталогу

Розвиток протоколу продовжується і сьогодні Вже використовується версія 3 даного протоколу, а також опублікований цілий ряд розширень (наприклад, підтримка language tags, що дозволяє зберігати імя користувача, записане на декількох мовах, і відправляти клієнту імя на його рідній мові)

Багато сучасних мережеві додатки також володіють вбудованою підтримкою LDAP (поштові клієнти здатні виробляти пошук адреси по імені користувача, web-сервери і СУБД можуть витягувати список пользова-

телей з каталогу LDAP, розподілені додатки можуть зберігати свої на-

будови в каталозі LDAP і т п)

Після того як всі дані про користувачів, групах, в які вони входять, і їх права доступу перемістилися в централізоване сховище,

розробники стали замислюватися і про рішення іншої проблеми сучасних компютерних систем – про постійну необхідність користувачів в ау-

тентіфікаціі Виробники стали випускати системи з концепцією єдино-го входу в мережу (так звані системи SSO – single sign on), тобто пользова-тель при одноразовому введенні пароля отримував доступ до всіх ресурсів мережі На

практиці це працювало тільки з сервісами самого виробника, оскільки занадто розрізнялися протоколи мережевої аутентифікації у різних при-ложений Ті способи вирішення проблеми, які намагалися запропонувати кон-

Конкретні виробники, що не були універсальні Рішення від Microsoft позво-лялі зберігати пароль користувача не у вигляді хеша, а в восстанавливаемом вигляді (тобто практично у відкритому), Novell дозволяв зберігати пароль різними способами (зашифрований хешем пароля секретний ключ для сервісів

Novell, NTLM-хеш для доступу до сервісів Microsoft) Такі рішення позво-лялі користувачеві не вводити свій пароль зайвий раз, але не були ні без-пасном, ні універсальними

Ситуація знову змінилася завдяки відкритим стандартам С не-великим проміжком часу зявилися описи методів, що дозволяють розділити сам мережевий сервіс і процес аутентифікації користувача, що

дозволяло використовувати будь-який мережевий сервіс з потрібним методом аутентіфі-кации В даний час три цих методу поширені досить широ-ко – це SASL (Simple Authentication and Security Layer, RFC 4422), GSSAPI

(Generic Security Service Application Program Interface, RFC 2743) і SPNEGO (Simple and Protected GSSAPI Negotiation, RFC 2478) Всі перераховані ме-тоди реалізують приблизно одну і ту ж ідею – існує чіткий інтерфейс взаємодії мережевого сервісу з бібліотекою, яка, як правило, є по-

ється розширюється за допомогою модулів (знову ж зі строго зафіксований-ним інтерфейсом) При цьому в стандарт закладається механізм узгоджен-ня використовуваного модуля для аутентифікації клієнта і сервера

Подібні механізми часто зустрічалися в рамках одного протоколу

(Наприклад, узгодження діалекту SMB або методу аутентифікації NFS),

проте вони були унікальними для кожного протоколу, що ускладнювало мож-ливість використання одних і тих же методів аутентифікації для різних мережевих сервісів

Зручність полягає також у тому, що універсальні методи аутен-

тіфікаціі можна вкладати один в одного Іншими словами, якщо сервіс був написаний з підтримкою механізму GSSAPI, а у виробника служби катало-

га є тільки модулі SASL, реалізують необхідні методи аутентіфі-кации, то будь-яка зацікавлена ​​особа може створити GSSAPI-модуль, кото-рий реалізує аутентифікацію за механізмом SASL (рис 71)

Рис 71 Приклад вкладеності механізмів мережевий аутентифікації

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

В якості універсального протоколу аутентифікації можна вико-

зовать інфраструктуру відкритих ключів (наприклад, на базі сертифікатів

X509) або протокол Kerberos (див нижче)

У цьому розділі розглянута реалізація служби каталогу корпорації

Microsoft – Active Directory (AD) на прикладі інтеграції її в середу сторін-

них сервісів А саме, рішення задачі аутентифікації користувачів на

web-сервері Apache за допомогою протоколу Kerberos, а також налаштування меха-

низмов аутентифікації і авторизації на робочій станції під управлінням

ОС Linux з метою отримання авторизуйтесь інформації з Active Directory

Служба Active Directory складається з цілого набору сервісів, повязаних між собою Основою Active Directory є система розпізнавання імен, за допомогою якої робочі станції здатні прозоро виявляти сервери домену, наприклад LDAP-сервери В існуючій реалізації сер-вису каталогу в якості служби дозволу імен обрана система DNS (на відміну від попередніх версій, які використовували систему імен NetBIOS) Для зберігання каталогу LDAP, а також для забезпечення аутентіфі-кации по протоколу Kerberos в мережі Microsoft виділяються спеціальні серве-ра, які називаються контролерами домену В цілому контролер будинку-на – це виділений сервер, призначений для забезпечення сервісів LDAP і KDC (див нижче)

В якості першої вправи пропонується встановити службу Active

Directory на ОС Windows Server 2003 В якості проміжного кроку тре-

буется встановити і налаштувати DNS-сервер

ВИКОНАТИ

1 Запустити віртуальну машину Windows Server 2003 (далі DC)

2 Встановлення та налаштування DNS-сервера Цей крок складається з двох основних дій: налаштування клієнта DNS і встановлення та налаштування сервера DNS

a Налаштувати імя компютера (після внесення змін буде потрібно

перезавантаження): name: DC, DNS suffix: examplecom

b Встановити DNS-сервер (Add / Remove programs ⇒ Windows components

⇒ Network services ⇒ DNS)

c Запустити оснастку адміністрування DNS (Start ⇒ Administrative

Tools ⇒ DNS)

d Створити зону прямого перегляду Вибрати з контекстного меню обєк-

єкта «Forward lookup zones пункт New zone» Вибрати тип зони

«Primary», імя зони «examplecom», дозволити динамічні обнов-лення для зони Ця зона буде зберігати інформацію про створюваний нами домені Active Directory Імя домену Active Directory збігається з імям DNS домену, в якому і буде зберігатися інформація про сер-вірах і робочих станціях Active Directory

e Створити зону зворотного перегляду Вибрати з контекстного меню обєкта «Reverse lookup zones пункт New zone» Вибрати тип зони

«Primary», network id 1921680

f Створити запис для робочої станції ws-linux (це стане в нагоді пізніше,

коли буде проводитися настройка відповідної віртуальної машини) Вибрати в списку зон прямого перегляду зону

«Examplecom», вибрати з контекстного меню зони пункт «New host

(A) », вказати імя хоста« ws-linux », IP-адресу 19216802, вибрати оп-

цію «Create associated pointer (PTR) record»

3 Підвищення ролі сервера до контролера домену Дана процедура прак-тично повністю автоматизована, необхідно лише вказати некото-рую допоміжну інформацію (наприклад, про роль і місце нашого но-вого контролера домену в існуючій інфраструктурі) Тут ми не будемо докладно розглядати складні схеми побудови доменів AD

a Запустити утиліту dcpromo

b Вибрати пункт «New domain controller in a new domain» c Вибрати пункт «New domain in a new forest»

d Вказати імя домену «examplecom»

e NetBIOS-імя і розташування службових файлів залишити по умолча-

нию

f Переконатися, що тест динамічних оновлень на DNS-сервері пройшов успішно

g Вибрати режим сумісності тільки з ОС Windows 2000 і 2003

h Вказати пароль режиму відновлення «P @ ssw0rd»

i Дочекатися закінчення роботи майстра і перезавантажитися

4 Встановлення додаткових інструментів адміністрування

a Встановити пакет «adminpakmsi», розташований в каталозі

«WINDOWS \ System32» Даний пакет міститься у всіх серверних версіях ОС Windows і містить набір оснащень MMC для адмініст-рірованія різних сервісів ОС Windows

b Встановити пакет «suptoolsmsi» Пакет Windows Support Tools постав-ляется разом з дистрибутивом операційної системи (зазвичай Наявна в каталозі SUPPORT інсталяційного диска)

c Встановити пакет «rktoolsexe»

Джерело: Андрончик А Н, Богданов В В, Домуховскій Н А, Коллеров А С, Синадський Н І, Хорьков Д А, Щербаков М Ю, Захист інформації в компютерних мережах Практичний курс

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*