1. Введение в Kerberos

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

2. Порт связи Kerberos

1) Порт TCP/UDP 88 (Kerberos): аутентификация и предоставление билетов.

2) Порт TCP/UDP 464: протокол Kerberos Kpaswd (сброс пароля).

3）LDAP：389。

4）LDAPS：636。

3. Существительные, специфичные для Kerberos.

4. Ролевой компонент Kerberos.

Как показано на рис. 1-1, компонент роли Kerberos включает следующие части.

1) KDC: KDC является частью ADDS (службы каталогов AD) и работает на каждом контроллере домена. Он предоставляет билеты сеансов и временные ключи сеансов пользователям и компьютерам в домене, а его сервисная учетная запись — krbtgt.

2) AS: Служба аутентификации, которая выполняет первоначальную аутентификацию и выдает пользователям билеты.

3) TGS: Служба авторизации билетов, которая выдает билеты на услуги на основе разрешений билетов, удостоверяющих личность пользователя.

4) Клиент. Под клиентом понимается пользователь, которому необходим доступ к ресурсам, например просмотр общих файлов, запросы к базам данных или удаленные подключения. Клиентам необходимо пройти аутентификацию перед доступом к ресурсам.

5) Сервер: соответствует определенным службам на компьютерах домена. Каждая служба имеет уникальный SPN.

Рис. 1-1 Компоненты роли Kerberos

5. Обзор процесса аутентификации Kerberos

Kerberos — это метод аутентификации на основе билетов. Когда клиенту необходимо получить доступ к службе на сервере, ему необходимо получить билет службы ST (Service Ticket). Другими словами, клиенту необходимо подготовить ST перед доступом к услуге, и он ждет, пока служба проверит ST перед доступом. Однако этот билет нельзя получить напрямую. Для подтверждения личности клиента требуется TGT (билет на получение билета). Другими словами, клиент должен сначала получить TGT, чтобы подтвердить свою личность, прежде чем получать ST. Как TGT, так и сервисный билет ST выдаются KDC (Центр распространения ключей). Поскольку KDC работает на контроллере домена, контроллер домена выдает как TGT, так и билет службы ST. Ниже приводится обзор процесса Kerberos.

1) Когда пользователь входит в систему, временная метка шифруется с использованием хэша NTLM, чтобы доказать KDC, что он знает пароль. Этот шаг называется «предварительной аутентификацией».

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

3) Когда пользователь желает пройти аутентификацию в службе, он представляет TGT службе TGS KDC. Если TGT действителен и у пользователя есть разрешение на использование службы, пользователь получает билет службы (ST) от Службы предоставления билетов (TGS).

4) Пользователи могут предоставить ST службе, к которой они хотят получить доступ, которая может аутентифицировать пользователя и принимать решения об авторизации на основе данных, содержащихся в TGS.

6. Подробное объяснение процесса аутентификации Kerberos.

（1）AS_REQ & AS_REP (Взаимодействие между клиентом и AS)

1)АС_РЕQ. Когда пользователь в домене вводит учетную запись и пароль на клиенте и хочет получить доступ к службе в домене, клиент отправляет запрос аутентификации Authenticator в AS. Запрос аутентификации содержит шифрование NTLM-HASH клиента. , имя пользователя, IP-адрес хоста и некоторая другая информация о параметрах, такая как тип сообщения, номер версии, параметры согласования и т. д., служат учетными данными для запроса аутентификации. Поскольку необходимо проверить, является ли AS подлинной, для шифрования используется NTLM-HASH клиента. Если это подлинная AS, AS_REQ будет расшифрован обычным образом.

2)АС_РЕП. Когда служба аутентификации AS в KDC получает запрос AS_REQ клиента, KDC проверяет, находится ли пользователь клиента в белом списке AD. Если он находится в белом списке AD, используйте ключ пользователя клиента для расшифровки запроса предварительной аутентификации Authenticator. В случае успеха служба аутентификации AS генерирует случайный ключ сеанса (CT_SK), шифрует ключ сеанса (CT_SK) с использованием NTLM-хеша пароля пользователя и использует NTLM учетной записи по умолчанию krbtgt. Хэш шифрует sessionKey, информацию о клиенте, временную метку клиента и время истечения срока действия аутентификации для получения TGT (билета предоставления билета), а затем отправляет клиенту ответный пакет AS_REP.

（2）TGS_REQ & TGS_REP (Взаимодействие между клиентом и TGS)

1) ТГС_РЕQ. Когда клиент получает соответствующий пакет от службы аутентификации AS, клиент будет использовать свой собственный NTLM-хеш для расшифровки двух частей содержимого зашифрованного текста, чтобы получить ключ SessionKey (CT_SK), используемый для связи с TGS, и кэш TGT клиента SessionKey. (билет предоставления билета), а затем клиент использует SessionKey (CT_SK) для шифрования запроса аутентификации Аутентификатора и отправляет его в TGS в KDC для получения прав доступа к Серверу. Аутентификация аутентификатора включает имя участника-клиента, временную метку, имя принципала SS, отправленное клиентом, время жизни, аутентификатор и TGT.

2) ТГС_РЕП. Когда TGS получает запрос аутентификации аутентификатора, отправленный TGS_REQ, он проверяет свое имя участника SS. Если проверка существует, TGS использует NTLM учетной записи krbtgt. Хэш расшифровывает TGT и извлекает SessionKey. В то же время он также проверяет информацию о клиенте, такую ​​как срок действия TGT, имя клиента в аутентификации Authenticator и является ли TGT тем же самым. пройдет, TGS будет случайным. Создайте новую строку Sessionkey и верните клиенту следующие две части.

• Имя участника SS, Timestamp (метка времени), Lifetime (время жизни) и новый SessionKey, зашифрованный старым SessionKey.
• Билеты, созданные с помощью шифрования хэша сервера, в основном включают имя субъекта клиента, зашифрованное ключом SS, имя субъекта SS, IP_List, Timestamp, Lifetime и новый SessionKey.

（3）AP-REQ & AP-REP (Взаимодействие между клиентом и сервером)

1)AP-REQ. После получения ответа TGS клиент расшифровывает ключ сеанса сервера через SessionKey и использует его для шифрования в аутентификаторе. Аутентификатор включает в себя имя участника клиента, временную метку, ClientAuthenticator и служебный билет, которые отправляются на SS (сервер).

2)АП-РЕП. После получения запроса AP-REQ от клиента сервер расшифровывает билет службы ST с помощью ключа службы и извлекает информацию ключа сеанса службы. В то же время он также проверяет время истечения срока действия TGT и аутентификации аутентификатора. Убедитесь, что имя участника-клиента совпадает с TGT и другой информацией о клиенте. После успешной проверки сервер проверит, требуется ли для конфигурации опции согласования в пакете запроса AP-REQ проверка личности сервера. Если она настроена на проверку личности сервера, сервер будет использовать Service SessionKey. снова для расшифрованного аутентификатора. Шифрование отправляется клиенту через ответный пакет AP-REP. Клиент использует кэшированный ключ сеанса службы для расшифровки. Если содержимое точно такое же, как и раньше, он может доказать, что к серверу он обращается. имеет тот же ключ сеанса службы, что и он сам.

Я участвую в пятом выпуске специального учебного лагеря Tencent Technology Creation 2024 с эссе, получившими награды. Приходите и разделите приз со мной!