Реализованная в Windows Server 2003 модель безопасности требует, чтобы установлению любого сетевого соединения предшествовала аутентификация всех его участников. Модель безопасности Windows Server 2003 предполагает разграничение доступа на уровне пользователей. В процессе аутентификации одна из сторон (либо каждая из сторон) осуществляет проверку того, что другая сторона действительно является тем, за кого себя выдаёт. Информация, которой обмениваются в процессе аутентификации клиент и сервер аутентификации, может быть перехвачена злоумышленником. Kerberos - это протокол аутентификации, обеспечивающий надёжную аутентификацию всех участников процесса.

Протокол Kerberos был разработан в Массачусетском технологическом институте в начале 80-х. В Windows Server 2003 реализована поддержка протокола Kerberos v5, которая официально заявлена IETF (Internet Engineering Task Force) как стандарт протокола Kerberos в RFC 1510. Этот протокол по умолчанию используется в качестве основного метода аутентификации всех участников соединения в среде Windows Server 2003.

Для аутентификации участников сетевого соединения в среде Windows Server 2003 используются два метода аутентификации: механизм NTML (Windows NT LAN Manager) и протокол аутентификации Kerberos. Механизм аутентификации NTLM используется в качестве основного способа аутентификации пользователей Windows NT и сохранён в Windows 2000 для совместимости с системами на основе этой платформы. Системы под управлением Windows NT могут взаимодействовать с Windows 2000 только с использованием этого метода аутентификации. Этот метод аутентификации по-прежнему используется в среде Windows Server 2003 в качестве основного механизма аутентификации пользователей при регистрации на локальном компьютере. Однако при работе в сети система безопасности требует, чтобы установлению любого сетевого соединения предшествовала аутентификация всех его участников. В Windows Server 2003 в качестве альтернативы механизму NTLM реализована принципиально новая схема аутентификации, более известная под названием протокола аутентификации Kerberos. По сравнению с NTLM-аутентификацией использование протокола Kerberos характеризуется следующими преимуществами:
1. Протокол Kerberos позволяет гаранитировать надёжность соединения, обеспечивая аутентификацию всех участников соединения. Метод NTLM позволяет аутентифицировать только пользователя, инициирующего соединение. Тем не менее он не включает в себя никаких механизмов, гарантирующих пользователю, что он подключился именно к тому серверу, к которому требовалось. Кроме того, в рамках механизма NTLM невозможна надёжная аутентификация серверами друг друга. Это связано с тем, что в системе безопасности Windows NT все серверы считались надёжными и вызывающими доверие.
2. Уменьшение времени аутентификации. Использование протокола Kerberos позволяет серверу приложений выполнять аутентификацию пользователей самостоятельно на основе имеющихся у них полномочий. Данные полномочия выдаются клиенту лишь один раз и используются им в течение всего периода работы в сети.
3. Делегирование процедуры аутентификации. После того как клиент прошёл аутентификацию, службы сервера приложения берут на себя предоставление ему необходимого доступа к ресурсам локального компьютера. Однако часто возникают ситуации, когда в процессе выполнения запроса клиента необходимо получить доступ к ресурсам, расположенным на удалённом компьютере. Протокол Kerberos позволяет службам сервера, выполнившим аутентификацию клиента, выступать его посредником на удалённом компьютере. При этом доступ к ресурсам, находящимся на удалённом сервере, осуществляется в контексте полномочий аутентифицированного пользователя.
4. Транзитивность доверительных отношений. Протокол Kerberos позволяет устанавливать двусторонние транзитивные доверительные отношения. В случае с четырьмя доменами для создания отношений полного доверия вам потребуется установить только три двусторонних доверительных отношения.

В основе протокола Kerberos лежит принцип совместного использования секретного ключа. Каждый из участников соединения удостоверяет свою подлинность фактом знания этого ключа. Любая попытка установить соединение без знания секретного ключа потерпит неудачу. Создатели протокола Kerberos предложили следующее решение. Участник соединения, отправляющий сообщение, подтверждает знание секретного ключа, выполняя с его помощью шифрование сообщения. Участник соединения, которому это сообщение предназначено, в свою очередь, использует секретный ключ, чтобы расшифровать полученное сообщение, и тем самым подтверждает свою подлинность. Для того, чтобы это было возможным, секретный ключ должен быть симметричным, позволяя расшифровать сообщение при помощи того же ключа, что использовался при его зашифровке. В Kerberos используется симметричный алгоритм шифрования DES (Data Encryption Standard) с применением 56- и 128-битных ключей.

Протокол Kerberos использует специальные пакеты, содержащие информацию об участниках соединения, называемых аутентификаторами. Аутентификатор содержит информацию, необходимую для надёжной аутентификации участников соединения и информацию о времени отправки аутентификатора. Получая аутентификатор, участник соединения извлекает эту информацию и сверяет её с показаниями собственных часов. Если разница между этими показаниями и временем, указанным в аутентификаторе, превышает 5 минут, то аутентификатор считается просроченным и соединение отклоняется. Компьютер регистрирует все аутентификаторы, полученные им в течение последних 5 минут. При получении аутентификатора система просматривает журнал, чтобы проверить, не был ли уже получен аутентификатор с таким же временем отправления. Если совпадение найдено - аутентификатор считается ложным и соединение отклоняется. Аналогичным образом будет отклонён аутентификатор с более ранним временем отправления, чем у самого последнего зарегистрированного в журнале аутентификатора. Содержимое аутентификатора должно быть различным при каждом новом обмене сообщениями, чтобы обеспечить уникальность каждого аутентификатора. Это позволяет гарантировать, что, даже будучи перехваченным, аутентификатор не может быть использован в дальнейшем для установления нового соединения. Информация аутентификатора шифруется при помощи секретного ключа, известного только участникам соединения. Участник соединения, предоставляющий доступ к ресурсу, получает аутентификатор и дешифрует его, проверяя таким образом подлинность сообщения. После этого он снова шифрует часть полученной информации при помощи секретного ключа и отправляет получившийся аутентификатор обратно. Участник соединения, запрашивающий ресурс, получает новый аутентификатор и, дешифруя его, проверяет содержащуюся в нём информацию. В случае, если она соответствует той, что была им послана, делается вывод, что второй участник соединения обладает секретным ключом. Таким образом, каждый из участников соединения надёжно аутентифицирует друг друга.

Центральное место в схеме аутентификации Kerberos занимает служба распределения ключей (Key Distribution Center, KDC). Служба распределения ключей выступает в качестве посредника между серверами и их клиентами. Каждое подключение должно иметь уникальный секретный ключ, поскольку к любому серверу может обращаться произвольное число пользователей. Служба распределения ключей решает эту задачу, обеспечивая каждое подобное подключение собственным уникальным ключом, известным только клиенту и серверу. Всё пространство объектов Active Directory поделено на области безопасности Kerberos, в каждой из которых имеются собственные экземпляры службы распределения ключей. Именно KDC осуществляет распределение секретных ключей между всеми субъектами системы безопасности, принадлежащей к одной области. Фактически служба распределения ключей взяла на себя все функции по аутентификации пользователей в среде Windows Server 2003. Поскольку служба распределения ключей тесным образом интегрирована в Active Directory, на каждом контроллере домена может быть запущен экземпляр данной службы, который будет выполнять аутентификацию пользователей. Каждому субъекту безопасности выделяется уникальный секретный ключ, который известен только ему и службе распределения ключей. Этот ключ принято называть долговременным ключом. Создавая данный ключ, служба основывается на информации о субъектах системы безопасности, содержащейся в каталоге Active Directory.

Долговременный ключ используется службой распределения ключей для создания специальных пакетов, называемых сеансовыми билетами. Прежде чем любой из субъектов системы безопасности сможет установить соединение с другим субъектом, он должен получить сеансовый билет (session ticket) представляет собой специальный пакет, выдаваемый службой распределения ключей для взаимной аутентификации участников точечного соединения "субъект-субъект". Любой билет, используемый протоколом Kerberos, включает в себя информацию, достаточную не только для функционирования механизма аутентификации, но также и для организации процесса авторизации пользователя. Поскольку каждый субъект системы безопасности имеет свой уникальный секретный ключ, сеансовый билет выступает в качестве носителя секретных ключей обоих участвующих в соединении субъектов. Часть сеансового билета не шифруется (оставляется открытой). В открытой части сеансового билета содержится имя области Kerberos (домена), в которой создан билет, а также основное имя субъекта (principal name), с которым клиент хочет установить соединение. Другая часть сеансового билета шифруется при помощи специального ключа, известного тому участнику соединения, который выступает получателем данного билета. Шифрование данных применяется для того, чтобы предотвратить перехват этих данных. В зашифрованной части сеансового билета располагается информация, используемая субъектами при установлении соединения. Сеансовый билет включает в себя следующую информацию:
1.Срок жизни сеансового билета. Для отображения этой информации в билет включается время начала и окончания его использования. Ограничение срока жизни сеансового билета позволяет уменьшить риск взлома шифра сеансового билета. Для взлома 128-битного шифра, в зависимости от имеющихся вычислительных ресурсов, может потребоваться определённое время, которое, скорее всего превысит время жизни сеансового билета.
2.Сеансовый ключ. В сеансовый билет помещается секретный ключ субъекта, инициирующего соединение. Поскольку эта информация помещается в зашифрованную часть билета, даже перехват билета не гарантирует возможность получить этот ключ.
3.Имя области Kerberos и основное имя субъекта. Эта информация сверяется с той, что содержится в открытой, не зашифрованной, части сеансового билета.
4. Данные, необходимые для авторизации пользователя. Авторизация пользователя подразумевает присвоение ему определённых прав доступа. Следует заметить, что Kerberos является протоколом аутентификации и не осуществляет авторизацию пользователя. Однако механизмы аутентификации Kerberos могут снабжать службы авторизации сервера всей необходимой информацией, помещая требуемые данные в зашифрованную часть сеансового билета. Прежде всего, это данные об идентификаторе безопасности пользователя (SID), его привилегиях и членстве в различных группах.
5.Флаги билетов Kerberos. Флаги позволяют службе распределения ключей задать определённые свойства билета. В стандарте протокола RFC 1510 описаны возможные флаги билета.

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

Открытая (незашифрованная) часть билета включает:
1. Tkt-Vno - элемент билета, указывающий версию протокола Kerberos. Указывание номера версии протокола позволяет приложению Kerberos верно определить формат билета, который различается от версии к версии. Для протокола Kerberos v5 этот параметр равен 5.
2.Realm - имя области Kerberos, в которой данный билет был создан. Поскольку в среде Windows Server 2003 область Kerberos совпадает с доменом, фактически этот элемент отражает имя домена Windows Server 2003. Служба распределения ключей может выдавать билеты только для серверов, принадлежащих к собственной области Kerberos.
3. Sname - основное имя сервера (server principal name), с которым клиент хочет установить соединение. В случае билета-запроса здесь указывается имя контроллера домена, выполняющего функции службы распределения ключей.

Закрытая (зашифрованная) часть билета включает в себя:
1.Flags - флаги, определяющие характеристики билета. Каждый флаг может принимать одно из двух значений: 1 - флаг установлен, 0 - флаг отключён.
2. Key - сеансовый ключ, используемый для установления соединения клиента с данным сервером (при этом говорят, что клиент разделяет этот ключ с указанным сервером).
3. Crealm - имя области Kerberos, участвующих в аутентификации клиента, владеющего данным билетом. Фактически данное поле содержит имя домена Windows Server 2003.
4. Cname - основное имя клиента (client principal name).
5. Transited - список областей Kerberos, участвующих в аутентификации клиента, владеющего данным билетом.
6. Authtime - время начальной аутентификации клиента. Служба распределения ключей включает эту информацию в билет-запрос в момент его создания. Впоследствии, когда клиент запрашивает соединение со службой удалённого сервера, эта информация копируется и в сеансовый билет.
7. Starttime - время, начиная с которого билет считается действительным.
8. Endtime - время окончания срока действия билета.
9. renew-till - необязательный параметр, указывающий максимальное время жизни билета с установленным флагом RENEWABLE.
10.Caddr - необязательный элемент, содержащий список возможных сетевых адресов (один адрес или более) клиента. При этом действительными будут считаться лишь те билеты, которые пришли только из указанных адресов. Таким образом можно обеспечить дополнительную безопасность соединения. Если данный параметр не указан, действительными считаются любые адреса.
11.Authorization-data - данные, используемые службой для авторизации клиента. При этом сам протокол Kerberos никоим образом не интерпретирует эти данные. Вся информация этого поля передаётся для авторизации непосредственно службе удалённого компьютера.

В состав любого билета Kerberos может входить несколько флагов. В зависимости от назначения билета в его состав могут входить следующие флаги:
1.INITIAL - установка данного флага превращает обычный сеансовый билет в билет-запрос. Именно поэтому данный флаг установлен в любом билете-запросе и снят в обычных сеансовых билетах.
2.FORWARDABLE - флаг, свойственный только билету-запросу, указывающий службе предоставления билетов на то, что данный билет-запрос может быть использован другим участником соединения для получения нового билета.
3.FORWARDED - установка данного флага свидетельствует о том, что данный билет запрос был либо перенаправлен, либо создан при помощи билета-запроса с установленным флагом FORWARDABLE.
4.PROXIABLE - флаг билета-запроса, сигнализирующий службе предоставления билетов о том, что при создании сеансового билета можно использовать сетевой адрес, отличный от тех, что указаны в параметре Caddr билета-запроса.
5.PROXY - установка данного флага показывает, что сетевой адрес билета отличается от адресов, перечисленных в параметре Caddr билета-запроса, использованного для получения данного билета.
6.RENEWABLE - установленный флаг свидетельствует о том, что включён режим периодического обновления сеансового ключа.

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

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

В стандарте протокола Kerberos для получения билета-запроса не обязательно включать в аутентификатор какую-либо информацию о клиенте. Тем не менее система безопасности Windows Server 2003 всегда использует этот приём, чтобы удостоверить личность клиента. Однако служба распределения ключей может принимать запросы от клиентов протокола Kerberos, не включающих в аутентификатор соответствующей информации. В этом случае проверка правильности пароля происходит в момент получения клиентом зашифрованного сеансового ключа. Не зная правильного пароля, пользователь не сможет извлечь этот ключ, и как следствие, не будет иметь возможности запрашивать билеты для соединения с другими службами.

Этот этап получил название взаимодействия со службой аутентификации (Authentication Service Exchange). Клиентская часть протокола Kerberos отправляет запрос службе аутентификации Kerberos. В этот запрос включаются данные, необходимые для начальной аутентификации клиента. Служба аутентификации извлекает данные из полученного пакета и, просматривая собственную базу данных, производит аутентификацию пользователя. В случае успешной проверки служба аутентификации создаёт билет-запрос, необходимый для соединения со службой предоставления билетов. Для обеспечения безопасности этого соединения служба аутентификации генерирует специальный сеансовый ключ. Получив ответный пакет, клиент извлекает из него сеансовый ключ и билет-запрос, помещает полученный билет и ключ в специальный кэш, чтобы иметь возможность многократно их использовать, без необходимости повторного обращения к службе аутентификации.

Когда клиент хочет установить соединение с сервером, он отправляет службе распределения ключей соответствующее обращение. В обращение включается билет-запрос, информация о сервере, с которым клиент хочет установить соединение, а также аутентификатор. Отправка аутентификатора необходима для того, чтобы служба распределения ключей могла удостовериться, что клиент именно тот, за кого себя выдаёт (для проверки используется время и сеансовый ключ, содержащийся в теле аутентификатора). Получив от клиента билет-запрос, служба распределения ключей дешифрует его при помощи известного только ему секретного ключа. Служба извлекает из билета-запроса сеансовый ключ и сравнивает его с ключом, полученным из аутентификатора. В случае идентичности двух этих ключей служба распределения ключей делает вывод, что билет-запрос пришёл от клиента, прошедшего аутентификацию. Такие меры предосторожности необходимы для того, чтобы предотвратить возможность использования злоумышленником перехваченного билета-запроса. Поскольку перехват аутентификатора, в силу его уникальности, не даёт злоумышленнику возможности воспользоваться им, служба распределения ключей может прибегнуть к его помощи, чтобы удостоверить подлинность билета-запроса. После того как вся процедура проверки подлинности билета-запроса успешно пройдена, служба распределения ключей отправляет клиенту запрошенный сеансовый ключ для установки соединения с требуемой службой на удалённом компьютере. Часть информации, включаемая в создаваемый сеансовый билет, наследуется им от билета-запроса (сведения о клиенте и данные, необходимые для его авторизации). Остальная информация (время жизни создаваемого билета и сеансовый ключ для соединения между клиентом и запрашиваемой службой сервера) генерируется в момент создания билета.

Сеансовый ключ (ключ для взаимодействия между клиентом и удалённым сервером) генерируется случайным образом каждый раз, когда клиент запрашивает билет на установление соединения. Для установления соединения между клиентом и службой удалённого компьютера созданный билет может использоваться многократно в пределах срока его жизни. Однако каждый раз, когда клиент обращается с запросом на получение сеансового билета, служба распределения ключей генерирует новый сеансовый ключ. Это означает, что если клиент дважды обратился к службе распределения ключей с запросом билета на установление соединения с одной и той же службой, он получит два билета с различными сеансовыми ключами. Таким образом гарантируется уникальность сеансовых ключей в каждом сеансовом билете.

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

Этот этап в структуре протокола Kerberos получил название взаимодействия со службой предоставления билетов (Ticket-Granting Service Exchange). Имея билет-запрос, клиент может обращаться к службе предоставления билетов для получения необходимых сеансовых билетов. При этом клиент посылает запрос службе предоставления билетов, в который включает аутентификатор, билет-запрос, полученный от службы аутентификации, а также имя службы, с которой клиент хочет установить соединение. Служба предоставления билетов проверяет информацию, содержащуюся в запросе, и создаёт запрашиваемый клиентом сеансовый билет. При этом службой предоставления билетов генерируется соответствующий сеансовый ключ. Вся эта информация отправляется клиенту в ответном пакете службы предоставления билетов. Получив зашифрованный сеансовый билет и расшифровав его при помощи сеансового ключа, клиент может инициализировать соединение со службой удалённого компьютера. Клиент посылает соответствующий сеансовый билет и аутентификатор. Служба удалённого компьютера получает пакеты и извлекает при помощи собственного секретного ключа сеансовый ключ, который будет использоваться в процессе взаимодействия с клиентом. При этом осуществляется проверка того, что сеансовый ключ, извлечённый из билета, совпадает с сеансовым ключом, включённым в аутентификатор. Сеансовый билет генерируется службой распределения ключей. Клиент не может каким-либо образом изменить содержимое сеансового билета, поскольку оно шифруется при помощи секретного ключа, который ему не известен. С другой стороны, клиент генерирует аутентификатор, включая в него известную только ему информацию. Поэтому факт совпадения ключей говорит о подлинности клиента. Если процедура проверки заканчивается успешно, процедура аутентификации заканчивается и клиент устанавливает соединение со службой сервера. Данные, необходимые для авторизации пользователя, извлекаются службой удалённого компьютера из сеансового билета, и на основании этих данных пользователю назначаются определённые права и привилегии. Если необходимо, чтобы клиент аутентифицировал службу, с которой он устанавливает соединение (взаимная аутентификация), ему возвращается модифицированный аутентификатор. Каждый раз когда клиенту необходимо установить соединение с удалённой службой, он использует соответствующий билет. При этом нет необходимости заново обращаться к службе распределения ключей за выделением нового сеансового билета. Клиент хранит сеансовый билет в специальном кэше и может использовать его на протяжении всего срока жизни. Аналогично службам удалённого сервера нет нужды каким-либо образом организовывать хранение всех поступающих билетов. Служба сервера каждый раз заново извлекает сеансовый ключ из поступившего билета.

Данный этап получил название взаимодействия клиента с удалённой службой (Client/Server Exchange). Получив ответный пакет службы предоставления билетов, клиент извлекает из него сеансовый билет, который использует для соединения с удалённой службой. При этом клиент формирует запрос приложению Kerberos. Служба удалённого сервера извлекает из запроса всю информацию, необходимую для аутентификации и авторизации пользователя. Для проверки подлинности билета и аутентификатора используется факт знания сеансового ключа и информация о времени отправления запроса. В случае если аутентификация заканчивается успешно, пользователь получает доступ в рамках имеющихся у него прав. Если клиент требует взаимной аутентификации, служба сервера формирует ответный пакет приложения Kerberos. В ответный пакет включается информация о времени отправления клиентом запроса. Используя эту информацию, клиент может убедиться в том, что служба удалённого компьютера владеет сеансовым ключом и способна расшифровать аутентификатор клиента.

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

Когда клиенту требуется установить соединение с сервером в другом домене, он обращается к собственной службе распределения ключей. В обращении он просит выделить билет-запрос, необходимый для соединения со службой распределения ключей другого домена. Тело билета шифруется секретным ключом, полученным службами распределения ключей обоих доменов при создании между ними двусторонних доверительных отношений. Этот билет-запрос клиент предъявляет службе распределения ключей другого домена, получая взамен сеансовый билет для соединения с требуемым сервером. В остальном процесс установления соединения аналогичен ситуации, когда клиент и сервер находятся в одном домене. прежде чем пользователь сможет обращаться с запросами на получение билетов, необходимых для установления соединения с удалёнными службами, он должен получить билет-запрос. Для этого он должен продемонстрировать знание пароля, соответствующего его основному имени (principal name). Не выполнив этого требования, он не сможет установить ни одного соединения в среде Kerberos.

Существует особый класс клиент/серверных приложений, характерной особенностью которых является возможность выполнения многоточечных соединений. Протокол Kerberos предоставляет возможность осуществлять подобные запросы, реализуя механизм делегирования аутентификации. Делегирование может осуществляться двумя способами:
1. Использование прокси-билета. Если политика Kerberos допускает использование прокси-билетов, служба распределения ключей устанавливает флаг PROXIABLE  в каждом создаваемом билете-запросе. Используя подобный билет-запрос, клиент может запрашивать у службы распределения ключей специальный прокси-билет. В своём запросе клиент должен указать имя как первого, так и второго сервера. В ответ на запрос служба распределения ключей создаёт специальный сеансовый билет с установленным флагом PROXY. Недостатком этого метода делегирования можно считать то, что клиент должен сразу явно указать имя второго сервера. Таким образом, создаётся жесткая клиент-первый сервер-второй сервер. Этот способ применяется тогда, когда доподлинно известны все три участника подобного соединения. 2. Перенаправление билета-запроса. Этот метод делегирования аутентификации заключается в перепоручении первому серверу части обязанностей клиента, касающихся получения сеансового билета, необходимого для соединения со вторым сервером. Клиент отправляет запрос службе распределения ключей на создание специального билета-запроса, поддерживающего возможность перенаправления. В ответ служба распределения создаёт подобный билет-запрос и устанавливает в нём соответствующий флаг FORWARDABLE. В процессе соединения с сервером клиент передаёт ему данный билет-запрос, а также сеансовый ключ, используемый для соединения клиента со службой распределения ключей. Сервер, с которым клиент установил соединение, в свою очередь, может использовать полученный от клиента билет-запрос для обращения к службе распределения ключей. Цель этого обращения - получить сеансовый билет, необходимый для соединения первого сервера со вторым сервером. При этом запрос сеансового билета производится непосредственно от лица клиента (поскольку билет-запрос принадлежит непосредственно ему). Преимуществом этого метода является то, что клиенту не требуется точно знать имя второго сервера в момент соединения с первым сервером. Клиент просто перенаправляет билет-запрос серверу и доверяет ему процесс получения всех необходимых сеансовых билетов.

Реализация протокола Kerberos в операционной системе Windows Server 2003 имеет ряд специфических особенностей. Протокол Kerberos в Windows Server 2003 реализован в виде двух основных компонентов: службы распределения ключей и модуля обеспечения безопасности.

Служба распределения ключей (Key Distribution Center) реализована в среде Windows Server 2003 в виде двух системных служб: службы аутентификации (Authentication Service) и службы предоставления билетов (Ticket-Granting Service). Обе службы Kerberos запускаются автоматически при запуске системы и не могут быть остановлены. Служба распределения ключей функционирует на каждом контроллере домена, предоставляя тем самым любому контроллеру домена возможность создавать и распространять билеты. Это позволяет более равномерно распределить нагрузку, вызванную процессом аутентификации пользователей, между всеми контроллерами домена. В домене все экземпляры службы распределения ключей выступают как один субъект системы безопасности с основным именем (principal name) krbtgt. Учётная запись для этого субъекта создаётся одновременно с созданием домена и не может быть каким-либо образом изменена и удалена. Пароль, соответствующий данной учётной записи, генерируется случайным образом и регулярно меняется. Пользователь в своих обращениях к службе распределения ключей указывает имя учётной записи субъекта безопасности krbtgt и имя домена, к которому принадлежит эта учётная запись. Поскольку все экземпляры службы распределения ключей функционируют под одной учётной записью, Windows Server 2003 использует службу DNS для того, чтобы обнаружить ближайший к пользователю контроллер домена. Для данного пользователя всегда будет отдаваться предпочтение службе распределения ключей, расположенной именно на этом контроллере домена. В этом случае говорят о предпочтительной (preferred) службе распределения ключей. Если предпочтительная служба распределения ключей по каким-либо причинам окажется недоступной, система выберет для аутентификации пользователя другой контроллер домена. Служба распределения ключей использует службу каталогов Active Directory  в качестве своей базы данных. Каждый субъект системы безопасности выступает в качестве объекта Active Directory. Информация, используемая исключительно протоколом Kerberos хранится в виде атрибута объекта. Служба распределения ключей, в целях безопасности, не может обмениваться этой информацией с Active Directory по сети, а должна взаимодействовать со службой каталогов локально. Поскольку копия Active Directory содержится только на контроллерах домена, служба распределения ключей также располагается исключительно на контроллерах домена.

Если служба распределения ключей выполняет функции начальной аутентификации пользователей и распределения билетов, обязанности по аутентификации участников соединения берёт на себя модуль обеспечения безопасности (Security Support Provider, SSP). В Windows Server 2003 также присутствует модуль обеспечения безопасности и для метода аутентификации Windows NT LAN Manager. Оба этих модуля активизируются при загрузки системы. При этом компьютер может осуществлять аутентификацию при помощи любого из этих двух методов, в зависимости от того, какой метод выберет компьютер, инициирующий соединение. По умолчанию всегда используется метод аутентификации Kerberos. Аутентификация любого субъекта системы безопасности осуществляется путём взаимодействия с интерфейсом модуля обеспечения безопасности (Security Support Provider Interface, SSPI). Интерфейс модуля обеспечения безопасности представляет собой Win32 интерфейс между приложениями транспортного уровня и различными модулями обеспечения безопасности. Этот интерфейс поддерживается практически всей линейкой операционных систем Windows. При использовании SSPI от субъекта не требуется знание и понимание всех деталей механизма аутентификации. Субъект лишь производит вызов соответствующих методов SSPI, всю остальную работу по аутентификации берёт на себя модуль обеспечения безопасности. Субъект может только судить о процессе аутентификации по конечному результату - установленному либо отклонённому соединению с другим объектом. На каждом компьютере с загруженным модулем обеспечения безопасности имеется специальный кэш, получивший название кэша полномочий (credentials cache). Основное назначение кэша полномочий - хранение сеансовых ключей и билетов, полученных от службы распределения ключей, в течение всего срока их жизни. Помимо этого к кэш помещается и криптографический ключ, полученный из пароля, введённого пользователем при входе в систему. Пока клиент не получит от службы распределения ключей билет-запрос, этот ключ будет выполнять функции долговременного ключа. В момент когда пользователь покидает систему, вся информация, находящаяся в кэше полномочий, безвозвратно уничтожается. Кэш полномочий располагается в невыгружаемой области памяти, защищенной локальной службы безопасности (Local Security Authority, LSA). При этом доступ к любой информации, содержащейся в кэше полномочий, может получить только модуль обеспечения безопасности Kerberos, запущенный в контексте локальной службы безопасности.

Протокол аутентификации Kerberos функционирует только в рамках стека протоколов TCP/IP. В стандарте RFC 1510 для организации взаимодействия отдельных компонентов Kerberos используется протокол UDP (User Datagram Protocol). Реализация Kerberos  в Windows Server 2003 допускает взаимодействие модулей обеспечения безопасности Kerberos со службой распределения ключей двумя способами: при помощи UDP-дейтаграмма и посредством TCP-пакетов. Протокол UDP не ориентирован на установление соединения. Это означает, что передача информации осуществляется без всякой проверки того, достигает ли она адресата. Участники соединения просто обмениваются сообщениями, называемыми дейтаграммами. За счёт этого UDP является более быстрым протоколом, чем TCP. Контроль доставки информации полностью перекладывается на протоколы верхних уровней, которые должны обеспечить повторную передачу информации в случае, если дейтаграмма не достигла адресата. Однако при этом необходимо учитывать, что использование UDP эффективно, когда вся информация дейтаграммы передаётся в виде одного фрейма (единый блок данных, передаваемых на канальном уровне модели OSI). Следовательно, различные компоненты Kerberos должны обмениваться между собой пакетами, не превышающими размер фрейма. Для сетей Ethernet максимально допустимый размер передаваемого блока данных (Maximum Transmission Unit, MTU) равен 1500 октетам (октет равен 8 битам). Компоненты Kerberos, входящие в состав Windows Server 2003, осуществляя передачу сообщений, включают в них информацию, необходимую для авторизации субъекта системы. Это приводит к тому, что размер сообщения превышает максимально допустимый размер фрейма. Поэтому компьютеры, находящиеся под управлением операционной системы Windows Server 2003, осуществляют взаимодействие с другими компонентами Kerberos при помощи транспортного протокола TCP. Компьютеры, находящиеся под управлением других операционных систем, не требуют данных авторизации и поэтому могут использовать дейтаграммы UDP.

Прежде чем пользователь сможет что-либо предпринять в системе Windows Server 2003, он должен войти в систему, предоставив информацию об имени своей учётной записи и соответствующем ей пароле. Вход в систему начинается с нажатия комбинации клавиш Ctrl+Alt+Del. Нажатие этой комбинации клавиш (называемой Security Attention Sequence, SAS) приводит к генерации определённого прерывания. Это прерывание обрабатывается непосредственно системой, что позволяет гарантировать защиту от различного вредоносного ПО. Система, обрабатывая прерывание, предлагает пользователю ввести имя учётной записи и соответствующий пароль в диалоговом окне Logon Information. При этом пользователь должен указать домен, к которому принадлежит его учётная запись. После того как пользователь ввёл всю необходимую информацию и нажал кнопку OK, процесс управления входом в систему Winlogon вызывает локальную службу безопасности (Local Security Authority, LSA), чтобы произвести проверку введённой информации и на её основе произвести авторизацию пользователя. Проверка производится согласно общей схеме функционирования протокола Kerberos. Прежде чем установить соединение с одной из служб сетевого компьютера, пользователь должен пройти процесс аутентификации. Для получения доступа к любым ресурсам сети, пользователю необходимо установить соединение со службой Workstation локального компьютера. Однако для установления соединения с этой службой пользователь должен иметь соответствующий сеансовый билет. Получение всех необходимых билетов LSA поручает модулю обеспечения безопасности Kerberos, который осуществляет взаимодействие со службой распределения ключей. В случае если пользователь ввёл верную информацию, он проходит начальную аутентификацию и получает билет-запрос, который использует для получения необходимого сеансового билета. Сеансовый билет содержит всю необходимую для авторизации пользователя информацию. Эту информацию LSA  извлекает из билета и передаёт диспетчеру безопасности учётных записей (Security Account Manager, SAM) локального компьютера. Диспетчер, используя полученные из билета данные авторизации, создаёт маркер доступа (SID) пользователя, а также идентификаторы безопасности всех групп, членом которых он является. Созданный маркер доступа LSA возвращает процессу управления входом в систему Winlogon. В последствии каждый процесс, активизированный пользователем, наследует копию его маркера доступа. Таким образом гарантируется, что пользователь сможет получить доступ к объектам только в рамках имеющихся у них прав.

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

Управление параметрами протокола Kerberos осуществляется через механизм групповых политик следующими параметрами:
1. Enforce logon user restrictions. В случае если данная опция установлена, пользователь обязательно должен войти в сеть, прежде чем может запросить у службы распределения ключей билет.
2. Maximum lifetime for service ticket. Определяет максимальный срок жизни сеансового билета, выделенного службе.
3. Maximum lifetime for user ticket. Определяет максимальный срок жизни сеансового билета, выделенного пользователю.
4. Maximum lifetime for user ticket renewal. Определяет максимальный срок жизни, который может иметь обновляемый билет, выделенный пользователю.
5. Maximum tolerance for computer clock synchronization. Для того чтобы механизм аутентификации Kerberos правильно функционировал, внутренние часы на всех компьютерах должны быть обязательно синхронизированы. При помощи данного параметра администратор может указать максимально допустимую разницу в показаниях часов компьютеров.