237

стему. Однако некоторые части этих процессов, инициируемые до отправления пакета, остаются неизменными.

8.3.2.1. Локальный интерактивный вход в систему

При локальном интерактивном входе в систему пользователь подключается по учетной записи с локального компьютера, а не по учетной записи домена (рис. 8.12).

Рис. 8.12. Локальный интерактивный вход в систему

При использовании локальной учетной записи в Windows происходит следующее:

1.Получив запрос на вход в систему, модуль идентифика-

ции Graphical Identification and Authentication DLL (GINA) передает его службе Local Service Authority (LSA). Kerberos в запросе указывается как аутентификационный пакет, так как в Windows он является таковым по умолчанию.

2.LSA обрабатывает запрос и посылает его Kerberos.

3.В ответ на этот запрос Kerberos возвращает сообщение об ошибке, поскольку он предназначен для аутентификации не локальных, а доменных учетных записей.

4.LSA получает это сообщение об ошибке и возвращает его GINA.

238

5. GINA повторно посылает запрос LSA с указанием «MSV1_0» в качестве аутентификационного пакета. Затем процесс входа в систему происходит так же, как в Windows NT 4.0.

8.3.2.2. Интерактивный вход в домен

Обмены при входе в Windows 2000-2003 пользователя с доменной учетной записью похожи на стандартные обмены в

Kerberos (рис. 13).

Рис. 8.13. Интерактивный вход в домен

Вход в домен осуществляется следующим образом:

1. Получив запрос на вход в систему, служба Local Service Authority (LSA) передает его Kerberos. Клиент посылает исходный AS-запрос службе Kerberos, сообщая ей имя пользователя и имя домена. Это служит запросом на аутентификацию и TGT. Запрос осуществляется с применением основного имени krbtgt@<имя_домена>, где <имя_домена> — это имя домена,

которому принадлежит учетная запись пользователя. Первый контроллер домена автоматически создает учетную запись krbtgt@<имя_домена>.

2. Служба Kerberos генерирует AS-ответ, содержащий TGT (зашифрованный секретным ключом Kerberos) и сеансовый ключ для обменов TGS (зашифрованный секретным ключом клиента), и отсылает его клиенту. Данные авторизации в составе TGT включают SID для учетной записи пользователя и SID для

239

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

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

4.Служба Kerberos генерирует и посылает ответ TGS. Он содержит билет на рабочую станцию и другую информацию, в частности сеансовый ключ (зашифрованный сеансовым ключом

сTGT). В данные авторизации включаются SID для учетной записи пользователя и всех глобальных групп, скопированные

службой Kerberos с оригинального TGT.

5. Пакет аутентификации Kerberos возвращает список SID

на LSA.

Для аутентификации службы Windows используют интерфейс SSPI режима ядра.

Вместо соединения с Kerberos напрямую обе службы получают доступ к нему через аутентификационный пакет согла-

сования, встроенный в LSA (Negotiate package).

При загрузке системы службы Server и Workstation инициализируют их интерфейс с пакетом согласования в LSA с помощью SSPI. При этом служба сервера п олучает идентификационные описатели для билетов по умолчанию.

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

8.3.2.3. Поддержка открытого ключа в Kerberos

Windows расширяет функциональность Kerberos и разрешает Kerberos взаимодействовать со службой Active Directory.