Путешествие на ракете Kerberos Билетики, пожалуйста… Станкевич Александр

2 Kerberos Что это? Active Directory использует Kerberos, когда может Отличается от LM/NTLM/NTLMv2, основан на стандартах RFC 1510 и других Имеет собственный словарь терминов: клиент, сервис, пре-аутентификатор, аутентификатор, учётные данные, ключ сессии, билет, Ticket Granting Ticket, Service Ticket, Key Distribution Center, Authentication Service, Ticket Granting Service

3 Kerberos Вид из космоса Упрощённо, это службы, работающие на контроллере домена Понимает две вещи (Principals): пользователи и сервисы (такие как файловые службы на сервере) Когда пользователь хочет получить сервис, он запрашивает билет на этот сервис Затем, пользователь предъявляет сервису этот билет, когда хочет им воспользоваться

4 Головы Kerberos Kerberos имеет три головы Клиенты или User Principals: учётные записи пользователей; каждая имеет свой пароль и имя – UPN Сервисы или Service Principals: нечто к чему мы хотим получить доступ; это может быть просто сервер или его отдельный сервис (файлы/печать, SQL, Exchange); каждый сервис имеет своё имя – SPN и пароль Key Distribution Center (KDC) – контроллер домена, сервер, который знает все пароли пользователей и сервисов. Имеет собственный пароль, известный только ему самому (учётная запись krbtgt) и другим контроллерам в домене. Отложим пароли на некоторое время в сторону; а сейчас…

5 Kerberos в картинках Встречайте наши головы… Том… KDC хочет чтоб контроллер домена… TOMSPC впустил его на рабочую станцию и… PS на принт-сервер

6 Kerberos в картинках Для выполнения этого… Тому необходимо что-то, что даст ему право общаться с этими серверами содерж имое Это что-то называется билет (Ticket); они бывают двух видов KDC контроллер домена создаёт оба типа билетов содерж имое ST-PS Service Ticket даёт Тому доступ к сервису, такому как служба Workstation на TOMSPC, или служба печати на PS содерж имое ST-TWS содерж имое TGT Ticket Granting Ticket даёт Тому право просить контроллер выдать ему Service Ticket

7 Kerberos Два вида билетов, две службы Вначале, мы представляем себя KDC, входя в систему; чтоб выполнять вход только один раз, мы просим KDC предоставить билет на KDC… и это Ticket Granting Ticket Он предоставляется частью KDC, которая называется Authentication Service или AS Получив TGT, мы можем предъявить его KDC и сказать: Помнишь меня? Теперь мне нужен Service Ticket к такому-то сервису… Service ticket выдаёт другая часть KDC, которая называется Ticket Granting Service или TGS

8 Как это размещается в DC? Key Distribution Center = Authentication Service + Ticket Granting Service KDC = AS + TGS KDC, AS, TGS – всего лишь часть ролей, которые выполняет контроллер Тем не менее, мы не можем увидеть AS, TGS и другие службы в Task Manager; они выполняются внутри процесса LSASS KDC AS TGS

9 Kerberos Почему два вида билетов? Ticket Granting Ticket как и Service Ticket аутентифицирует нас сервису Но обычно, всё заканчивается всего одним TGT и множеством ST Причина наличия двух видов билетов: Kerberos защищает каждый билет, шифруя часть его данных с помощью пароля или ключа

10 Kerberos Ключевые причины почему Kerberos лучше Множество билетов подразумевает множество шифрования информации с помощью нашего пароля – это значит, что злоумышленник будет иметь множество данных для вычисления пароля Итак – и это очень важный момент – то, что предоставляет Kerberos в TGT, по сути дела, является паролем на день Информация, относящаяся к Service ticket, шифруется с помощью этого дневного пароля; только относящаяся к TGT информация шифруется с помощью вашего пароля – одна транзакция в день!

11 Kerberos в картинках Сперва, Тому нужен Ticket Granting Ticket KDC AS TGS (И на сколько же близко должно быть это близко, которое проверяется AS? Это настраиваемое значение, но по умолчанию оно составляет 5 минут.) Том запрашивает TGT у AS и доказывает, что он Том, шифруя дату и время YYYYMMDDHHMMSSZ, используя свой пароль, в качестве ключа шифрования содерж имое TGT AS расшифровывает штамп времени, используя пароль Тома, и проверяет близко ли оно к текущему времени; если близко, AS выдаёт Тому TGT

12 К слову о Vista и выше Если взглянуть на сетевой трафик, когда Vista пытается выполнить вход, мы увидим, что запрос TGT в первый раз всегда завершается неудачно. Vista сознательно отправляет плохой пакет, чтобы определить возможность использования AES вместо RC4-HMAC – возвращаемое сообщение об ошибке KDC_ERR_PREAUTH_REQUIRED содержит в себе список возможных алгоритмов

13 Итак… Том нажал Ctrl + Alt + Del, ввёл свои имя и пароль и получил TGT Но он всё ещё не вошёл на свой компьютер Ему нужен доступ к его рабочей станции Он получит его с помощью Service Ticket Итак, это следующая вещь, которую ему нужно попросить у Ticket Granting Service

14 Kerberos в картинках Далее, Том получает Service Ticket KDC AS TGS Том предъявляет TGS свой TGT и запрашивает ST на свою рабочую станцию содерж имое TGT TGS проверяет TGT и создаёт Service Ticket, идентифицирующий Тома службе Workstation, компьютера TOMSPC; затем, Том предъявляет этот билет TOMSPC содерж имое ST-TWS Теперь Том вошёл на свою рабочую станцию! TOMSPC Это идентифицирует – аутентифицирует Тома на TOMSPC; затем, TOMSPC смотрит на личный и групповые SIDы и, если есть соответствующее разрешение, Тому разрешается вход.

15 Итак… Том вошёл на свою рабочую станцию Он получил TGT, который использует для запроса Service Ticket у Ticket Granting Service Он получил Service Ticket к своей рабочей станции Эти билеты, на самом деле, всего лишь данные в памяти компьютера TOMSPC Том может посмотреть их с помощью kerbtray или klist, входящих в Resource Kit klist теперь встроена в 2008

16 Вывод утилиты klist C:\>klist tickets Cached Tickets: (2) Server: KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 5/11/ :10:08 Renew Time: 5/18/ :10:08 Server: KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 5/11/ :10:08 Renew Time: 5/18/ :10:08

17 На принт-сервер… Точно таким же образом, Том может получить билет к службе печати на PS (в klist это отображается, как cifs/ps.stanky.ru…) Он предъявляет TGS свой TGT Контроллер проверяет TGT и выдаёт Тому Service Ticket, идентифицирующий его на PS Теперь у Тома три билета

18 Том и его билеты TOMSPC PS содерж имое ST-PS содерж имое ST-TWS содерж имое TGT KDC AS TGS

19 Звучит хорошо, но безопасно ли? Время погрузиться в детали Всё это звучит хорошо… Но как мы это обезопасим? Почему злоумышленник не может перехватить билеты, которые говорятПривет служба печати PS, я Том? Ключ – это хорошо… Ключи – это следующая часть нашего Марлезонского балета

20 Безопасная идентификация Мы хотим иметь возможность идентифицировать друг-друга через небезопасную сеть; мы можем сделать это, если: Договоримся об алгоритме шифрования Договоримся о секретном ключе Договоримся о данных для коммуникации Например: я говорю, что вы можете узнать меня по приветственному сообщению, которое вы расшифровываете DESом и 56-ти битным ключом, который знаем только я и вы, и если оно гласитТекущее время X, тогда я, действительно, могу безопасно идентифицировать себя перед вами, скажем, через интернет

21 Kerberos и AD… Мы договариваемся: Алгоритм шифрования: RC4-HMAC Общий секретный ключ: мы позволяем KDC создать произвольный 128-ми разрядный ключ и передать его только нам Данные распознавания: блок данных, называемыйаутентификатор Когда аутентификатор расшифрован, он должен доказывать другой стороне, что мы знаем общий секретный ключ *Server 2008 позволяет использовать AES (ура)!

22 Общие ключи так же полезны… Однажды получив общий ключ, который больше ни кто не знает, клиент и сервер могут выполнять другие вещи, помимо аутентификации, такие как: Подписывание SMB Безопасные (шифрованные) сессии Обмен ключами IPsec для AH или ESP (подписывание или шифрование) Любые другие формы подписывания или шифрования

23 Ещё одно требование к ключам Было бы замечательно, если б ключ, который мы используем, не был одним и тем же, каждый раз Вместо этого, при необходимости поговорить, было бы лучше, если б мы каким-то образом договорились о ключе, который бы действовал всего несколько часов и мы бы никогда больше его не использовали – ключ для сессии Такой ключ называется ключом сессии (Session Key)

24 Предназначение Kerberos Как получить ключ без его перехвата? Мы договорились о содержимом аутентификатора, который мы шифруем, используя согласованный алгоритм Всё, что нам нужно: Сервер, генерирующий произвольные ключи сессий, которые используются всего несколько часов Метод, позволяющий передать вам и мне эти ключи без перехвата Это и делает Kerberos. Периодически.

25 Выдача ключей – часть I: Ключ сессии в Ticket Granting Ticket Помните билеты – сперва TGT, потом Service Ticket? Теперь рассмотрим часть ключей Когда Том просит TGT у AS, он, в действительности, просит две вещи: TGT, который он предъявляет TGS, когда ему нужен Service Ticket и Специальный ключ сессии только на сегодня, известный только Тому и KDC Вот как это работает (уже подробней, но всё ещё немного упрощённо)

26 Поехали… KDC AS TGS Сейчас 12:10, 11 Мая 2010 Хэш пароля Тома Том создаёт штамп времени Затем он отправляет пре-аутентификатор на AS Шифрует используя NT hash, хэш MD4 Unicode-версии его пароля

27 AS создаёт ключ сессии Затем, AS делает копию этого ключа Tom-KDC KDC AS TGS Сейчас 12:10, 11 Мая 2010 Хэш пароля Тома AS расшифровывает временной штамп, используя хэш пароля Тома; время находится в пределах пяти минут от текущего, поэтому AS верит, что это Том. AS генерирует полностью новый ключ сессии Tom-KDC TGT Секретный ключ KDCШифрует один из ключей (и некоторую иную информацию, которую мы увидим позже), используя секретный ключ KDC, создаёт TGT Хэш пароля Тома Шифрует другую копию ключа, используя хэш пароля Тома Отправляет результаты Тому

28 Том получает TGT и ключ сессии Хэш пароля Тома Tom-KDC TGT Секретный ключ KDC KDC AS TGS Том не может расшифровать TGT, но он может расшифровать копию сегодняшнего ключа сессии Tom-KDC Теперь только Том и KDC имеют копии ключа Tom-KDC, и ни кто не прослушал их общение.

29 Чего мы этим достигли? Во-первых – получили общий ключ сессии (на сегодня) между KDC и Томом Во-вторых – получили структуру данных (TGT), которую может расшифровать только KDC Так как только KDC мог создать TGT, и TGT содержитсегодняшний ключ Tom-KDC, Том может предъявить TGT всякий раз, когда захочет напомнить KDC, что они уже общались И для KDC НЕТ необходимости запоминать, что Том сегодня уже аутентифицировался

30 Выдача ключей – часть II: Получение Service Ticket на рабочую станцию Далее, вспоминаем, что Тому нужен Service Ticket на его рабочую станцию, поэтому, он предъявляет TGT на Ticket Granting Service Но как TGS может убедиться в том, что кто-нибудь не перехватил TGT Тома и не отправил его на TGS? Это достигается с помощью аутентификатора (Authenticator) – структуры данных, содержащей в себе, среди прочих вещей, штамп времени, зашифрованный ключом Tom-KDC

31 Том запрашивает ST KDC AS TGS Сейчас 12:10, 11 Мая 2010 Снова, Том создаёт штамп времени Затем, он отправляет свой запрос (Тому нужен ST на TOMSPC), Authenticator (это больше, чем просо штамп, но нам этого достаточно) и копию TGT на TGS, НЕ на AS Но на этот раз, он шифрует его, используя ключ сессии Tom-KDC, который он получил от AS ранее, а не свой NT hash TGT Секретный ключ KDC Tom-KDC Tom-KDC SK Tom-KDC

32 TGS проверяет запрос Тома KDC AS TGS TGT Секретный ключ KDC Tom-KDC Сейчас 12:10, 11 Мая 2010 Tom-KDC SK KDC не помнит разговаривал ли он когда-либо с Томом раньше, но распознаёт TGT, который он выдал. Так как TGT зашифрован, используя пароль известный KDC (учётная запись krbtgt), он может расшифровать TGT и получить ключ сессии Tom-KDC. С помощью полученного ключа сессии Tom-KDC, KDC может расшифровать аутентификатор и извлечь из него штамп времени. Если штамп достаточно близок ко времени KDC, то TGS понимает, что это, действительно, Том просит Service Ticket на TOMSPC.

33 TGS создаёт ST для TOMSPC Service Ticket:Tom toTOMSPC Хэш пароля TPC KDC AS TGS TGT Секретный ключ KDC Tom-KDC TPC-Tom Tom-KDC SK TPC-Tom Затем, TGS генерирует новый ключ сессии TPC-Tom, который Том и его рабочая станция TOMSPC (для краткости TPC) могут использовать сегодня Как и прежде, делается копия этого ключа Затем, TGS создаёт ST, содержащий ключ сессии TPC-Tom (и другие вещи) и шифрует его, используя пароль компьютера TPC TGS шифрует другую копию ключа, используя пароль на сегодня Tom-KDC TGS доставляет билет и новый ключ сессии Тому и забывает ключ Tom-KDC Tom-KDC

34 Том получает новый ключ KDC AS TGS TGT Секретный ключ KDC Tom-KDC Service Ticket:Tom toTOMSPC Хэш пароля TPC TPC-Tom Tom-KDC SK TPC-Tom Том видит новый билет на TOMSPC, но внутрь него заглянуть не может, так как не знает пароля компьютера. Tom-KDC Но он знает пароль Tom-KDC, поэтому, он может расшифровать новый ключ сессии TPC-Tom, который можно использовать для общения со службой Workstation на компьютере TPC. Теперь всё готов для входа на рабочую станцию.

35 Том аутентифицируется на TOMSPC TGT Секретный ключ KDC Tom-KDC Service Ticket:Tom toTOMSPC Хэш пароля TPC TPC-Tom Tom-KDC TOMSPC Сейчас 12:10, 11 Мая 2010 Том создаёт штамп времени Как и прежде, он шифрует его, чтобы доказать, что он является законным владельцем Service Ticket, который предъявляет, но на этот раз он шифрует его новым ключом TPC-Tom TPC-Tom SK Он отправляет аутентификатор, Service Ticket и запрос Эй, ты не хочешь впустить Тома? на службу Workstation компьютера TOMSPC

36 Том вошёл в систему Так же, как AS и TGS, служба Workstation на TOMSPC открывает билет, так как он зашифрован личным паролем TOMSPC TOMSPC находит внутри ключ TPC-Tom, который использует, чтобы открыть аутентификатор Затем, TOMSPC проверяет штамп времени, видит что он в порядке И Том снова аутентифицирован, но не авторизован… но авторизация – не работа Kerberos

37 Приехали Вход на PS – та же самая история Ещё один момент о билетах – помните аутентификатор? Он доказывает сервису, что пользователь, в самом деле, тот за кого себя выдаёт В Kerberos, мы можем дополнительно попросить сервис отправить обратно наш штамп времени, зашифрованный ключом сессии – это взаимная аутентификация (Mutual Authentication)

38 Итак… Работа Kerberos – создавать произвольные пароли, которые используются как ключи сессии, чтобы аутентифицировать, не авторизовывать, пользователей и службы Эти ключи предоставляются пользователям в форме билетов Пользователи доказывают, что они являются законными владельцами билетов, используя аутентификаторы Kerberos работает только в AD; современные системы до сих пор используют LM, NTLM или NTLMv2 для аутентификации

39 Дополнительные материалы How the Kerberos V5 Authentication Protocol Works us/library/cc772815(WS.10).aspx Блог команды Ask the Directory Services lt.aspx IIS and Kerberos от Ken Schaefer

40 Спасибо! Надеюсь, это было полезно и интересно

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.