Ниже мое понимание о делегировании Kerberos:
1] Неограниченное делегирование (W2000): Windows 2000 позволяет авторизованному пользователю пересылать TGT: он запрашивает перенаправляемый TGT (АутентификацияСлужба), а затем может запросить переадресованный TGT (Служба предоставления билетов).Он может просто переслать этот TGT (с сеансовым ключом) в службу (сообщение krb_cred).Служба может затем запросить услугу по продаже билетов от имени пользователя для любой службы и может, в свою очередь, также перенаправить TGT с сеансовым ключом пользователя к любой другой услуге [билеты на проксимальные / прокси-серверы выходят за рамки, поскольку, похоже, они не используются из-занеобходимые условия],
2] Ограниченное делегирование (начиная с W2003): ИТ-администратор может настроить службу в AD (SPN) для авторизации запроса службы билетов от именипользователя для набора услуг (SPN): параметр «Allowed To-Delegate-To» (A2D2).Кроме того, новые расширения (S4U2Proxy) позволяют службе запрашивать службу заявок от имени пользователя для другой службы, поскольку она может представить действительный и пересылаемый билет от имени пользователя для себя (таким образом, это означает, что существуетбольше не нужно получать TGT от пользователя и связанного с ним сеансового ключа).Чтобы получить перенаправляемый билет для себя, служба должна быть помечена как «Trusted-To-Authenticate-For-Delegation» (T2A4D),
3] Протокол перехода (S4U2self) (так какW2003): Служба может запрашивать у KDC службу билетов (для себя) от имени пользователя, не предъявляя KDC никаких свидетельств того, что пользователь был аутентифицирован Kerberos.Это можно сделать, установив флажок «Использовать любой протокол» в конфигурации SPN в AD.Затем он мог бы использовать ограниченное делегирование, если для этой службы установлены надлежащие флаги (T2A4D и A2D2),
4] Кросс-домены ограниченного делегирования (начиная с W2012):
¤ Там, где раньше было невозможно использовать делегирование кросс-доменов (поскольку невозможно установить SPN из текущего домена SPN), теперь можно настроить авторизацию на целевой службе, а не на исходной службе (концептуально этоболее логично).
specific Конкретный SID ($$) может быть настроен на целевой службе для авторизации или без делегирования, когда пользователь не был явно аутентифицирован KDC (это означает, что когда служба использовала свою способность перехода по протоколу для получениябилет для себя): для того, чтобы это работало, это означает (я полагаю), что служба билетов, предоставленная исходной службе для целевой службы, содержит эту информацию
Что мне не ясно:
1) После прочтения статей MS я понимаю, что перенаправленные TGT нельзя использовать для ограниченного делегирования, хотя в TGT явно есть флаг «переадресованный».На самом деле, это совсем другое дело по сравнению со службой, которая использует свой собственный TGT со службой заявок для себя, потому что в случае TGT пользователя служба аутентифицируется как пользователь, который запрашивает билет службы.Есть ли смысл в использовании «поля адреса» запроса билета, которое должно содержать IP / DNS-адрес запрашивающей стороны (это, конечно, можно изменить)?Есть ли какой-либо параметр, чтобы отклонить запрос билета при использовании перенаправленного TGT?Почему бы не использовать поле адреса (клиент), чтобы проверить связанные права?Это потому, что он ненадежен (адрес может быть подделан) или потому, что он недостаточно точен, чтобы идентифицировать имя участника-службы?
2) Введение SID ($$) подразумевает для меня, что пересылаемый билет службы действительно содержит определенныйинформация о том, что этот билет был получен через расширения S42Uself или был получен непосредственно пользователем.Но я не знаю, что это такое,
3) Перенаправленные TGT кажутся «устаревшими», если это означает, что делегирование не может быть ограничено.Итак, я не понимаю, почему существует одна пересылаемая и одна пересылаемая TGT (так же для делегирования), когда я отображаю свои кэшированные билеты с помощью klist (машина Windows 10 в корпоративной среде, и это для двух разных компаний).Это стандартная и рекомендуемая практика или я что-то пропустил?
Большое спасибо за ваш отзыв !!Хорошего дня.
Арахнид.