Процедура аутентифікації Windows

1. Протоколи, що становлять основу процедури
2. Аутентифікація: загальні принципи
3. завдання протоколу
4. Локальна і доменна реєстрація
5. Протоколи аутентифікації Windows
6. LAN Manager
7. NTLM
8. NTLMv2
9. Kerberos
10. Смарт-карти
11. Захист протоколу аутентифікації
12. Обов'язки користувачів

Протоколи, що становлять основу процедури

Наша взаимовыгодная связь https://banwar.org/

Аутентифікація - це незамінна процедура для кожного користувача, комп'ютера і службового облікового запису Windows, але її механізм не вивчається системними адміністраторами досконально. Кожен знає, що для реєстрації в комп'ютері необхідно вказати вірний пароль, але чи багатьом відомо, що відбувається потім? Аутентифікація Windows і пов'язані з нею протоколи активізуються кожен раз, коли користувач, комп'ютер або служба реєструються локально або на контролері домену (DC). У даній статті мова піде спочатку про основні принципи аутентифікації Windows, а потім про пов'язаних з нею протоколах. На закінчення наводяться короткі рекомендації щодо підвищення надійності процедури аутентифікації в мережі Windows.

Аутентифікація: загальні принципи

Аутентифікація є один з компонентів будь-якої комп'ютерної системи управління доступом. Як показано на екрані 1, системи управління доступом забезпечують ідентифікацію, аутентифікацію, авторизацію і звітність.

Ідентифікація (identification). У процесі ідентифікації використовується набір даних, який унікально ідентифікує об'єкт безпеки (наприклад, користувача, групу, комп'ютер, обліковий запис служби) в загальній службі каталогів. Служба каталогів, така як Active Directory (AD), дозволяє унікально ідентифікувати об'єкти, подібно до того як DNS засвідчує, що дві людини не можуть мати однакові адреси електронної пошти. У внутрішніх механізмах Windows використовуються SID, глобально унікальні ідентифікатори (globally unique identifier, GUID) та інші унікальні теги. У більшості випадків для ідентифікації досить ввести унікальне ім'я облікового запису, таке як Rgrimes. У великому лісі AD доводиться застосовувати повні імена користувачів (user principal name, UPN), наприклад [email protected]. При використанні смарт-карт суб'єкт безпеки може представити свій цифровий сертифікат або ключ.

Аутентифікація або перевірка справжності (authentication). Після того як суб'єкт безпеки вводить з клавіатури або іншим способом надає необхідну для ідентифікації інформацію (наприклад, ім'я користувача, маркер безпеки), він повинен ввести з клавіатури або представити приватну інформацію для аутентифікації (наприклад, пароль і PIN-код). У Windows суб'єкт безпеки вводить цю інформацію на екрані реєстрації за допомогою програм Microsoft Graphical Identification and Authentication DLL (msgina.dll) і Winlogon.exe. Протокол аутентифікації і механізм системи кодують представлену інформацію на настільному комп'ютері і передають запит аутентифікації. Служба аутентифікації Windows може бути базою даних SAM або AD. База даних SAM обслуговує локальні процедури реєстрації та реєстрацію на контролерах домену Windows NT 4.0. AD аутентифікує запити в Windows 2000 або доменах пізніших версій цієї операційної системи. Протокол аутентифікації (наприклад, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) використовується для транспортування запитів аутентифікації і наступних транзакцій між екраном реєстрації та службою аутентифікації. Трохи нижче кожен протокол аутентифікації буде розглянуто окремо.

Авторизація (authorization). Якщо служба аутентифікації засвідчує комбінацію ідентифікатора і «секретних» даних аутентифікації, то справжність суб'єкта безпеки вважається успішно підтвердженої. Потім система збирає інформацію про членство суб'єкта безпеки (т. Е. Користувача) в групах. Нерідко користувач належить до кількох точно певним групам - локальним (local), доменним (domain local), глобальним (global) і універсальним (universal) - в результаті звичайних процедур призначення членства. Система звіряє локальні групи з локальною базою даних SAM і перевіряє локальні і глобальні групи на контролерах DC в домашньому домені користувача, а також універсальні групи на DC, який містить глобальний каталог Global Catalog. Прямо чи опосередковано система збирає всі відомості про членство в групах, щоб отримати інформацію про дозволи безпеки.

Відразу після аутентифікації система збирає ідентифікатори SID облікового запису і відомості про членство в групах в об'єкті, званому маркером доступу (access token). Можливо, користувачеві доведеться вийти і знову зареєструватися в системі, щоб нові дозволи безпеки вступили в силу. Якщо користувачеві потрібно отримати доступ до об'єкта (наприклад, файлу, папки, принтеру, розділу реєстру), захищеному дозволами NTFS, то процес (наприклад, Windows Explorer), який виступає від імені користувача, надає свій маркер доступу. Кожен об'єкт NTFS в своєму розпорядженні список елементів управління доступом (access control entry, ACE), які, по суті, являють собою знайомі дозволу NTFS (наприклад, Allow Read, Allow Write). Набір елементів ACE, призначених користувачам і групам, складає список управління доступом (ACL) даного об'єкта. Примітно, що ACL об'єкта представлений дозволами безпеки, які можна переглянути в Windows Explorer.

Маркер доступу, що містить обліковий запис і групи, з якими пов'язаний користувач, визначає ефективні дозволу користувача. Процес авторизації полягає в дозволі або відмову в доступі до певного об'єкту на основі порівняння маркера доступу з ACL об'єкта. Авторизацію забезпечує Security Reference Monitor системи Windows (екран 1). У прикладі, показаному на екрані 1, користувач має дозволу Read, Write і Modify. Однак група Everyone, до якої належить користувач, не має дозволу Modify. Члени інших груп мають у своєму розпорядженні дозволами Read і Modify, але дозвіл Deny групи Everyone скасовує дозвіл Modify. Об'єкт також має в своєму розпорядженні списками ACL, які відмовляють у дозволі Full Control групі HR, але користувач до цієї групи не належить. Таким чином, ефективні дозволу користувача по відношенню до об'єкта на екрані 2 - Read і Write.

Звітність (accounting). Якщо в Windows режим аудиту активізований, то система зберігає подія аутентифікації в журналі Security, і це останній компонент системи управління доступом - звітність. Більшість складних подій початковій реєстрації і подальшої авторизації відбуваються за кілька секунд і приховані від користувача. Всі складні операції покладаються на протокол аутентифікації.

завдання протоколу

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

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

1. Комп'ютер отримує дані для ідентифікації і аутентифікації від користувача і запитує аутентифікацію на відповідному сервері.
2. Сервер аутентифікації генерує випадкове довільне значення (зване запитом - challenge) і посилає його запитувача.
3. Запитувач отримує запит і виробляє над ним і прихованою формою пароля математичні операції, а потім передає результат (званий відповіддю - response) сервера аутентифікації.
4. Сервер аутентифікації також виконує математичні маніпуляції із запитом методом, ідентичним використовуваному на робочої станції, і порівнює результат з отриманою відповіддю. Якщо результати збігаються, то запитувач вважається успішно аутентифицироваться.

У протоколах аутентифікації використовується процес запит-відповідь, тому пароль ніколи не передається через мережу.

Локальна і доменна реєстрація

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

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

Протоколи аутентифікації Windows

Як зазначалося вище, в Windows застосовується чотири основних протоколу аутентифікації: LAN Manager, NTLM, NTLMv2 і Kerberos. LAN Manager з'явився за часів DOS і продовжував використовуватися з першими версіями Windows. NTLM був випущений разом з NT. Нововведенням пакету оновлень NT Server 4.0 Service Pack 4 (SP4) став NTLMv2, а Windows 2000 привнесла Kerberos. За замовчуванням всі комп'ютери з Windows 2000 і більш новими операційними системами сумісні з усіма чотирма протоколами аутентифікації. Передаючи в ці системи відповідні команди, інші робочі станції і сервери можуть вибирати протокол для обробки запиту аутентифікації. Системи Windows 9x і більш пізні з повним набором програмних виправлень сумісні з LM, NTLM і NTLMv2. На платформі Microsoft Kerberos може використовуватися тільки клієнтами Windows 2000 (або новішими) при зверненнях до домени Windows 2000 (і вище). Комп'ютер з Windows 2000 або більш новою версією операційної системи повинен мати Kerberos і принаймні ще один з протоколів аутентифікації.

Дослідження в області безпеки показали, що більш старі протоколи (LM і NTLM) уразливі в разі прослуховування і атак з розгадуванням пароля.

Тому, якщо можливо, рекомендується використовувати тільки Kerberos і NTLMv2. Щоб переконатися в правильності цієї ради, слід оцінити можливості кожного протоколу.

LAN Manager

Компанія IBM розробила протокол LAN Manager, застосувавши його в ранніх версіях Windows і мережах Windows. Як все протоколи аутентифікації Microsoft, LAN Manager генерує хеш паролів (LM hash), який зберігається і використовується відправником і отримувачем в процесі аутентифікації. LAN Manager формує LM-хеш-кодування, змінюючи всі букви пароля на верхній регістр, розбиваючи пароль на дві 7-символьні половини, а потім шифруючи. Надалі LM-хеш використовується в декількох послідовних операціях, аналогічних процесу запит-відповідь, описаного вище.

Якщо раніше LAN Manager був цілком прийнятний, то зараз він вважається дуже ненадійним. За допомогою спеціальних інструментів паролі, зашифровані методом хеширования LAN Manager, можна всього за кілька секунд перетворити в простий текст. LM-Хешам властиві принципові недоліки, а також є ряд вразливих місць:

• паролі можуть складатися з обмеженою послідовності 128 символів ASCII;
• довжина пароля не перевищує 14 символів;
• якщо пароль містить менше 14 символів, то відсутні символи замінюються легко вгадується хешировать формою, що дозволяє точно визначити довжину пароля;
• перед кешуванням LAN Manager перетворює все літерні символи пароля в верхній регістр.

Чому LAN Manager досі не вийшов з ужитку? З метою забезпечення сумісності він активний за замовчуванням у всіх комп'ютерах Windows, в тому числі Windows Server 2003. У новітніх базах даних аутентифікації Windows слабкий LM-хеш зберігається поряд з більш надійними просто на випадок, якщо доведеться виконати транзакцію LAN Manager. Якщо на підприємстві не використовуються інші програми, що вимагають аутентифікації LAN Manager, то можна (і потрібно) LAN Manager відключити.

NTLM

З появою NT компанія Microsoft спроектувала і розгорнула більш надійний протокол аутентифікації NTLM. У NTLM використовується більш ефективний алгоритм аутентифікації, який створює більш надійний хеш паролів (NTLM hash). Пароль NTLM може містити до 128 символів. На відміну від хеширования LAN Manager, обмеженого використанням тільки символів ASCII, NTLM сумісний з повним набором символів Unicode, що підвищує складність паролів. NTLM-хеш відсікається на 128-му символі, перетворюється в 16-розрядне значення Unicode, обробляється розподільчою функцією MD4 і зберігається в 32-символьного шестнадцатеричной рядку. За рахунок використання NTLM-хешу в операціях запит-відповідь послідовність аутентифікації NTLM набагато складніше процедури LAN Manager.

NTLMv2

В результаті з'ясувалося, що і NTLM вразливий, і фахівці Microsoft підготували NTLMv2, який до цих пір вважається досить надійним, хоча зараз кращий протокол - Kerberos. NTLMv2 як і раніше широко використовується для локальної реєстрації і в деяких інших випадках. NTLMv2 схожий на NTLM, але в хеше пароля NTLMv2 використовується аутентифікація повідомлень HMAC-MD5, а послідовності запит-відповідь присвоюється мітка часу, щоб запобігти атакам, в ході яких зломщик записує облікові дані і згодом їх використовує.

В цілому NTLMv2 більш стійкий до атак із застосуванням «грубої сили», ніж NTLM, так як в протоколі застосовується 128-розрядний ключ шифрування. Відомо тільки про дві програми злому паролів (одна з них - LC5 компанії Symantec), за допомогою яких вдавалося відкрити хеші паролів NTLMv2.

Kerberos

Компанія Microsoft прийняла Kerberos як обраного за замовчуванням протоколу доменної аутентифікації для доменів Windows 2000, а потім і AD. Kerberos - відкритий стандарт, придатний для взаємодії з чужорідними доменами (званими областями - realm - в UNIX і Linux). Кожен DC в доменах AD грає роль сервера розподілу (Kerberos Distribution Server, KDC) і може брати участь в процедурі аутентифікації. Безпека підвищується завдяки таким характеристикам Kerberos:

• взаємна аутентифікація між клієнтом і сервером;
• надійний захист пароля, так як Windows пересилає пароль тільки при початковому зверненні, а не в кожній події аутентифікації і всі сеанси зв'язку шифруються;
• послідовність запит-відповідь з міткою часу не дозволяє зломщикові використовувати перехоплений пароль після певного часу;
• серверний процес може звертатися до віддаленого ресурсу від імені користувача;
• интероперабельность.

Короткий опис роботи Kerberos:

1. Після успішної звичайної аутентифікації комп'ютер користувача запитує квиток безпеки з сервера Kerberos (DC) для майбутніх запитів аутентифікації.
2. Сервер Kerberos видає запитувачів квиток для участі в майбутніх подіях аутентифікації і авторизації без повторного пред'явлення первинних облікових даних аутентифікації.
3. Коли запитувачів потрібно звернутися до ресурсу сервера-учасника, він отримує інший квиток доступу від сервера Kerberos і пред'являє його серверу ресурсу для перевірки.
4. Початкові облікові дані аутентифікації не передаються по мережевим каналам ні в одному з наступних сеансів аутентифікації (до тих пір, поки не закінчиться термін дії квитка, виданого на етапі 2).

Слід звернути увагу, що, хоча принцип роботи Kerberos нагадує інфраструктуру з приватним відкритим ключем (public key infrastructure, PKI), вся інформація захищається з використанням симетричних ключів (на відміну від асиметричних ключів, що застосовуються в більшості служб аутентифікації).

Смарт-карти

Надійність паролів та других методів аутентіфікації на основе одного параметра Швидко зніжується. Електронна комерція пронікає в повсякдення життя и растет як Кількість способів крадіжкі особістом Даних (спам, шахрайство з URL), так и ймовірність зловжівань паролями. Багато фахівців вважають, що аутентифікація з двома параметрами - в формі смарт-карт, USB-пристроїв або інших криптографічних пристроїв - в майбутньому стане звичайним явищем для транзакцій в Internet. Розробники Microsoft вбудовують в свої рішення функції для роботи з цифровими сертифікатами і смарт-картами. Для використання смарт-карт необхідно встановити службу Certificate Services і поширити сертифікати смарт-карт. Звичайно, потрібні також фізичні смарт-карти, пристрої зчитування і програмне забезпечення постачальника. Потім при необхідності користувачі можуть вставляти свої смарт-карти в локальні пристрої читання для доступу до комп'ютера Windows. При грамотному використанні смарт-карти можуть істотно підвищити надійність аутентифікації.

Захист протоколу аутентифікації

У деяких статтях помилково стверджується, що зламати механізм аутентифікації Microsoft як і раніше просто. Насправді з 20 існуючих інструментів злому пароля тільки два працюють з NTLMv2 і лише один - з Kerberos. Але, зробивши кілька простих кроків, можна відвести і цю загрозу. Для запобігання спробам розгадування і скидання пароля потрібно вжити таких заходів (більшість параметрів можна налаштувати локально або за допомогою Group Policy).

• Відключити зберігання LM-хешей, як описано в статті Microsoft "How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases" ( aspx?scid=kb;en-us;299656> http://support.microsoft.com/ default.aspx? scid = kb; en-us; 299656 ). Це робиться для того, щоб перешкодити хакерам відкрити вихідний пароль.
• Вимкнути всі протоколи аутентифікації, крім NTLMv2 і Kerberos (після вичерпного тестування). Процедура описана в статті Microsoft TechNet "Network security: LAN Manager authentication level" ( http://www.microsoft.com/resources/ documentation / windowsserv / 2003 / standard / proddocs / en-us / 576.asp ).
• Заборонити початкове завантаження зі змінних носіїв, щоб запобігти запуск інструментів злому пароля в обхід операційної системи. Заборона початкового завантаження з усіх дисків, крім обраного за замовчуванням, запобігає доступ автономних програм злому пароля до бази даних аутентифікації, де зберігаються хеші паролів.
• Користувачі повинні призначати складні паролі довжиною не менше 8 символів.
• Користувачі повинні змінювати свої паролі принаймні раз в квартал.
• Активізувати блокування облікового запису хоча б на одну хвилину з автоматичним скиданням. Це запобігає розгадування паролів в мережі.

Обов'язки користувачів

Завдяки NTLMv2, Kerberos і смарт-картками Windows має надійними механізмами аутентифікації, стійкими до підслуховування і атакам з застосуванням методу перебору. Але оптимальні процедури і надійні протоколи аутентифікації не допоможуть, якщо користувачі призначають слабкі паролі. Необхідно навчити користувачів правильно вибирати паролі і домогтися, щоб паролі були складними і надійними.

Роджер Граймз - Редактор Windows IT Pro і консультант з проблем безпеки. Має сертифікати CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security і Security +. [email protected]