Расшифровка кода ошибки GetLastError на русском языке и ошибки протокола kdc при использовании смарт-карты для входа в систему

Обновлено 25. 2019

Обновлено 03. 2017

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Причины ошибки шифрования CredSSP

К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.

Уязвимость в протоколе Credential Security Support Provider (CredSSP — провайдер поддержки безопасности учетных данных) допускала удаленный запуск произвольного кода на уязвимой системе и 8 мая 2018 г. Microsoft изменила уровень безопасности подключения с Vulnerable на Mitigated и начались проблемы подключения к удаленному рабочему столу по RDP. Ранее вы могли удаленно подключаться с обновленной машины к машинам без обновления безопасности, так сказать в мягком режиме. Однако с последним обновлением, Microsoft усилила безопасность, и вы больше не можете подключаться к компьютерам без обновления закрывающего брешь CVE-2018–0886.

Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8. 1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.

DNS server IP address: 217. 30   Returned Response Code (RCODE): 4   Returned Status Code: 9004

If this DNS server does not have any DS-integrated peers, then this error   should be ignored.

If this DNS server’s Active Directory replication partners do not have the correct IP address(es) for this server, they will be unable to replicate with it.

To ensure proper replication:   1) Find this server’s Active Directory replication partners that run the DNS server. 2) Open DnsManager and connect in turn to each of the replication partners. 3) On each server, check the host (A record) registration for THIS server. 4) Delete any A records that do NOT correspond to IP addresses of this server. 5) If there are no A records for this server, add at least one A record corresponding to an address on this server, that the replication partner can contact. (In other words, if there multiple IP addresses for this DNS server, add at least one that is on the same network as the Active Directory DNS server you are updating. )   6) Note, that is not necessary to update EVERY replication partner. It is only necessary that the records are fixed up on enough replication partners so that every server that replicates with this server will receive (through replication) the new data.

Больше ничего не видно.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

• Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это  сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
• Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

• Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
• Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
• KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

• Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
• Теперь все это дело шифруется сессионным ключом и передается клиенту.

• Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
• Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs .  В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Хотя использование Kerberos порой напоминает черную магию, это одна из ключевых технологий Active Directory (AD). Большинство настроек Kerberos абстрагировано, и взаимодействовать с протоколом приходится нечасто. Тем не менее Kerberos применяется всякий раз, когда пользователь регистрируется на компьютере, присоединенном к AD, а также при доступе к сетевым ресурсам, таким как общие папки и приложения.

Вместо того чтобы передавать через сеть собственно пароль, Kerberos работает с последовательностью билетов. На высоком уровне это выглядит так: при регистрации пользователя на компьютере формируется серия обменов данными с контроллером домена (DC), и в случае успеха пользователю назначается билет на право получения билетов (TGT). Впоследствии при каждом обращении к службе, такой как общая папка или приложение, TGT используется, чтобы получить билет для доступа к службе или приложению.

Проверка подлинности

Когда компьютер выполняет проверку подлинности при регистрации, в контроллер домена отправляется сообщение AS_REQ или Authentication Service Request. В Kerberos контроллер домена именуется центром распространения ключей Key Distribution Center (KDC). На рисунке 1 показаны важнейшие элементы запроса AS_REQ. Имя клиента представляет собой основное имя пользователя (UPN) или унаследованное имя пользователя (sAMAccountName). Имя службы в этом случае всегда одно и то же, запрос к службе krbtgt в контексте домена или пользователя. Чтобы предотвратить атаки с повторной передачей пакетов, в ходе которой злоумышленник повторно использует сообщение AS_REQ, текущее время шифруется с использованием хеша пароля пользователя. Допустимое расхождение при этом — пять минут. Если зашифрованная отметка времени отличается от текущего времени более чем на пять минут, то запрос отвергается.

Когда KDC получает сообщение AS_REQ, в первую очередь предпринимается попытка расшифровать отметку времени с использованием локальной копии хеша пароля пользователя. Если попытка заканчивается неудачей, клиент получает сообщение об ошибке, и обработка запроса прекращается. Если дешифрация проходит удачно, а значение отметки времени находится в приемлемых пределах, KDC выдает пользователю сообщение AS_REP (Authentication Service Reply) от службы проверки подлинности со встроенным билетом TGT. На рисунке 2 показано содержимое сообщения AS_REP. На данном этапе компьютер пользователя сохраняет в кэше билет TGT и сеансовый ключ на время существования TGT и удаляет пароль пользователя. По умолчанию время существования билетов TGT, сформированных центрами KDC AD, истекает через десять часов.

В AD для Kerberos требуется зашифрованная отметка времени в сообщении AS_REQ. Первоначальный обмен известен как предварительная проверка подлинности. В Kerberos в стандартном виде не обязательно шифровать отметки времени; вполне достаточно сообщения AS_REQ, содержащего имя клиента и имя службы. Недостаток такого подхода заключается в уязвимости для атаки методом перебора по словарю, так как каждый запрос, содержащий уникальное имя клиента, будет возвращать ошибку, указывающую, что клиент не обнаружен, или выдаст действительный TGT данному пользователю.

Как показано на рисунке 2, сообщение AS_REP содержит два блока зашифрованных данных. Первый шифруется с применением хеша пароля пользователя и содержит сеансовый ключ и отметку времени окончания существования билета. Сеансовый ключ используется для шифрования будущих соединений с центром KDC. Второй компонент, билет TGT, шифруется с помощью секрета KDC. Секрет KDC в реализации Kerberos в AD хранится как пароль учетной записи пользователя krbtgt, существующей в каждом домене AD. Учетная запись krbtgt создается, когда назначается первый DC в домене; этой учетной записи принадлежит решающая роль в функционировании домена.

Получение билета службы

В Kerberos любой объект, к которому требуется получить доступ, называется службой. К службам относятся серверы файлов и печати, серверы базы данных и внутренние веб-приложения. Для доступа к службе пользователь предоставляет билет службы. Первый шаг — определить имя участника службы service principal name (SPN), к которой нужно получить доступ. Задача формирования SPN возлагается на компьютер или приложение пользователя.

На рисунке 3 показано содержимое сообщения TGS_REQ (Ticket Granting Service Request), которое KDC получает от клиента, если тот пытается обратиться к службе. Первый фрагмент информации — имя SPN службы, для которой клиент запрашивает билет. Имя клиента и отметка времени зашифрованы с помощью сеансового ключа, полученного клиентом в переданном ранее сообщении AS_REP. Эта информация повторно используется для предотвращения атак, в ходе которых злоумышленник повторно задействует сообщение запроса. Также прилагается экземпляр билета TGT, ранее полученного клиентом.

Если KDC получает сообщение TGS_REQ и указан один элемент для SPN, отметка времени находится в допустимом диапазоне и билет TGT действителен (не просрочен), то клиенту предоставляется билет службы как часть сообщения TGS_REP (рисунок 4). Сообщение TGS_REP содержит все данные, необходимые клиенту для доступа к службе.

С помощью секрета службы (например, пароля учетной записи компьютера или учетной записи службы) шифруется билет службы, который клиент кэширует и использует всегда, когда необходим доступ к службе. Так же как у билетов TGT, время, в течение которого разрешено повторно использовать билеты службы, ограничено (десять часов по умолчанию в реализации Kerberos в AD). Имея билет службы, клиент может запросить доступ к ней.

Доступ к службам

Билет службы предъявляется приложению в форме сообщения AP_REQ Kerberos, как показано на рисунке 5. Служба дешифрует билет службы и получает сеансовый ключ, который можно использовать для дешифрации полей отметки времени и имени клиента, которые в свою очередь используются для проверки подлинности билета службы. Даже если служба принимает билет службы, на данном этапе клиент просто прошел проверку в службе. Выполнить задачу авторизации службе предстоит на основе информации о клиенте.

В билет службы также обычно входят данные, известные как сертификат атрибута привилегий Privilege Attribute Certificate (PAC). На рисунке 5 сертификат PAC именуется информацией маркера Token Information. Это та же информация маркера, которую KDC включает в билет TGT пользователя (рисунок 2). Сертификат PAC составлен из такой информации, как идентификатор безопасности (SID) пользователя, сведения о членстве в группе и правах безопасности/привилегиях пользователя. Когда пользователь предъявляет билет TGT в центр KDC, чтобы запросить билет службы, KDC копирует информацию маркера из TGT и вставляет в поле PAC билета службы. Служба использует эту информацию, чтобы подготовить маркер доступа для пользователя и проверить авторизацию пользователя, обычно на основе членства в группе.

Допускается передача дополнительного сообщения Kerberos, известного как AP_REP или Application Reply, после того как пользователь предъявляет билет службы в сообщении AP_REQ, показанном на рисунке 5. Сообщение Application Reply — необязательное; как правило, приложение не отправляет такое сообщение, если не происходит ошибки. Пример ситуации, когда формируется сообщение AP_REP: клиент запрашивает (в сообщении AP_REQ) у службы подтверждение подлинности через процесс, известный как обоюдная проверка подлинности.

Обзор процесса

На рисунке 6 показана схема потока сообщений, когда пользователь решает обратиться к службе на сервере приложений. Пользователь регистрируется на своей рабочей станции, которая выдает последовательность сообщений AS_REQ и AS_REP в центр KDC, откуда пользователь получает билет TGT, если учетные данные верны. Затем TGT пользователя кэшируется в памяти, и каждый раз, когда пользователю нужно получить доступ к службе (например, к серверу файлов, серверу печати, веб-приложению), пользователь предъявляет TGT центру KDC и запрашивает билет службы для службы. Пользователь получает билет службы и предъявляет его приложению, чтобы запросить доступ.

Если используются контроллеры домена только для чтения (RODC), поток сообщений немного отличается от показанного на рисунке 6, в зависимости от политик репликации паролей и места кэширования паролей. Следует иметь в виду, что центру KDC требуется доступ к секретам службы и пользователя или компьютера, чтобы издавать билеты службы или билеты TGT соответственно. По умолчанию RODC не кэширует пароли, поэтому у него нет доступа к необходимым секретам.

Если вернуться к рисунку 2, можно увидеть, что билет TGT пользователя зашифрован с помощью секрета KDC. Этот секрет — пароль для учетной записи krbtgt, которая имеется во всех доменах AD. Учитывая положения, заложенные в основу RODC (то есть его уязвимость по умолчанию), было бы потенциально опасно хранить в RODC пароль доменной учетной записи krbtgt. Если RODC будет скомпрометирован, взломщик сможет самостоятельно издавать билеты TGT. В целях снижения риска каждый RODC располагает собственной учетной записью krbtgt и никогда не осведомлен о паролях учетных записей домена или другого RODC. Доступные для записи контроллеры домена имеют доступ к паролям всех учетных записей krbtgt, поэтому они могут расшифровать билеты TGT, изданные любым RODC в домене.

Прозрачная проверка подлинности

Kerberos почти прозрачен для администраторов AD. В отличие от многих схем проверки подлинности, в Kerberos никогда не требуется передавать пароли через сеть, как и нет необходимости хранить пароль пользователя в памяти после начального процесса регистрации. Благодаря этим преимуществам существенно снижается уязвимость, свойственная другим протоколам проверки подлинности.

Как выглядит ошибка credssp

An authentication error has occurred. The function requested is not supported. Remote computer name. This coild be to CredSSP encryption oracle remediation.

Ну и конечно в русском исполнении:

Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

CredSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня. Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X. 509 и PKINIT.

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с Windows:

• NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
• Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях.
• Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
• Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
• PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
• Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
• Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
• Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена ​​в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.

Варианты исправления ошибки CredSSP

На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.

• Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
• Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол  с проверкой подлинности на уровне сети»
• То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
• Ну и самый правильный метод, это установка обновлений на все ваши системы

Отключаем credssp в Windows через NLA

Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft. System. В окне «Система» находим пункт меню «Настройка удаленного доступа»

Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол  с проверкой подлинности на уровне сети»

После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:

• Использовать сетевой реестр Windows
• Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.

Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».

Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.

У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):

Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.

Или можно так же отключить NLA, для этого найдите ветку реестра:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp

Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.

Теперь то же самое вы можете выполнить и через PsExec. exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:

PsExec. exe \w10-cl01 -u rootАдминистратор -p пароль cmd

w10-cl01 — это имя компьютера.

Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:

Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:

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

Отключаем шифрование credssp через GPO

Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.

Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc. msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit. msc.

Вам необходимо перейти в ветку:

Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:

• Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
• Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
• Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.

Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.

После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра

На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory

Самый правильный метод, это установка обновлений

Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607 — KB4103723
• Windows Server 2016 / Windows 10 1703 — KB4103731
• Windows Server 2016 / Windows 10 1709 — KB4103727
• Windows Server 2016 / Windows 10 1803 — KB4103721

На этом у меня все, надеюсь, что вы разобрались в работе CredSSP и научились ей управлять. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik. org.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

• Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
• Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.

Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI — это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети,  и приложению вообще до лампочки, какой из них использовать.

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Пользовательский ключ — когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

Системный ключ — в момент ввода компьютера в домен Active Directory он так же получает свой уникальный пароль, на его основании и создается ключ, все как у пользователя. Еще отмечу, что данный пароль каждый месяц автоматически меняется, поэтому старые компьютеры, которые долго не были включены, не могут пройти аутентификацию в домене, так как потеряны доверительные отношения.

Ключ службы (service key) — тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

За счет высокого уровня безопасности протокола Kerberos, при передаче данных вы не увидите пароли или значения хэш в открытом виде. Еще одним требованием к работе с данным протоколом, выступает системное время, которое не может расходится с временем на контроллере домена более чем 5 минут

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.