Використання протоколу LDAP (Lightweight Directory Access Protocol) при пошуку в службі каталогів Active Directory інформації, необхідної для завантаження і входу в систему.
Цільова аудиторія
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet
Додайте наступний ключ:
Ім'я ключа: IPAutoconfigurationEnabled
Тип ключа: REG_DWORD
Значення в шістнадцятковій системі числення: 0 (значення 0 відключає підтримку механізму APIPA для цього адаптера).
Примітка. У разі, якщо навіть ключ IPAutoconfigurationEnabled відсутня, то за замовчуванням вважається, що він є і має значення 1, що відповідає включеному станом кошти APIPA.
Для отримання додаткової інформації зверніться до наступних матеріалів:
Документами RFC 1035, RFC 1 036.
Kerberos версії 5 є протоколом аутентифікації. Він дозволяє комп'ютерам здійснювати взаємну аутентифікацію. Іншими словами, він дозволяє комп'ютерам ідентифікувати один одного. Він також є основою для всіх систем безпеки. До тих пір, поки сервер не буде повністю впевнений в тому, що Ви є тим, за кого себе видаєте, як він не зможе забезпечити надійний доступ до своїх ресурсів? Як тільки сервер ідентифікує Вас, він зможе визначити, чи є у Вас відповідні повноваження на доступ до його ресурсів.
Існує шість первинних повідомлень Kerberos. Ці шість повідомлень в дійсності є три типи дії, кожне з яких містить запит клієнта і відповідь центру поширення ключів (Key Distribution Center, KDC). Перша дія полягає у введенні клієнтом пароля. Клієнт Kerberos робочої станції відсилає запит "AS" в службу перевірки автентичності (Authentication Service) центру KDC, запитуючи у служби перевірки справжності квиток в якості відповіді для того, щоб підтвердити, що користувачі є тими, за кого себе видають. Служба перевірки автентичності перевіряє облікові дані користувачів і відсилає назад квиток надання квитка (Ticket Granting Ticket, TGT).
Друга дія полягає в тому, що клієнт запитує доступ до служби або ресурсу, відсилаючи TGS-запит в службу Ticket Granting Service (TGS) центру KDC. Служба TGS повертає клієнту індивідуальний квиток, який він може використовувати для отримання доступу до запитуваної службі на будь-якому сервері, на якому вона працює.
Третя дія полягає в тому, що клієнт Kerberos пред'являє сервера квиток на доступ до служби та запитує дозвіл на доступ до необхідної йому службі або ресурсу. Ці повідомлення називаються «AP». У реалізації Microsoft ідентифікатори безпеки (Security ID, SID) містяться в поле PAC, яке є частиною квитка, посилається на сервер. Це третя дія не вимагає відповіді від сервера, якщо тільки клієнт не запитав виконати взаємну аутентифікацію. Якщо ж клієнт запросив взаємну аутентифікацію, то сервер повертає клієнтові повідомлення, що містить мітку часу аутентифікації (authenticator timestamp). У разі звичайного входу в домен всі ці три дії відбуваються перед тим, як користувач отримає доступ до робочої станції.
Робота по протоколу LDAP
Прийнята в LDAP загальна модель передбачає, що всі операції клієнта, пов'язані з протоколом, виконуються на сервері. Клієнт передає серверу запит, в якому вказано ту операція, яку повинен виконати сервер. З цього моменту вся відповідальність за виконання необхідних операцій в каталозі лягає на сервер. По завершенню виконання необхідних операцій сервер повертає клієнтові або результат операції, або повідомлення про помилку.
Інформаційна модель LDAP заснована на записи, в якій міститься інформація про якомусь об'єкті (наприклад, людині). Записи складаються з атрибутів, що мають одне або кілька значень. Кожен атрибут має певний синтаксис написання, що визначає допустимі значення атрибута і те, яким чином ці значення задіяні при виконанні операцій з каталогом. Атрибутами можуть виступати: строкові значення IA5 (ASCII), URL-посилання і відкриті ключі.
Можливості протоколу LDAP
В протокол можуть бути додані розширення для підтримки нових операцій, а також можуть використовуватися засоби управління, що розширюють можливості наявних операцій.
RootDSE є вершиною логічного простору імен і, до того ж, вершиною дерева, за яким здійснюється пошук за допомогою LDAP. Атрибути rootDSE визначають обидва розділу каталогу (домен, схему і налаштування розділів каталогу), які є особливими для окремо взятого контролера домену та для лісу розділу каталогу кореневого домена.
RootDSE публікує інформацію про сервер LDAP, включаючи інформацію про те, скільки разів LDAP він підтримує, підтримувані механізми SASL і механізми управління, точно так же, як і различающееся ім'я для його записи підсхеми.
Клієнти приєднуються до rootDSE, на початку роботи по LDAP.
LDAP поверх TCP
Використання протоколу LDAP при завантаженні і вході в систему
Для отримання додаткової інформації зверніться до наступних матеріалів:
Безпека протоколу SMB розвивалася паралельно з розвитком тих платформ, які використовували даний протокол. У базовій моделі протоколу SMB визначені два рівня безпеки:
Рівень загальних ресурсів. В даному випадку захист здійснюється на рівні загальних ресурсів сервера. Для отримання доступу до кожного загального ресурсу необхідний пароль. При цьому тільки той клієнт, якому він відомий, зможе отримати доступ до всіх файлів, доступним на цьому загальному ресурсі. Ця модель безпеки була першою, яка застосовувалася в протоколі SMB, і вона ж була єдиною моделлю безпеки доступною в протоколах Core і CorePlus. У Windows для робочих груп (Windows for Workgroups) vserver.exe за замовчуванням застосовувала цей рівень безпеки, точно так же його використовувала ОС Windows 95.
Призначений для користувача рівень. В даному випадку захист застосовується окремо для кожного файлу кожного загального ресурсу і заснована на правах доступу користувачів. Кожен користувач (клієнт) повинен увійти на сервер під своїм обліковим записом і пройти аутентифікацію. Після завершення перевірки автентичності клієнт отримує відповідний ідентифікатор користувача (user ID), який він повинен пред'являти для отримання доступу до ресурсів сервера. Така модель безпеки була вперше реалізована в протоколі LAN Manager 1.0.
Повідомлення встановлення з'єднання (Connection establishment messages) складаються з команд, якими починається і закінчується з'єднання системи перенаправлення із загальним ресурсом на сервері.
Використання протоколу SMB під час завантаження і входу в систему
Для отримання додаткової інформації зверніться до:
Віддалений виклик процедур MSRPC
Як найпростіший приклад того, що таке RPC, можна навести ситуацію, коли один комп'ютер запитує інший комп'ютер про можливість використання його обчислювальної потужності. Протокол RPC дозволяє одному процесу запитувати інший процес, запущений на іншому комп'ютері в мережі, про можливості їм виконання інструкцій першого процесу.
В процесі RPC задіяні:
Серверний додаток. Виконує необхідні інструкції.
RPC однозначно визначаються за номером інтерфейсу (UUID), номеру операції (opnum) і номеру версії. Номер інтерфейсу визначає групу пов'язаних віддалених процедур. Прикладом інтерфейсу може виступити служба мережевого входу, у якій UUID має значення 12345678-1234-ABCD-EF00-01234567CFFB.
Приклад виклику RPC:
MSRPC: c / o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB call 0x1
assoc grp 0x0 xmit 0x16D0 recv 0x16D0
MSRPC: Version = 5 (0x5)
MSRPC: Version (Minor) = 0 (0x0)
MSRPC: Packet Type = Bind
+ MSRPC: Flags 1 = 3 (0x3)
MSRPC: Packed Data Representation
MSRPC: Fragment Length = 72 (0x48)
MSRPC: Authentication Length = 0 (0x0)
MSRPC: Call Identifier = 1 (0x1)
MSRPC: Max Trans Frag Size = 5840 (0x16D0)
MSRPC: Max Recv Frag Size = 5840 (0x16D0)
MSRPC: Assoc Group Identifier = 0 (0x0)
+ MSRPC: Presentation Context List
RPC не залежить від низькорівневих транспортних протоколів. Microsoft RPC (MSRPC) може використовувати кілька різних транспортних протоколів, таких як TCP / IP, IPX / SPX або NetBEUI.
Більшість інтерфейсів RPC використовують динамічні порти для зв'язку в мережі. У цьому випадку виникає необхідність використовувати особливий інтерфейс, званий сопоставітелем кінцевих точок (End Point Mapper). Цей інтерфейс завжди прослуховує порт 135 для TCP / IP-з'єднань і має номер UUID E1AF8308-5D1F-11C9-91A4- 08002B14A0FA.
Перш ніж клієнт зможе викликати процедури, він повинен здійснити прив'язку до інтерфейсу. У тому випадку, якщо вдалося встановити прив'язку, він може вислати запит до сопоставітелю кінцевих точок (End Point Mapper), в якому буде вказано UUID необхідного інтерфейсу. Сопоставітель кінцевих точок повертає номер порту, який клієнт може використовувати для з'єднання.
У наступній таблиці вказана послідовність пакетів, якими обмінюються сторони, які беруть участь в цьому процесі:
c / o RPC-відповідь: call 0x1
context 0x0 hint 0x80 cancels 0x0
Також можна инкапсулировать пакети MSRPC в SMB. В даному випадку клієнт і сервер для обміну даними використовують дескриптор раніше відкритого файлу.
Для отримання додаткової інформації зверніться до наступних матеріалів:
Розділ «Мережевий трафік, що генерується клієнтом в Active Directory» книги Організація служб підприємства Active Directory: нотатки на полях ( "Active Directory Client Network Traffic," Notes from the Field BuildingEnterprise Active Directory Services) (EN)
Для виконання синхронізації використовується наступна ієрархія систем в домені:
Всі клієнтські настільні комп'ютери використовують як джерело часу свій контролер домену.
Документи RFC: 1769 2030.
Далі більш детально буде розглянуто протокол перевірки автентичності Kerberos, а також буде розглянуто його використання під час завантаження і входу в систему. Протокол NTLM, який використовується при запуску і вході в систему, залишився таким же, як і в Windows NT 4.0. Він докладно описаний в книзі Організація служб підприємства Active Directory: польові замітки (Notes from the Field series book Building Enterprise Active Directory Services) (EN).
Для отримання додаткової інформації зверніться до наступного документу: