11.02.2011 Жан де Клерк

Будь-якому адміністратору Windows, зрозуміло, неодноразово доводилося мати справу з двома основними протоколами автентифікації серед Windows: Kerberos і NTLM. Ця стаття присвячена тому, як Kerberos та NTLM підтримуються у системах Windows 7 та Windows Server 2008 R2. Але спочатку я хотів би зупинитися на ключових відмінностях між цими протоколами.

Розробники Microsoft вперше реалізували протокол Kerberos у системі Windows 2000. Протокол NTLM увійшов у вжиток набагато раніше, за часів Windows NT. Kerberos є протоколом аутентифікації, що базується на концепції довіреної третьої сторони trusted third party (TTP), тоді як в основу протоколу NTLM покладено механізм «запит-відповідь» (challenge/response). Докладніше різницю між двома протоколами описані у таблиці .

При обміні даними під час аутентифікації з використанням протоколу NTLM серверний ресурс (наприклад, файл-сервер) генерує запит, який надсилається клієнту. Клієнт формує відповідь NTLM, що включає хеш пароля користувача, а сервер перевіряє правильність цієї відповіді. Якщо клієнт використовує локальний обліковий запис, сервер перевіряє відповідь користувача за допомогою пароля користувача хеша, який зберігається в локальній базі даних диспетчера облікових записів безпеки Security Account Manager (SAM). Якщо клієнт застосовує доменний обліковий запис, сервер передає відповідь для перевірки контролеру домену, бо тільки контролери доменів зберігають у своїх базах даних Active Directory (AD) копії хешей користувацьких паролів.

У Windows Kerberos довіреною третьою стороною є контролер домену Windows 2000 або пізнішої версії, на якому розміщується служба центру розповсюдження ключів Kerberos Key Distribution Center (KDC). Центр KDC полегшує процедуру автентифікації між оснащеним засобами Kerberos клієнтом та сервером. Служба KDC автоматично встановлюється як компонент системи AD і складається з двох підсистем: служби автентифікації Authentication Service (AS) та служби надання квитків Ticket-Granting Service (TGS).

Коли користувач реєструється в домені Windows з використанням протоколу Kerberos, клієнт Windows насамперед перевіряє справжність користувача на контролері домену за допомогою пароля користувача. У той же час, клієнт запитує квиток на видачу квитка Ticket Grant Ticket (TGT) в службу аутентифікації. TGT можна розглядати як тимчасовий пароль (за замовчуванням час його життя становить 8 годин), який замінюватиме пароль користувача в наступних запитах на автентифікацію. Коли користувачеві потрібно буде звернутися до серверного ресурсу, клієнт представить TGT видачу TGT для перевірки справжності на серверному ресурсі. Майте на увазі, що, на відміну від NTLM, протокол Kerberos не використовується для локальної автентифікації диспетчера облікових записів безпеки Windows; його сфера застосування обмежується доменною автентифікацією на контролері домену.

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

Чому Kerberos?

Kerberos ефективніший, ніж NTLM, і тому є кілька причин. При використанні протоколу Kerberos хеш пароля користувача експонується набагато рідше, ніж у разі застосування NTLM. Хеш пароля експонується тільки в тому випадку, коли користувач запитує TGT - по суті, раз кожні вісім годин. З іншого боку, у разі застосування NTLM хеш пароля експонується щоразу, коли клієнт використовує NTLM для автентифікації на сервері. У цьому полягає важлива перевага протоколу Kerberos перед NTLM; річ у тому, що існують спеціальні інструменти, які перевіряють мережевий трафік на наявність хешей паролів. Ці інструменти захоплюють виявлені хеш і методом підбору відновлюють на їх основі паролі користувачів.

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

На додаток до сказаного протокол Kerberos реалізує такі вдосконалені функції автентифікації, як взаємна автентифікація та делегування автентифікації. Взаємна автентифікація означає, що користувач і служба перевіряють справжність один одного, тоді як можливості NTLM обмежуються автентифікацією користувача. Без цієї функції можуть виникати ситуації, коли користувачі надають облікові дані фіктивному серверу.

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

Нарешті, треба сказати, що, хоча фахівці Microsoft виконали велику роботу з модернізації протоколу NTLM, а саме створили версію NTLMv2, яка підтримується в середовищі NT4 SP4 і новіших версіях, у продукті Microsoft Kerberos реалізовано більше сучасних алгоритмів шифрування. Я розповім про це докладніше у розділі, присвяченому засобам шифрування протоколу Kerberos

Обмеження протоколу NTLM

Переваги автентифікації засобами протоколу Kerberos сумніви не викликають. Але навіть у середовищі AD Server 2008 Windows часто використовує протокол NTLM, наприклад, коли ви підключаєтеся до системи Windows, випущеної до появи Windows 2000, або під час підключення до загальнодоступного ресурсу за допомогою команди net use та IP-адреси (а не імені NetBIOS). Крім того, програми, у яких імена учасників служби principal names (SPN) не налаштовані належним чином, будуть як і раніше використовувати протокол NTLM.

Щоб дізнатися, яким протоколом – NTLM або Kerberos – ви користуєтеся в даний момент, можете візуалізувати трафік NTLM за допомогою утиліти netmon або іншого трасувальника мережі; альтернативний варіант - перевірити вміст кешу квитків Kerberos за допомогою інструменту klist (який входить до комплектів постачання Windows 7 та Server 2008). У системах Windows 7 та Server 2008 фахівці Microsoft реалізували нові групові політики, за допомогою яких можна відстежувати, а також блокувати використання протоколу NTLM вашими користувачами та програмами. Усього таких політик три: одна для вхідного трафіку NTLM (для відстеження та блокування на рівні сервера), інша для вихідного трафіку NTLM (для відстеження та блокування на рівні клієнта) та третя для доменного трафіку (для відстеження та блокування на рівні контролера домену). Вони розміщуються в контейнері Security Options Group Policy Object (CPO), потрапити до якого можна, послідовно вибираючи пункти Computer Configuration, Windows Settings, Security Settings, Local Policies (див. екран 1). Усі вони починаються із елемента Network security: Restrict NTLM:.

Кожне налаштування політики має параметри audit та block. Коли ви включаєте функцію аудиту NTLM, програма створює записи журналу подій з вихідними даними NTLM і числами 8001, 8002, 8003 і 8004. Журнальні записи зберігаються в контейнері Operational шляхом доступу Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. Я рекомендую для початку провести аудит NTLM у тестовому середовищі та подбати про те, щоб там були належним чином представлені всі ваші програми. Якщо почати довільно блокувати використання протоколу, швидше за все, деякі програми функціонувати не будуть. Щоб не допустити втрати подій, слід перед початком тестування аудиту NTLM встановити рішення для збору подій аудиту; Ви можете скористатися вбудованою службою Windows Event Collector, Event Subscriptions або рішенням від незалежного постачальника. Крім того, я рекомендую насамперед розпочати моніторинг NTLM на серверах. Ви можете підключити клієнти для детального аналізу, після того як стане очевидно, що сервер використовує протокол NTLM. Усвідомивши, які програми використовують NTLM, ви можете розробити стратегію блокування NTLM. Ця стратегія може включати стратегію винятків для застарілих додатків, які не можуть бути переписані або переналаштовані і які завжди вимагатимуть застосування NTLM.

На жаль, NTLM не можна використовувати на старих системах Windows. Однак, ці системи допускають можливість управління версіями протоколу NTLM. Ви можете, наприклад, відключити фрагмент LM протоколу аутентифікації NTLM (оскільки цей фрагмент слабкий за своєю природою) або задати примусове застосування протоколу NTLMv2. Для цього слід скористатися налаштуванням Network Security: LAN Manager Authentication Level GPO, яка розміщується в контейнері Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO (див. екран 2).

Засоби шифрування Kerberos

Криптографічні протоколи, які використовуються протоколами аутентифікації, відіграють важливу роль у забезпеченні безпеки останніх. Як я вже зазначав, у цій галузі показники Kerberos вищі, ніж у протоколу NTLM. Алгоритм шифрування RC4 був вперше реалізований у протоколі Windows Kerberos у версії Windows 2000 і досі підтримується в системах Server 2008, а також Windows 7 (точніше, підтримується його версія RC4_HMAC_MD5). У системах Server 2008, Windows Vista і новіших версіях розробники Microsoft додали засоби підтримки шифрування за стандартом Advanced Encryption Standard, AES, а системи Windows 7 і Server 2008 R2 підтримують типи шифрування Kerberos AES (AES128_HMAC_SHA1 і AES256_H) AES - новий і потужний алгоритм шифрування, ніж DES. Логіка Kerberos на контролерах доменів перейде до стандарту шифрування AES, коли ви модернізуєте домен AD до рівня Windows 2008 Domain Functional Level (DFL).

У системах Windows 7 та Server 2008 R2 типи шифрування DES для протоколу автентифікації Kerberos за замовчуванням вимкнуто. Через це можуть виникнути проблеми сумісності, якщо одна із застарілих програм жорстко закодована на шифрування лише за стандартом DES або якщо обліковий запис Windows, що виконує ту чи іншу службу (обліковий запис цієї служби), налаштований на використання лише DES-шифрування. Ці служби або програми вийдуть з ладу, якщо ви не зможете переналаштувати відповідну службу або програму на підтримку іншого типу шифрування (RC4 або AES) або не відновіть підтримку стандарту DES.

Щоб з'ясувати, чи є у вас програми або служби, закодовані на шифрування виключно за стандартом DES, можна запустити мережевий трасувальник при старті відповідної програми або служби та перевірити вміст полів Etype у заголовках автентифікації Kerberos. Щоб визначити, чи обліковий запис користувача чи комп'ютера AD чи обліковий запис комп'ютера для використання виключно типів шифрування DES, потрібно перевірити, чи вибрано на вкладці Account властивостей об'єкта параметр Use Kerberos DES encryption types for this account. До цих властивостей можна звернутися з оснастки AD Users and Computers консолі MMC.

Якщо ви виконаєте згадані вище перевірки і виявиться, що у вас виникла ця проблема, можете активувати DES-шифрування для автентифікації за допомогою Kerberos на комп'ютерах, що функціонують під Windows 7 або Server 2008 R2, за допомогою GPO налаштування Network security: настройте типи шифрування, сумісні зі стандартом Kerberos; ці параметри розташовані в контейнері Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO.

Отже, з двох протоколів автентифікації Windows доцільним є протокол Kerberos. Адміністраторам слід завжди наполягати на тому, щоб користувачі та програми застосовували саме Kerberos, а не NTLM. Нові обмеження щодо використання NTLM, реалізовані в системах Windows 7 та Server 2008 R2, відкривають перед нами чудову можливість для досягнення цієї мети.

Жан де Клерк ( [email protected]) – співробітник Security Office компанії HP. Спеціалізується на керуванні ідентифікаційними параметрами та безпекою у продуктах Microsoft

Аутентифікація в системах Windows Server 2008 R2 та Windows 7

В операційній системі Windows 7 реалізовано нове покоління технологій безпеки для робочого столу та одна з них – автентифікація та авторизація. Частина технологій спрямована на зміцнення загальної інфраструктури Windows, а решта на надання допомоги в управлінні системою та даними користувача.

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

Аутентифікація - це процес, який використовується для підтвердження особи користувача, при зверненні його до комп'ютерної системи або додаткових системних ресурсів. У приватних та державних комп'ютерних мережах (включно з Інтернетом) найчастіше для аутентифікації передбачається перевірка облікових даних користувача; тобто, ім'я користувача та пароль. Однак для типів критичних транзакцій, наприклад, обробка платежів, перевірки автентичності імені користувача та пароля не достатньо, оскільки паролі можуть бути вкрадені або зламані. З цієї причини, основна частина інтернет-бізнесу, а також багато інших угод тепер використовують цифрові сертифікати, які видаються та перевіряються центром сертифікації.

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

• Зміни системних ресурсів спочатку дозволені системним адміністратором.
• При спробі користувача отримати доступ або оновити системний ресурс, дозвіл на дію оцінюється системою або програмою.

Останній варіант дозволяє користувачу отримати доступ без автентифікації та авторизації. Він використовується у випадку, коли потрібно надати доступ для анонімних користувачів, що не проходять автентифікацію. Такий доступ, як правило, дуже обмежений.

Процес авторизації та аутентифікації.

Для отримання доступу до файлів у мережі користувачі, щоб перевірити їх особи, повинні проходити автентифікацію. Це робиться під час процесу входу до мережі. Операційна система Windows 7 для входу в мережу має такі методи автентифікації:

• Протокол Kerberos версії 5: Основний метод автентифікації клієнтів та серверів під керуванням операційної системи Microsoft Windows. Він використовується для автентифікації облікових записів користувачів та облікових записів комп'ютерів.
• Windows NT LAN Manager (NTLM): використовується для зворотної сумісності з операційними системами старішими, ніж Windows 2000 та деяких програм. Він менш гнучкий, ефективний та безпечний, ніж протокол Kerberos версії 5.
• Зіставлення сертифікатів: зазвичай використовується для автентифікації при вході в поєднанні зі смарт-карткою. Сертифікат, записаний на смарт-карті, пов'язаний із обліковим записом користувача. Для читання смарт-карток та аутентифікації користувача використовується зчитувач смарт-карток.

Нові функції автентифікації у Windows 7.

Ціла низка покращень, пов'язаних з процесами входу та перевірки автентичності користувача була додана ще у Windows Vista ®. Ці вдосконалення збільшили базовий набір функції автентифікації, щоб допомогти забезпечити кращу безпеку та керованість. У Windows 7 Microsoft продовжує розпочаті у Windows Vista удосконалення, надаючи наступні нові функції автентифікації:

• Смарт-картки
• Біометрія
• Інтеграція особистості Інтернет.

Смарт-карти.

Використання смарт-карт найпоширеніший метод аутентифікації. Для заохочення використання організаціями та користувачами смарт-карт, Windows 7 пропонує нові можливості, що полегшують їх використання та розгортання. Ці нові можливості дозволяють використовувати смарт-картки для виконання різноманітних завдань, включаючи:

• Смарт-карти Plug and Play
• Особисті посвідчення перевірки (PIV), стандарт Національного інституту стандартів та технологій США (NIST)
• Підтримка для входу смарт-картки Kerberos.
• Шифрування дисків BitLocker
• Документи та електронна пошта
• Використання з бізнес-додатками.

Біометрія.

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

До цього часу Windows не було стандартної підтримки біометричних пристроїв. Для вирішення цієї проблеми Windows 7 вводить Windows Biometric Framework (WBF). WBF надає новий набір компонентів, що підтримує зняття відбитка пальця за допомогою біометричного пристрою. Ці компоненти підвищують безпеку користувачів.

Windows Biometric Framework спрощує користувачам та адміністраторам налаштування та керування біометричними пристроями на локальному комп'ютері або в домені.

Інтеграція особистості Інтернет.

Управління обліковим записом - стратегія забезпечення безпеки. Для дозволу або заборони автентифікації певних комп'ютерів або всіх комп'ютерів, якими ви керуєте онлайн, використовується Групова політика.

Інтеграцією онлайн ідентифікації можна керувати політикою групи. Політика, налаштована як: “Мережева безпека: Дозволити цьому комп'ютеру за запитом ідентифікації PKU2U використовувати ID онлайн”, керує можливістю ID онлайн підтвердити справжність цього комп'ютера за допомогою протоколу PKU2U. Цей параметр політики не впливає на здатність облікових записів доменів або локальних облікових записів користувачів на комп'ютері.

Windows NT питання/відповідь. При інтегрованій аутентифікації Windows браузер клієнта перевіряє сам себе на сервері у вигляді криптографічного обміну даними.

Інтегрована автентифікація Windows підтримує як протокол Kerberos v5, так і протокол NTLM (NT LAN Manager) для автентифікації за допомогою пакета Negotiate. За наявності Active Directory та відповідної підтримки браузером (IE 5 або вище на платформі Windows 2000) використовується протокол Kerberos, інакше протокол NTLM . Як Kerberos, і NTLM мають деякі обмеження. Цікавим є той факт, що переваги одного відповідають слабким місцям іншого. Kerberos, зазвичай, працює з проксі-серверами, але з міжмережевими екранами його функціонування менш ефективно. NTLM зазвичай працює через міжмережевих екранах, але досить посередньо взаємодіє з проксі-серверами.

Декілька слів про Microsoft Negotiate

Microsoft Negotiate є пакетом, що обслуговує інтерфейс між різними постачальниками послуг з безпеки. Він може здійснювати вибір між різними пакетами автентифікації. IIS використовує пакет Negotiate для аутентифікації і в цьому випадку відбувається вибір протоколу Kerberos або протоколу NTLM . До цього пакету також додано підтримку майбутніх автентифікаційних пакетів, що є перевагою Negotiate. За умовчанням Negotiate вибирає Kerberos як найбезпечніший протокол. Якщо протокол Kerberos з якоїсь причини недоступний, Negotiate повертається до використання NTLM .

Аутентифікація NTLM

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

NTLM функціонує в такий спосіб.

1. Користувач вказує ім'я користувача, пароль та ім'я домену під час входу на комп'ютер-клієнт.
2. Клієнт створює хеш даного пароля та видаляє оригінал.
3. Клієнт відправляє серверу ім'я користувача у відкритому вигляді.
4. Сервер надсилає клієнту 16-бітовий фрагмент випадкових даних.
5. Клієнт шифрує цей фрагмент, а також хеш пароля користувача та передає їх на сервер.
6. Сервер передає ім'я користувача, випадковий фрагмент даних та відповідь клієнта на контролер домену.
7. Контролер домену шифрує відрізок випадкових даних разом зі своїм власним хеш пароля користувача, після чого порівнює їх з елементами, надісланими сервером.
8. Якщо значення збігаються, контролер домену повідомляє сервер про успішне завершення автентифікації.
9. Якщо значення або ім'я користувача не збігаються, контролер домену повідомляє про це сервер, який надсилає клієнту відповідне повідомлення. Після цього браузер клієнта запитує користувача автентифікаційні дані.

Автентифікація Kerberos

У давньогрецькій міфології Керберос – це казковий триголовий собака, який охороняв підземний світ від людей. В даний час терміном Kerberos називається протокол безпечної автентифікації для доступу до ресурсів. Kerberos ґрунтується на автентифікації із секретним ключем, при якій клієнт та сервер використовують один і той же ключ для шифрування та розшифровки. Клієнт доводить знання ключа за допомогою шифрування повідомлення, а сервер доводить знання ключа за допомогою розшифрування повідомлення. Потім сервер бере частину повідомлення, шифрує її та відправляє клієнту. При збереженні цілісності повідомлення результат автентифікації буде позитивним.

Робота Kerberos ґрунтується на центральному сервері, званому Key Distribution Center ( KDC ) ( Центр розподілу ключів), що надає всі необхідні ключі. KDC випускає так звані квитки TGT ( "Квитки для отримання квитків") і надає їх клієнтам, що запитують доступ до ресурсу на сервері.

Нижче наведено процес отримання клієнтом початкового квитка TGT.

1. Користувач здійснює вхід на комп'ютер-клієнт із зазначенням імені користувача та пароля.
2. Клієнт шифрує пароль та зберігає його.
3. Клієнт відправляє KDC повідомлення із запитом на автентифікаційні дані для служби TGT, а також зашифрований пароль користувача.
4. KDC порівнює зашифрований пароль зі своєю еталонною копією для перевірки їхньої ідентичності. Також здійснюється перевірка тимчасового штампу, що додається клієнтом до запиту, для підтвердження того, що вказаний у штампі час знаходиться в межах п'яти хвилин власного часу KDC.
5. У разі повної відповідності KDC створює запитані автентифікаційні данідля служби TGT за допомогою генерації сеансового ключавходу і шифрування його на ключі користувача.
6. KDC створює інший фрагмент автентифікаційних данихза допомогою шифрування сеансового ключавходу та TGT користувача своїм власним еталонним ключем.
7. KDC надсилає обидва фрагменти автентифікаційних данихклієнту.
8. Клієнт розшифровує сеансовий ключ входу з першого відрізка автентифікаційних данихза допомогою зашифрованого пароля та зберігає цей сеансовий ключ входу до кешу свого квитка.
9. Клієнт також зберігає TGT у своєму кеші квитка.

Тепер клієнт має TGT, і він може використовувати його для отримання квитків на доступ до ресурсів. Ось як це відбувається.

1. Клієнт запитує KDC квиток на доступ до ресурсів на сервері. Клієнт надає свій TGT центру KDC разом із ім'ям потрібного ресурсу та автентифікаційним повідомленням, зашифрованим на сеансовому ключі входу.

Аутентифікація – це незамінна процедура для кожного користувача, комп'ютера та службового облікового запису 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]. При використанні смарт-карток суб'єкт безпеки може надати свій цифровий сертифікат або ключ.

Аутентифікація або автентифікація.Після того, як суб'єкт безпеки вводить з клавіатури або в інший спосіб надає необхідну для ідентифікації інформацію (наприклад, ім'я користувача, маркер безпеки), він повинен ввести з клавіатури або надати приватну інформацію для аутентифікації (наприклад, пароль та 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) уразливі у разі прослуховування та атак з розгадуванням пароля.

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-пристроїв чи інших криптографічних пристроїв – у майбутньому стане звичайним явищем для транзакцій до Інтернету. Розробники 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" ( http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Це робиться для того, щоб завадити хакерам відкрити вихідний пароль.
• Вимкнути всі протоколи автентифікації, крім NTLMv2 та Kerberos (після вичерпного тестування). Процедуру описано у статті Microsoft TechNet "Network security: LAN Manager authentication level" ().
• Заборонити початкове завантаження зі змінних носіїв, щоб запобігти запуску інструментів злому пароля в обхід операційної системи. Заборона початкового завантаження з усіх дисків, окрім обраного за умовчанням, запобігає доступу автономних програм злому пароля до бази даних автентифікації, де зберігаються хеші паролів.
• Користувачі повинні призначати складні паролі завдовжки не менше 8 символів.
• Користувачі повинні змінювати свої паролі щонайменше раз на квартал.
• Активізувати блокування облікового запису хоча б на одну хвилину з автоматичним скиданням. Це запобігає розгадуванню паролів у мережі.

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

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

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

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

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

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

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

Щоб простіше уявити цей процес проведемо просту аналогію. Ви за кордоном і вас зупиняє поліцейський, ви пред'являєте свій паспорт. Поліцейський перевіряє дані у паспорті та звіряє фотографію – це процес аутентифікації. Переконавшись, що це ви, поліцейський просить показати візу - це процес авторизації, тобто. вашого права тут перебувати.

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

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

Локальна автентифікація

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

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

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

У разі входу користувача до домену, для аутентифікації використовуються інші механізми, перш за все протокол Kerberos, проте, якщо одна із сторін не може його використовувати, за погодженням можуть бути використані протоколи NTLM і навіть застарілий LM. Роботу цих протоколів ми розглядатимемо нижче.

LAN Manager (LM)

Протокол LAN Manager виник на зорі зародження локальних мереж під керуванням Windows і вперше був представлений в Windows 3.11 для робочих груп, звідки перекочував до сімейства Windows 9.х. Ми не розглядатимемо цей протокол, оскільки в природному середовищі він уже давно не зустрічається, проте його підтримка, з метою сумісності, є досі. І якщо сучасній системі надійде запит на автентифікацію за протоколом LM, то за наявності відповідних дозволів він буде оброблений.

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

• Пароль реєстронезалежний і наводиться до верхнього регістру.
• Довжина пароля - 14 символів, коротші паролі доповнюються при створенні хеша нулями.
• Пароль ділиться навпіл і кожної частини створюється свій хеш за алгоритмом DES.

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

А тепер найцікавіше, LM-хеш, з метою сумісності, створюється при введенні пароля і зберігається в системах Windows XP включно. Це уможливлює атаку, коли системі цілеспрямовано надсилають LM-запит і вона його обробляє. Уникнути створення LM-хеш можна змінивши політику безпеки або використовуючи паролі довше 14 символів. У системах, починаючи з Windows Vista та Server 2008, LM-хеш за замовчуванням не створюється.

NT LAN Manager (NTLM)

Новий протокол автентифікації з'явився в Windows NT і, з деякими змінами, дожив до наших днів. До появи Kerberos в Windows 2000 був єдиним протоколом аутентифікації в домені NT.

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

Принцип роботи NTLM має багато спільного з LM і ці протоколи обернено сумісні, але є і суттєві відмінності. NT-хеш формується на основі пароля довжиною до 128 символів за алгоритмом MD4, пароль реєстрозалежний і може містити не тільки ACSII символи, але і Unicode, що суттєво підвищує його стійкість порівняно з LM.

Як відбувається робота з протоколом NTLM? Розглянемо таку схему:

Допустимо локальний комп'ютер хоче отримати доступ до деякого файлового ресурсу на іншому ПК, який ми вважатимемо сервером, при цьому зовсім не обов'язково наявність на цьому ПК північної ОС чи серверних ролей. З погляду протоколу NTLM клієнт це той, хто звертається, сервер – до кого звертаються.

Щоб отримати доступ до ресурсу, клієнт надсилає серверу запит з ім'ям користувача. У відповідь сервер передає йому випадкове число, яке називається запит сервера. Клієнт у свою чергу шифрує даний запит за алгоритмом DES, використовуючи як ключ NT-хеш пароля, однак, незважаючи на те, що NT-хеш 128-бітний, в силу технічних обмежень використовується 40 або 56 бітний ключ (хеш ділиться на три частини кожна частина шифрує запит сервера окремо).

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

У разі доменної аутентифікації процес протікає трохи інакше. На відміну від локальних користувачів, хеші паролів яких зберігаються в локальних базах SAM, хеші паролів доменних користувачів зберігаються на контролерах доменів. При вході в систему LSA надсилає доступному контролеру домену запит із зазначенням імені користувача та імені домену і подальший процес відбувається як показано вище.

У разі отримання доступу до третіх ресурсів схема також змінюється:

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

Як бачимо, хеш пароля за жодних обставин через мережу не передається. Хеш введеного пароля зберігає служба LSA, хеш паролів користувачів зберігаються або в локальних сховищах SAM, або в сховищах контролера домену.

Але незважаючи на це, протокол NTLM на сьогоднішній день вважатися захищеним не може. Слабке шифрування уможливлює досить швидко відновити хеш пароля, а якщо використовувався не тільки NTLM, а ще й LM-відповідь, то й відновити пароль.

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

NTLMv2

Усвідомлюючи, що протокол NTLM не відповідає сучасним вимогам безпеки, з виходом Windows 2000 Microsoft представила другу версію протоколу NTLMv2, який був серйозно доопрацьований щодо поліпшень криптографічної стійкості та протидії поширеним типам атак. Починаючи з Windows 7/Server 2008 R2, використання протоколів NTLM і LM за замовчуванням вимкнено.

Відразу розглянемо схему з контролером домену, у разі його відсутності схема взаємодії не змінюється, лише обчислення, що виробляються контролером домену, виконуються безпосередньо на сервері.

Як і в NTLM, клієнт при зверненні до сервера повідомляє йому ім'я користувача та доменне ім'я, у відповідь сервер передає йому випадкове число - запит сервера. У відповідь клієнт генерує випадкове число, куди, крім іншого, додається мітка часу, яке називається запит клієнта. Наявність мітки часу дозволяє уникнути ситуації, коли атакуючий спочатку накопичує перехоплені дані, та був з допомогою здійснює атаку.

Запит сервера поєднується із запитом клієнта і від цієї послідовності обчислюється HMAC-MD5 хеш. Після цього від цього хеш береться ще один HMAC-MD5 хеш, ключем в якому виступає NT-хеш пароля користувача. Результат, що вийшов, називається NTLMv2-відповіддю і разом із запитом клієнта пересилається серверу.

Криптостійкість даного алгоритму є актуальною і на сьогоднішній день, відомо лише два випадки злому даного хеша, один із них вироблений компанією Symantec у дослідницьких цілях. Можна з упевненістю сказати, що зараз немає масових інструментів для атак на NTLMv2, на відміну від NTLM, зламати який може будь-який школяр, який вдумливо прочитав інструкцію.

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

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

налаштування безпеки

Тепер, коли ви маєте уявлення про роботу протоколів автентифікації, саме час поговорити про налаштування безпеки. NTLMv2 цілком безпечний протокол, але якщо система налаштована неправильно, то зловмисник може надіслати NTLM або LM запит і отримати відповідну відповідь, яка дозволить успішно здійснити атаку.

За вибір протоколу автентифікації відповідає локальна чи групова політика. Відкриємо редактор політик і перейдемо в Конфігурація комп'ютера - Конфігурація Windows - Політики безпеки - Локальні політики - Параметри безпеки, в цьому розділі знайдемо політику Безпека мережі: рівень автентифікації LAN Manager.

У цьому розділі перебуває політика Безпека мережі: не зберігати хеш-значення LAN Manager при наступній зміні пароля, яка забороняє створення LM-хешу, за замовчуванням активна починаючи з Vista/Server 2008.

У нашій політиці ми бачимо широкий вибір значень, очевидно, що сьогодні безпечними можуть вважатися політики починаючи з і нижче за списком.

Ці значення можна задати через реєстр, що зручно в мережах рівня робочої групи, для цього в розділі HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsaпотрібно створити параметр DWORDз ім'ям LmCompatibilityLevel, який може набувати значень від 0 до 5. Розглянемо їх докладніше:

Найменування налаштування	Клієнтський комп'ютер	Контролер домену	Lm Compatibility Level
Надсилати LM- та NTLM-відповіді	Клієнтські комп'ютери використовують автентифікацію LM і NTLM і ніколи не використовують сеансову безпеку NTLMv2.		0
Надсилати LM- та NTLM- використовувати сеансову безпеку NTLMv2	Клієнтські комп'ютери використовують автентифікацію LM і NTLM, і використовують сеансову безпеку NTLMv2, якщо сервер підтримує її.	Контролери домену допускають автентифікацію LM, NTLM і NTLMv2.	1
Надсилати тільки NTLM-відповідь	Клієнтські комп'ютери використовують автентифікацію NTLMv1 і використовують сеансову безпеку NTLMv2, якщо сервер підтримує її.	Контролери домену допускають автентифікацію LM, NTLM і NTLMv2.	2
Надсилати тільки NTLMv2-відповідь		Контролери домену допускають автентифікацію LM, NTLM і NTLMv2.	3
Надсилати тільки NTLMv2-відповідь. Відмовляти LM.	Клієнтські комп'ютери використовують автентифікацію NTLMv2 і використовують сеансову безпеку NTLMv2, якщо сервер підтримує її.	Контролери домену відмовляються приймати аутентифікацію LM, і прийматимуть лише NTLM і NTLMv2.	4
Надсилати тільки NTLMv2-відповідь. Відмовляти LM та NTLM.	Клієнтські комп'ютери використовують автентифікацію NTLMv2 і використовують сеансову безпеку NTLMv2, якщо сервер підтримує її.	Контролери домену відмовляються приймати аутентифікацію LM та NTLM, і прийматимуть лише NTLMv2.	5

Уважний читач, вивчаючи цю таблицю, обов'язково зверне увагу на сеансову безпеку NTLMv2. Дана можливість, як і взагалі вся взаємодія по NTLMv2, досить погано документована, тому багато хто розуміє сенс цієї можливості неправильно. Але насправді все досить просто.

Після того, як клієнт пройде аутентифікацію, формується ключ сеансу, який використовується для підтвердження справжності при подальшій взаємодії. Ключ сеансу NTLM заснований тільки на NT-хеш і буде однаковим до тих пір, поки клієнт не змінить пароль користувача. Які загрози безпеці це пояснює, нам здається, не треба. Сеансова безпека NTLMv2 має на увазі обчислення ключа сеансу з використанням не тільки NT-хешу, але й запитів сервера та клієнта, що робить ключ унікальним та набагато стійкішим до можливих атак. При цьому дана можливість може бути використана спільно з аутентифікацією NTLM або LM.

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