Ошибка протокола kerberos при попытке использовать подсистему смарт карт

I have developed a custom read-only virtual smartcard. The solution includes
 both reader and minidriver.

The smartcard passes a lot of tests. Those include but not limited to:

1. Certutil.exe –scinfo
2. Cmck.exe from Windows Hardware Certification Kit
3. LsaLogonUser API with KERB_SMART_CARD_LOGON
4. Smartcard logon onto a remote computer using non-NLA (legacy) mode

The problem is that it does not work with remote desktop client (mstsc.exe) in NLA mode.

When launched the RDP client enumerates readers and smartcards, then it displays logon UI prompt and asks for the smartcard PIN.
 After PIN is provided and credential tile is submitted an expected communication with reader and minidriver starts to happen from both mstsc.exe and lsass.exe. However no calls to CardSignData or CardRSADecrypt are made and the client finally
fails with the message «The Kerberos protocol encountered an error while attempting to utilize the smartcard subsystem» which corresponds to ERROR_SMARTCARD_SUBSYSTEM_FAILURE.

I have a pretty verbose logging in my code and what puzzles me a lot is that neither reader nor mini-driver return errors during this run. Windows event log does not provide any hints either.

Technet suggests [1] using WPP tracing on several system components, but it does not seem to be useful as MS do not provide corresponded TMF files to decode binary logging files. I may be mistaken here as I have little experience in this
area.

Did you have similar problems or perhaps have an idea what could be done to understand the cause of the error?

[1] https://technet.microsoft.com/en-us/library/ff404296%28v=ws.10%29.aspx

I have developed a custom read-only virtual smartcard. The solution includes
 both reader and minidriver.

The smartcard passes a lot of tests. Those include but not limited to:

1. Certutil.exe –scinfo
2. Cmck.exe from Windows Hardware Certification Kit
3. LsaLogonUser API with KERB_SMART_CARD_LOGON
4. Smartcard logon onto a remote computer using non-NLA (legacy) mode

The problem is that it does not work with remote desktop client (mstsc.exe) in NLA mode.

When launched the RDP client enumerates readers and smartcards, then it displays logon UI prompt and asks for the smartcard PIN.
 After PIN is provided and credential tile is submitted an expected communication with reader and minidriver starts to happen from both mstsc.exe and lsass.exe. However no calls to CardSignData or CardRSADecrypt are made and the client finally
fails with the message «The Kerberos protocol encountered an error while attempting to utilize the smartcard subsystem» which corresponds to ERROR_SMARTCARD_SUBSYSTEM_FAILURE.

I have a pretty verbose logging in my code and what puzzles me a lot is that neither reader nor mini-driver return errors during this run. Windows event log does not provide any hints either.

Technet suggests [1] using WPP tracing on several system components, but it does not seem to be useful as MS do not provide corresponded TMF files to decode binary logging files. I may be mistaken here as I have little experience in this
area.

Did you have similar problems or perhaps have an idea what could be done to understand the cause of the error?

[1] https://technet.microsoft.com/en-us/library/ff404296%28v=ws.10%29.aspx

Ошибка: сбой проверки подлинности Kerberos

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Эта ошибка возникает, когда монитор удаленной отладки Visual Studio выполняется от имени учетной записи локальной системы (LocalSystem) или учетной записи сетевой службы (NetworkService). Работая под одной из этих учетных записей, удаленный отладчик должен установить соединение с аутентификацией на основе Kerberos, чтобы иметь возможность возвращать данные главному компьютеру отладчика Visual Studio.

Проверка подлинности Kerberos невозможна при следующих условиях:

Удаленный компьютер или ведущий компьютер с отладчиком включен в рабочую группу, а не в домен.

Служба Kerberos на контроллере домена была отключена.

Если аутентификация на основе Kerberos недоступна, следует сменить учетную запись, от имени которой выполняется монитор удаленной отладки Visual Studio. Инструкции см. в статье Ошибка: службе удаленного отладчика Visual Studio не удается подключиться к этому компьютеру.

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

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

В первой строке ответа ping будет выведено полное имя компьютера и IP-адрес, возвращаемый службой DNS для указанного компьютера.

Источник

Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам

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

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Дополнительные сведения о контексте ошибки см. в ссылке HTTP 400 Bad Request (Запросзагона слишком долго) ответов на запросы HTTP.

В аналогичных условиях Windows проверки подлинности NTLM работает, как и ожидалось. Проблема проверки подлинности Kerberos может возникнуть только при анализе Windows поведения. Однако в таких сценариях Windows не удастся обновить параметры групповой политики.

Такое поведение происходит в любой из поддерживаемых в настоящее время Windows версиях. Сведения о поддерживаемых версиях Windows см. в Windows.

Причина

Пользователь не может проверить подлинность, так как билет, который создает Kerberos для представления пользователя, недостаточно велик, чтобы содержать все члены группы пользователя.

В рамках службы проверки подлинности ExchangeWindows создает маркер для представления пользователя для целей авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя и siD-коды всех групп, к которой принадлежит пользователь. Он также включает все SID-данные, хранимые в атрибуте учетной sIDHistory записи пользователя. Kerberos хранит этот маркер в структуре данных сертификата атрибута привилегий (PAC) в билете Kerberos Ticket-Getting (TGT). Начиная с Windows Server 2012, Kerberos также сохраняет маркер в структуре данных Active Directory Claims (Dynamic Access Control) в билете Kerberos. Если пользователь является членом большого количества групп, и если существует много утверждений для пользователя или используемого устройства, эти поля могут занимать много пробелов в билете.

Маркер имеет фиксированный максимальный размер MaxTokenSize (). Транспортные протоколы, такие как удаленный вызов процедуры (RPC) и HTTP, зависят от значения при выделении буферов MaxTokenSize для операций проверки подлинности. MaxTokenSize имеет следующее значение по умолчанию в зависимости от версии Windows, которая создает маркер:

Как правило, если пользователь принадлежит к более чем 120 универсальным группам, значение по умолчанию не создает достаточно большого буфера для MaxTokenSize удержания информации. Пользователь не может проверить подлинность и может получить сообщение из памяти. Кроме того, Windows не сможет применить параметры групповой политики для пользователя.

Другие факторы также влияют на максимальное число групп. Например, УАИ для глобальных и локальных доменных групп имеют меньшие требования к пространству. Windows Server 2012 и более поздние версии добавляют сведения о претензиях в билет Kerberos, а также сжимаются SID-данные ресурсов. Обе функции изменяют требования к пространству.

Решение

Чтобы устранить эту проблему, обновим реестр на каждом компьютере, который участвует в процессе проверки подлинности Kerberos, включая клиентские компьютеры. Рекомендуется обновить все системы на Windows, особенно если пользователям необходимо войти в несколько доменов или лесов.

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

На каждом из этих компьютеров установите запись реестра для MaxTokenSize большего значения. Эту запись можно найти в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters подкайке. Компьютеры должны перезапустить после внести это изменение.

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

Например, рассмотрим пользователя, используюшего веб-приложение, которое опирается на SQL Server клиента. В рамках процесса проверки подлинности клиент SQL Server передает маркер пользователя в SQL Server базу данных. В этом случае необходимо настроить запись реестра на каждом MaxTokenSize из следующих компьютеров:

В Windows Server 2012 (и более поздних версиях) Windows можно войти в журнал события (Event ID 31), если размер маркера преодолеет определенный порог. Чтобы включить такое поведение, необходимо настроить параметр групповой политики Конфигурация компьютераАдминистративные шаблоныSystemKDCWarning для больших билетов Kerberos.

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Windows Сервер 2008 R2 и более ранние версии используют ту же формулу. Тем не менее, в этих версиях число членов группы домена и локальной группы является частью значения d, а не значения s.

Если у вас есть значение 0x0000FFFF (64K), вы можете быть в состоянии буферить примерно MaxTokenSize 1600 D-класса SID или примерно 8000 S-class SIDs. Однако на значение, которое можно безопасно использовать, влияет ряд других факторов, в том числе MaxTokenSize следующие:

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

Если у вас несколько трастов, настройте эти траста для фильтрации siD-систем. Эта конфигурация снижает влияние размера билета Kerberos.

Если вы используете Windows Server 2012 или более поздний вариант, на требования к пространству SID также влияют следующие факторы:

В 2019 г. Корпорация Майкрософт отправила обновления в Windows, которые изменили конфигурацию неподготовленного делегирования для Kerberos на отключенную. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.

Так как сжатие SID ресурсов широко используется и неконтентированное делегированное число неограниченно, 48000 или больше должны стать достаточными для MaxTokenSize всех сценариев.

Известные проблемы, влияющие на MaxTokenSize

Для большинства реализаций должно быть достаточно значения в MaxTokenSize 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе.

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Эта проблема аналогична тому, что пользователь, у которого слишком много членов группы, не может проверить подлинность, но расчеты и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или Windows проверки подлинности NTLM. Дополнительные сведения см. в статью Ведение журнала учетной записи пользователя, в которую входит более 1010групп, на компьютере на Windows сервере.

Известная проблема при использовании значений MaxTokenSize более 48 000

Для смягчения вектора атаки на службу internet Information Server (IIS) использует ограниченный размер буфера http-запроса в 64 КБ. Билет Kerberos, который является частью http-запроса, закодирован как Base64 (6 битов, расширенный до 8 битов). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Поэтому, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 битов.

Если задать запись реестра значению, которое превышает 48000 bytes, и буферное пространство используется для siDs, может возникнуть ошибка MaxTokenSize IIS. Однако если вы установите запись реестра до 48 000 бит и используете пространство для SID-файлов и утверждений, возникает ошибка MaxTokenSize Kerberos.

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Мы также определили, что протокол IKE IPSEC не позволяет BLOB-адресу безопасности быть больше 66 536 битов, и он также не будет иметь значения, когда задавалось большее MaxTokenSize значение.

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

Компьютер в детском домене леса Службы домена Active Directory (AD DS) не может получить доступ к службе, которая находится в другом домене в одном лесу. При запуске сетевого следа на сообщениях на клиентском компьютере и с клиентского компьютера этот след содержит следующие сообщения Kerberos:

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Шифрование RC4 считается менее безопасным, чем более новые типы шифрования, AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96. Руководства по безопасности, такие как руководство по технической реализации Windows 10 безопасности, предоставляют инструкции по повышению безопасности компьютера, настроив его на использование только шифрования AES128 и/или AES256 (см. типы шифрования Kerberos, чтобы предотвратить использование наборов шифрования DES и RC4).

Такой клиент может продолжать подключаться к службам в собственном домене, которые используют шифрование AES128 или AES256. Однако другие факторы могут помешать клиенту подключиться к аналогичным службам в другом доверяемом домене, даже если эти службы также используют шифрование AES128 или AES256.

На очень высоком уровне контроллер домена (DC) отвечает за управление запросами доступа в собственном домене. В рамках процесса проверки подлинности Kerberos dc проверяет, что клиент и служба могут использовать один и тот же тип шифрования Kerberos. Однако, когда клиент запрашивает доступ к службе в другом доверяемом домене, dc клиента должен «передать» клиенту dc в домен службы. Когда dc создает билет на передачу, вместо сравнения типов шифрования клиента и службы, он сравнивает типы шифрования клиента и доверия.

Проблема возникает из-за конфигурации самого доверия. В Active Directory объект домена имеет связанные доверенные объекты домена (TDOs), которые представляют каждый домен, которому он доверяет. Атрибуты TDO описывают отношения доверия, включая типы шифрования Kerberos, поддерживаемые доверием. Связь по умолчанию между детским доменом и родительским доменом — это двунаружное транзитное доверие, которое поддерживает тип шифрования RC4. Оба родительского и детского домена имеют TDOs, которые описывают эту связь, в том числе тип шифрования.

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

После сбоя проверки подлинности Kerberos клиент пытается вернуться к проверке подлинности NTLM. Однако если проверка подлинности NTLM отключена, у клиента нет других альтернатив. Поэтому попытка подключения сбой.

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

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

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

Этот метод добавляет новые типы шифрования в конфигурацию доверия и не требует изменений для клиента или службы. В этом методе для настройки доверия используется средство командной ksetup строки.

Чтобы настроить тип доверия шифрования Kerberos, откройте окно командной подсказки на домене DC в доверенного домена и введите следующую команду:

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

В примере, в котором находится корневой домен (где находится служба) и это детский домен (где находится клиент), откройте окно командной подсказки на dc и введите следующую contoso.com child.contoso.com contoso.com команду:

После завершения этой команды dc может успешно создать переходный билет, который клиент может использовать для child.contoso.com достижения contoso.com dc.

Так как связь между двумя доменами является двунастройным транзитным доверием, настройте другую сторону доверия, открыв окно Командная подсказка на dc и введите child.contoso.com следующую команду:

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

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

Полные инструкции по изменению типов шифрования, которые могут использовать клиенты, см. в Windows Конфигурации для поддерживаемого типа шифрования Kerberos.

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

В случае Windows лесных трастов обе стороны доверия поддерживают AES. Поэтому все запросы на билеты в трастах используют AES. Однако сторонний клиент Kerberos, который проверяет билет на реферал, может уведомить вас о том, что в билете используется тип шифрования, который клиент не поддерживает. Чтобы позволить такому клиенту и далее проверять билет, обнови его в поддержку AES.

При использовании этого метода настройте доверие с помощью оснастки Active Directory Domains and Trusts MMC. Чтобы использовать этот метод, выполните следующие действия:

В доменах Active Directory и Trusts перейдите к надежному объекту домена (в contoso.com примере). Щелкните правой кнопкой мыши объект, выберите свойства и выберите трасты.

В поле Домены, которые доверяют этому домену (входящие трасты), выберите доверчивый домен (в child.domain.com примере).

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

В случае доверия в одну сторону доверенный домен перечисляет доверчивый домен как входящий, а доверчивый домен — как исходящую.

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

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

Ошибка проверки подлинности kerberos windows server 2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Ошибка проверки подлинности kerberos windows server 2019

Этот форум закрыт. Спасибо за участие!

Спрашивающий

Общие обсуждения

Имеется хост-система Windows 10 и установленная на VMware Windows Server 2008 r2 Core. Серверной версии присвоен ip-адрес. С помощью Диспетчера серверов Windows 10 пытаюсь подключиться по ip для удаленного управления, но выдается «Ошибка проверки подлинности Kerberos». Какие действия предпринять?

Все ответы

Сразу оговорюсь, что в делах администрирования я совсем новичок.

Расхождения во времени нет, везде стоит правильное. winrm включен на Windows Server. Какие логи нужно посмотреть? Спасибо.

В RSAT ведь и входит Диспетчер серверов, насколько я понимаю? Проблема была изначально, у меня просто появилась задача подключиться к серверу через этот диспетчер.

Через Управление компьютером > Подключиться к другому компьютеру возникает «Ошибка (5). Отказано в доступе».

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд

Я не волшебник, я только учусь MCP, MCTS, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение». Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter.

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд

У вас dc виртуальный или физический сервер?

Тогда будем пытаться делать вывод из имеющейся информации. Из того, что приведено, подозрительны две вещи:

Они должны быть зарегистрированы на MY-PC

Источник

Переустановка службы смарт карт windows 10

При запуске Панели управления Рутокен на вкладке Администрирование отображается сообщение: «Нет доступа к системной службе «Смарт-карты». Дальнейшая работа невозможна. Если вы подключены через службу Удаленных рабочих столов (RDP), смотрите подробности здесь«

Существует две причины отображения этого сообщения:

1. Подключение производится через «Удаленный рабочий стол» (RDP). Рутокен вставлен в компьютер, к которому подключаются удаленно.

Эта схема является неправильной. С подробным описанием можно ознакомиться в этой статье.

2. Проблема со службой «Смарт-карта».

При локальном подключении (или при правильном подключении по RDP) эта ошибка указывает на проблемы со службой «Смарт-карта».

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

1. Убедитесь, что у веток реестра (Пуск — Выполнить — regedit)

есть полный доступ у двух пользователей: Local Service и текущий пользователь (под которым осуществлен вход): щелкните правой кнопкой мыши по необходимой ветке, выберите пункт Разрешения, выберите нужного пользователя(*) и установите внизу галочку Полный доступ.

(*) Если нужного пользователя в выборе нет — нужно его добавить:

Нажмите Добавить.

В поле Введите имена выбираемых объектов введите LO.

Нажмите Проверить имена.

Выберите Local Service.

2. Убедитесь, что Служба «Смарт-карта» запущена от имени NT AUTHORITYLocalService (Пуск — Панель управления — Администрирование — Службы).

Попробуйте Запустить/Перезапустить службу.

3. Если служба не работает/не запускается/не перезапускается — может понадобиться ее переустановка (Только системным администраторам!).

1) Win7, Vista, Win8/8.1, Win10

•Запустите файл (smart-card-7) из вложения.

•Переустановите службу смарт-карт согласно инструкции из вложения (Smart-Card-XP).

4. Возможно какое-либо ПО может блокировать службу «Смарт-карта». Совместно с системным администратором произведите поиск ПО, которое может вызывать проблемы со службой «Смарт-карта».

5. Иногда ошибка может быть в самой ОС. Порой приходится переустанавливать сервис пак, или саму ОС .

Устранение неполадок смарт-карт Smart Card Troubleshooting

Применяется к: Windows 10, Windows Server 2016 Applies To: Windows 10, Windows Server 2016

В этой статье рассказывается о средствах и службах, которые разработчики смарт-карт могут использовать для выявления проблем с сертификатами при развертывании смарт-карт. This article explains tools and services that smart card developers can use to help identify certificate issues with the smart card deployment.

Отладка и отслеживание проблем смарт-карт требуют различных средств и подходов. Debugging and tracing smart card issues requires a variety of tools and approaches. В следующих разделах указаны инструменты и подходы, которые можно использовать. The following sections provide guidance about tools and approaches you can use.

Certutil Certutil

Полное описание Certutil, включая примеры, которые показывают, как его использовать, см. в примере Certutil [W2012]. For a complete description of Certutil including examples that show how to use it, see Certutil [W2012].

Сертификаты списка, доступные на смарт-карте List certificates available on the smart card

Чтобы перечислить сертификаты, доступные на смарт-карте, введите certutil -scinfo . To list certificates that are available on the smart card, type certutil -scinfo .

Ввод ПИН-кода не требуется для этой операции. Entering a PIN is not required for this operation. Вы можете нажать ESC, если вам будет предложен ПИН-код. You can press ESC if you are prompted for a PIN.

Удаление сертификатов на смарт-карте Delete certificates on the smart card

Каждый сертификат заключен в контейнер. Each certificate is enclosed in a container. При удалении сертификата на смарт-карте удаляется контейнер для сертификата. When you delete a certificate on the smart card, you’re deleting the container for the certificate.

Чтобы найти значение контейнера, введите certutil -scinfo . To find the container value, type certutil -scinfo .

Чтобы удалить контейнер, введите certutil-delkey-csp «Microsoft Base Smart Card Crypto Provider» To delete a container, type certutil -delkey -csp «Microsoft Base Smart Card Crypto Provider» » «.

Отладка и отслеживание с помощью WPP Debugging and tracing using WPP

WPP упрощает отслеживание работы поставщика трассировки. WPP simplifies tracing the operation of the trace provider. Он предоставляет поставщику трассировки механизм для входа двоичных сообщений в режиме реального времени. It provides a mechanism for the trace provider to log real-time binary messages. Зарегистрированные сообщения можно преобразовать в понятный для человека след операции. Logged messages can be converted to a human-readable trace of the operation. Дополнительные сведения см. в блоге Diagnostics with WPP — блог NDIS. For more information, see Diagnostics with WPP — The NDIS blog.

Включить трассировка Enable the trace

С помощью WPP используйте одну из следующих команд, чтобы включить отслеживание: Using WPP, use one of the following commands to enable tracing:

tracelog.exe -kd-rt-start -guid # -f . .etl-flags -ft 1 tracelog.exe -kd -rt -start -guid # -f . .etl -flags -ft 1

Начало журнала -ets-p <> — -ft 1 -rt -o . **.etl-mode 0x00080000 ** logman start -ets -p <> — -ft 1 -rt -o . .etl -mode 0x00080000

Параметры можно использовать в следующей таблице. You can use the parameters in the following table.

Чтобы включить трассировку для службы SCardSvr: To enable tracing for the SCardSvr service:

tracelog.exe -kd-rt-start scardsvr -guid #13038e47-ffec-425d-bc69-5707708075fe-f .scardsvr.etl-flags 0xffff -ft 1 tracelog.exe -kd -rt -start scardsvr -guid #13038e47-ffec-425d-bc69-5707708075fe -f .scardsvr.etl -flags 0xffff -ft 1

logman start scardsvr -ets-p <13038e47-ffec-425d-bc69-5707708075fe>0xffff -ft 1 -rt -o .scardsvr.etl-mode 0x00080000 logman start scardsvr -ets -p <13038e47-ffec-425d-bc69-5707708075fe>0xffff -ft 1 -rt -o .scardsvr.etl -mode 0x00080000

Чтобы включить трассировку для scfilter.sys: To enable tracing for scfilter.sys:

• tracelog.exe-kd-rt-start scfilter-guid #eed7f3c9-62ba-400e-a001-658869df9a91 -f .scfilter.etl-flags 0xffff-ft 1 tracelog.exe -kd -rt -start scfilter -guid #eed7f3c9-62ba-400e-a001-658869df9a91 -f .scfilter.etl -flags 0xffff -ft 1

Остановка трассировки Stop the trace

С помощью WPP используйте одну из следующих команд, чтобы остановить трассировку: Using WPP, use one of the following commands to stop the tracing:

tracelog.exe -stop tracelog.exe -stop

logman -stop -ets logman -stop -ets

Примеры: Examples

Чтобы остановить след: To stop a trace:

tracelog.exe -stop scardsvr tracelog.exe -stop scardsvr

logman -stop scardsvr -ets logman -stop scardsvr -ets

Протокол Kerberos, KDC и отладка и отслеживание NTLM Kerberos protocol, KDC, and NTLM debugging and tracing

Эти ресурсы можно использовать для устранения неполадок этих протоколов и KDC: You can use these resources to troubleshoot these protocols and the KDC:

Набор драйверов Windows (WDK) и средства отладки для Windows (WinDbg). Windows Driver Kit (WDK) and Debugging Tools for Windows (WinDbg). Вы можете использовать средство журнала трассировки в этом SDK для отладки сбоев проверки подлинности Kerberos. You can use the trace log tool in this SDK to debug Kerberos authentication failures.

Чтобы начать трассировку, можно использовать Tracelog . To begin tracing, you can use Tracelog . Различные компоненты используют различные GUID-интерфейсы управления, как это объясняется в этих примерах. Different components use different control GUIDs as explained in these examples. Дополнительные сведения Tracelog см. в . For more information, see Tracelog .

Протокол NTLM NTLM

Чтобы включить трассировку для проверки подлинности NTLM, запустите следующую команду в командной строке: To enable tracing for NTLM authentication, run the following command on the command line:

• tracelog.exe-kd-rt-start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .ntlm.etl-flags 0x15003-ft 1 tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .ntlm.etl -flags 0x15003 -ft 1

Чтобы остановить отслеживание для проверки подлинности NTLM, запустите эту команду: To stop tracing for NTLM authentication, run this command:

• tracelog -stop ntlm tracelog -stop ntlm

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

Чтобы включить трассировку для проверки подлинности Kerberos, запустите эту команду: To enable tracing for Kerberos authentication, run this command:

• tracelog.exe-kd-rt-start kerb-guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .kerb.etl-flags 0x43-ft 1 tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .kerb.etl -flags 0x43 -ft 1

Чтобы остановить отслеживание проверки подлинности Kerberos, запустите эту команду: To stop tracing for Kerberos authentication, run this command:

• tracelog.exe -stop kerb tracelog.exe -stop kerb

KDC KDC

Чтобы включить трассировку для KDC, запустите следующую команду в командной строке: To enable tracing for the KDC, run the following command on the command line:

• tracelog.exe-kd-rt-start kdc-guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .kdc.etl-flags 0x803-ft 1 tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .kdc.etl -flags 0x803 -ft 1

Чтобы остановить отслеживание для KDC, запустите следующую команду в командной строке: To stop tracing for the KDC, run the following command on the command line:

• tracelog.exe -stop kdc tracelog.exe -stop kdc

Чтобы остановить отслеживание с удаленного компьютера, запустите эту команду: logman.exe -s * *. To stop tracing from a remote computer, run this command: logman.exe -s .

Расположение по умолчанию для logman.exe % systemroot%system32. The default location for logman.exe is %systemroot%system32. Используйте параметр -s для поставки имени компьютера. Use the -s option to supply a computer name.

Настройка отслеживания с помощью реестра Configure tracing with the registry

Вы также можете настроить трассировку, редактировать значения реестра Kerberos, показанные в следующей таблице. You can also configure tracing by editing the Kerberos registry values shown in the following table.

Если вы использовали, посмотрите следующий файл журнала в текущем Tracelog каталоге: kerb.etl/kdc.etl/ntlm.etl. If you used Tracelog , look for the following log file in your current directory: kerb.etl/kdc.etl/ntlm.etl.

Если вы использовали параметры ключей реестра, показанные в предыдущей таблице, посмотрите на файлы журнала трассировки в следующих расположениях: If you used the registry key settings shown in the previous table, look for the trace log files in the following locations:

NTLM: %systemroot%tracingmsv1_0 NTLM: %systemroot%tracingmsv1_0

Kerberos: %systemroot%tracingkerberos Kerberos: %systemroot%tracingkerberos

KDC: %systemroot%tracingkdcsvc KDC: %systemroot%tracingkdcsvc

Для расшифровки файлов трассировки событий можно использовать Tracefmt (tracefmt.exe). To decode event trace files, you can use Tracefmt (tracefmt.exe). Tracefmt — это средство командной строки, которое форматы и отображение сообщений трассировки из файла журнала трассировки событий (.etl) или сеанса трассировки в режиме реального времени. is a command-line tool that formats and displays trace messages from an event trace log file (.etl) or a real-time trace session. Tracefmt может отображать сообщения в окне Командная подсказка или сохранять их в текстовом файле. can display the messages in the Command Prompt window or save them in a text file. Он расположен в поднаправлении toolstracing набора драйверов Windows (WDK). It is located in the toolstracing subdirectory of the Windows Driver Kit (WDK). Дополнительные сведения Tracefmt см. в . For more information, see Tracefmt .

Служба смарт-карт Smart Card service

Служба диспетчера ресурсов смарт-карт работает в контексте локальной службы. The smart card resource manager service runs in the context of a local service. Он реализуется в качестве общей службы процесса хост-службы (svchost). It’s implemented as a shared service of the services host (svchost) process.

Чтобы проверить, запущена ли служба Смарт-карты To check if Smart Card service is running

Нажмите кнопку CTRL+ALT+DEL, а затем выберите start Task Manager. Press CTRL+ALT+DEL, and then select Start Task Manager.

В диалоговом окне Диспетчер задач Windows выберите вкладку Services. In the Windows Task Manager dialog box, select the Services tab.

Выберите столбец Name для сортировки списка в алфавитном порядке, а затем введите s. Select the Name column to sort the list alphabetically, and then type s.

В столбце Имя посмотрите на SCardSvr, а затем посмотрите в столбце Состояние, чтобы узнать, запущена или остановлена служба. In the Name column, look for SCardSvr, and then look under the Status column to see if the service is running or stopped.

Перезапуск службы смарт-карт To restart Smart Card service

Запустите в качестве администратора в командной подсказке. Run as administrator at the command prompt.

Если появится диалоговое окно «Управление учетной записью пользователя», подтвердите, что отображаемая в нем акция является нужным, а затем выберите Да. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then select Yes.

В командной подсказке введите net stop SCardSvr . At the command prompt, type net stop SCardSvr .

В командной подсказке введите net start SCardSvr . At the command prompt, type net start SCardSvr .

Вы можете использовать следующую команду в командной подсказке, чтобы проверить, запущена ли служба: sc queryex scardsvr . You can use the following command at the command prompt to check whether the service is running: sc queryex scardsvr .

В следующем примере кода приводится пример вывода из этой команды: The following code sample is an example output from this command:

Считыватели смарт-карт Smart card readers

Как и любое устройство, подключенное к компьютеру, диспетчер устройств можно использовать для просмотра свойств и начала процесса отлаговки. As with any device connected to a computer, Device Manager can be used to view properties and begin the debug process.

Чтобы проверить, работает ли считыватель смарт-карт To check if smart card reader is working

Перейдите к компьютеру. Navigate to Computer.

Щелкните правой кнопкой мыши Компьютер, а затем выберите Свойства. Right-click Computer, and then select Properties.

В статье Задачивыберите диспетчер устройств. Under Tasks, select Device Manager.

В диспетчере устройств раздайте считывателисмарт-карт, выберите имя считывателей смарт-карт, которые необходимо проверить, а затем выберите Свойства. In Device Manager, expand Smart card readers, select the name of the smart card reader you want to check, and then select Properties.

Если считыватель смарт-карт не указан в диспетчере устройств, в меню Action выберите scan для изменения оборудования. If the smart card reader is not listed in Device Manager, in the Action menu, select Scan for hardware changes.

Диагностика CryptoAPI 2.0 CryptoAPI 2.0 Diagnostics

Диагностика CryptoAPI 2.0 доступна в версиях Windows, которые поддерживают CryptoAPI 2.0 и могут помочь устранить проблемы с инфраструктурой ключевых общедоступных ключевых элементов (PKI). CryptoAPI 2.0 Diagnostics is available in Windows versions that support CryptoAPI 2.0 and can help you troubleshoot public key infrastructure (PKI) issues.

CryptoAPI 2.0 Журналы диагностики событий в журнале событий Windows. CryptoAPI 2.0 Diagnostics logs events in the Windows event log. Журналы содержат подробные сведения о проверке цепочки сертификатов, операциях хранения сертификатов и проверке подписи. The logs contain detailed information about certificate chain validation, certificate store operations, and signature verification. Эта информация упрощает определение причин проблем и сокращает время, необходимое для диагностики. This information makes it easier to identify the causes of issues and reduces the time required for diagnosis.

Дополнительные сведения о диагностике CryptoAPI 2.0 см. в статью Устранение неполадок корпоративного PKI. For more information about CryptoAPI 2.0 Diagnostics, see Troubleshooting an Enterprise PKI.

Протокол безопасности Kerberos стал основой современной кибербезопасности. Фактически, он настолько хорошо интегрирован, что большинство пользователей или даже разработчиков вообще забывают о нем. Этот скрытый статус может затруднить получение информации о том, что такое Kerberos и как он работает, особенно со всеми различными формами, которые этот протокол принимает сегодня.

В этой статье мы ответим, что такое Kerberos, как он работает, и рассмотрим типичные атаки, которые инженеры безопасности Kerberos должны преодолевать ежедневно.

К концу вы получите новую оценку современной сетевой безопасности и, надеюсь, пик интереса к кибербезопасности!

Что такое Kerberos?

Kerberos — это протокол проверки подлинности компьютерной сети, предназначенный для упрощения и безопасности проверки подлинности.

Основная идея Kerberos вращается вокруг использования локальной формы личной идентификации, называемой билетами, которые предоставляются сервером аутентификации. Каждый билет принадлежит определенным областям, которые определяют, к каким службам он предоставляет доступ. Эти билеты зашифрованы, и для их использования требуется несколько уровней дешифрования. Эта система билетов гарантирует, что конфиденциальная информация, такая как пароли, никогда не будет отправлена ​​по сети.

Протокол Kerberos получил широкое признание с момента его создания в Массачусетском технологическом институте в 1980-х годах. Теперь он встроен в бесчисленное количество зависимых от безопасности реализаций в Интернете, и почти все компании ежедневно взаимодействуют по крайней мере с одной системой Kerberos.

Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.

Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.

Преимущества Kerberos

Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:

• Безопасность: Kerberos никогда не передает пароли по сети. Вместо этого Kerberos подтверждает личность пользователя, отправляя ограниченные по времени криптографические сообщения, которые становятся недействительными по истечении установленного периода. Даже сообщения были перехвачены и расшифрованы, они были бы бесполезны в считанные минуты!
• Единый вход: Kerberos требует, чтобы пользователь вводил пароль только один раз при первой аутентификации клиента. С этого момента пользователь имеет доступ ко всем керберизованным службам в области Kerberos без необходимости повторно вводить свой пароль. Единый вход упрощает работу с несколькими службами, устраняя необходимость в нескольких требованиях входа в систему.

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

• Взаимная аутентификация: в Kerberos оба конца связи должны быть аутентифицированы, прежде чем соединение будет разрешено. Взаимная аутентификация резко снижает возможность мошенников обманным путем заставить системы отправлять конфиденциальную информацию.

Пример взаимной аутентификации:

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

Основные компоненты Kerberos

Центр распространения ключей

Центр распространения ключей (KDC) — это центральный процесс Kerberos, содержащий сервер аутентификации (AS) и службу выдачи билетов (TGS). Его основная функция — быть посредником между этими двумя, ретранслируя сообщения от AS, выдает билет на выдачу билетов (TGT), а затем передает его для шифрования с помощью TGS. После этого KDC мало влияет на процесс аутентификации.

Билет на выдачу билетов

Этот билет выдается KDC после успешной аутентификации клиента. TGT зашифрован и содержит разрешения на то, к каким службам может получить доступ клиент, как долго предоставляется доступ, а также ключ сеанса, используемый для связи с клиентом.

Клиенты не могут расшифровать TGT, так как у них нет ключа TGS. Следовательно, они должны слепо представить TGT желаемым службам (которые могут получить доступ к TGS) и позволить службам решить, может ли клиент получить к нему доступ.

Скрывая TGT от клиента, Kerberos предотвращает мошенническое копирование или изменение разрешений клиентом.

Сервер аутентификации

Сервер аутентификации — это первая остановка при аутентификации с помощью Kerberos. Сначала клиент должен аутентифицироваться в AS, используя имя пользователя и пароль для входа.

После этого AS перенаправляет имя пользователя в KDC, который, в свою очередь, предоставляет TGT. Без выполнения этого первого шага клиент не сможет взаимодействовать с какой-либо другой частью системы Kerberos.

Служба выдачи билетов

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

Затем TGS аутентифицирует TGT и устанавливает сеансовый ключ, совместно используемый сервером и клиентом. Если TGS подтверждает, что клиентский TGT включает доступ к желаемой службе, клиенту предоставляется доступ для запроса услуги.

Как работает Kerberos?

Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:

• Вход пользователя / клиента: на этом этапе происходит взаимодействие между пользователем и клиентом. Пользователь вводит в клиент свое имя пользователя и пароль. Затем клиент преобразует этот пароль в ключ шифрования, хранящийся локально. Если это завершится правильно, клиент может начать аутентификацию с помощью AS.
• Аутентификация клиента / AS: на этом этапе клиент и сервер аутентификации подключаются для аутентификации имени пользователя и проверки того, что они являются частью системы. Затем AS проверяет, что имя пользователя уже задокументировано в системе. В этом случае Клиент и AS обмениваются зашифрованными проверочными сообщениями для проверки друг друга. В конце оба аутентифицируются, соединение устанавливается, и клиент может перейти к аутентификации с помощью службы.
• Аутентификация клиента / службы: на этом этапе клиент и сервер должны аутентифицировать друг друга в соответствии с практикой взаимной аутентификации. Клиент и сервер обмениваются зашифрованными проверочными сообщениями, как на предыдущем этапе. Если все это проходит, клиент и служба аутентифицируются, и клиент получает разрешение запросить их службу.
• Клиент / запрос службы: наконец, клиент может запросить именованную службу у сервера службы. Затем сервисный сервер проверяет, доступна ли запрошенная услуга. Если да, сервер службы предоставляет услугу клиенту. Поскольку клиент прошел аутентификацию на всех этапах этого процесса, он может продолжать использовать службу до истечения срока действия разрешений.

Пример процесса Kerberos

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

В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.

Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.

Затем вы можете получить доступ к этой службе в любое время без необходимости каждый раз аутентифицировать свои разрешения. Однако, если вы попытаетесь получить доступ к любой из служб из financesобласти, вам будет отказано, потому что ваш TGT не имеет ключей к этой области.

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

Разбивка процесса Kerberos (16 шагов)

Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:

1. Войти

Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.

2. Запросы клиентов на сервер выдачи билетов

Затем клиент отправляет серверу аутентификации текстовое сообщение, содержащее:

• введенное имя пользователя
• название запрашиваемой услуги
• сетевой адрес пользователя
• как долго они запрашивают доступ на

3. Сервер проверяет имя пользователя.

Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.

4. Выдача билета. Билет возвращается клиенту.

Сервер аутентификации отправляет клиенту два зашифрованных сообщения:

• Message A может быть расшифрован с помощью секретного ключа клиента, созданного на шаге 1. Он содержит имя TGS, временную метку, время жизни билета и вновь предоставленный сеансовый ключ сервера предоставления билетов.
• Message Bявляется билетом на выдачу билета и может быть расшифрован только с помощью секретного ключа TGS. Он содержит ваше имя пользователя, имя TGS, метку времени, ваш сетевой адрес, время жизни билета и тот же ключ сеанса TGS.

5. Клиент получает сеансовый ключ TGS.

Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.

6. Клиент запрашивает доступ к службе с сервера

Теперь клиент отправляет обратно два сообщения:

• Message Cпредставляет собой незашифрованное сообщение, содержащее имя запрошенной службы, время существования и все еще зашифрованное message B.
• Message D является аутентификатором, зашифрованным с помощью сеансового ключа TGS, и содержит ваше имя и временную метку

7. Сервер проверяет службу.

Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.

8. Сервер получает сеансовый ключ TGS.

Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.

Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.

Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.

9. Сервер генерирует служебный сеансовый ключ.

Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.

• Message E зашифрован с помощью секретного ключа службы и содержит ваше имя, имя запрошенной службы, метку времени, ваш сетевой адрес, время жизни билета и ключ сеанса службы.
• Message Fшифруется с помощью сеансового ключа TGS, хранимого как клиентом, так и сервером. Это сообщение содержит всю ту же информацию, message Eкроме вашего имени пользователя и сетевого адреса.

10. Клиент получает ключ сеанса обслуживания.

Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.

11. Клиент связывается с Сервисом

Теперь клиент отправляет еще два сообщения, на этот раз службе:

• Message G- еще одно сообщение аутентификатора, на этот раз зашифрованное с помощью сеансового ключа службы. Он содержит ваше имя и метку времени.
• Message Hявляется копией message E, которая все еще зашифрована служебным секретным ключом.

12. Расшифровка сервисов Message G

Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.

13. Сервис проверяет запрос

Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.

14. Сервис аутентифицируется для клиента.

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

15. Клиент проверяет услугу.

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

16. Свободное общение между клиентом и службой

Уверенный в том, что и клиент, и служба взаимно аутентифицированы, Kerberos позволяет клиенту связываться со службой.

Можно ли взломать Kerberos?

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

Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:

• Pass-the-ticket: этот метод создает ложный сеансовый ключ путем подделки ложного TGT. Затем хакер может представить TGT службе как действительные учетные данные. Наличие сеансового ключа позволяет этой подделке обходить все этапы проверки Kerberos, которые предшествуют этапу предоставления сеансового ключа.
• Золотой билет: этот метод подделывает билет со статусом администратора. Хакер имеет неограниченный доступ ко всему домену при использовании этого билета; доступны отдельные устройства, серверы, данные и настройки. Хакеры могут создать «золотой билет» только в том случае, если у них есть доступ к машине администратора, обычно через установленное вредоносное ПО.
• Серебряный билет: Подобно атаке Золотого билета, серебряные билеты — это поддельный билет проверки подлинности службы, который предоставляет доступ к службе. Этот метод дает меньший доступ, чем атака по золотому билету, но его также труднее обнаружить. Все взаимодействия на этом этапе являются взаимодействиями клиент / служба, что позволяет хакеру избежать мер безопасности, установленных в KDC.
• Грубая сила: самый очевидный метод, грубая форсировка, включает использование автоматического подбора паролей для ввода тысяч паролей до тех пор, пока не будет найден правильный. Для брутфорса не требуются украденные учетные данные, но его легко обнаружить из-за нечеловеческого поведения при входе.
• Вредоносное ПО с скрытым ключом бэкдора : в этом методе хакеры устанавливают скрытый ключ-ключ доступа к бэкдору в систему, чтобы позволить им войти в систему как любой пользователь в любое время в будущем. Этот метод требует ранее успешной атаки Golden Ticket Attack, поскольку эти скелетные ключи могут быть установлены только с административным доступом. Это одни из самых сложных атак для обнаружения, поскольку взлом и атака могут произойти с разницей в годы.

Что изучать дальше

Поздравляю! Сегодня вы узнали, что такое Kerberos, для чего он используется и какие шаги необходимо предпринять для аутентификации действий.

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

• Управление целостностью сообщения
• Шифрование с открытым ключом
• Методы предотвращения атак
• Меры реагирования на атаки