Хранение аутентификации Kerberos для последующего олицетворения

Question

Можно ли сохранить билет Kerberos, чтобы позже использовать его для олицетворения пользователя?

У меня есть сценарий, когда пользователь напрямую вызывает внешнюю систему для обработки некоторых данных. Внешняя система полагается на то, что пользователь правильно олицетворяется / аутентифицируется в AD.

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

Учитывая, что я не могу изменить внешнюю систему и не могу сохранить имя пользователя и пароль в очереди, могу ли я сохранить билет Kerberos, когда пользователь добавляет новые рабочие элементы в очередь, а затем выдавать себя за пользователя службой, когда он передает данные во внешнюю систему. Как бы я это сделал в C #?

Answer 1

• Редактировать: Это самый близкий вопрос, который я могу получить к вашему актуальному вопросу: можете ли вы создать отдельный поток под олицетворением, сделать запрос оттуда, сколько бы времени это ни заняло?Под прикрытием это будет делать то, что нужно (если, конечно, процесс обслуживания не будет прерван).

Как однажды сказал нам один парень из Microsoft, «безопасность - это то, что останавливает работу вашего приложения при его развертывании.».(Его целью было проверить с реалистичной настройкой безопасности).

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

Я предлагаю вам просто решить основную проблему другим способом.

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

• Можете ли вы увеличить или уменьшить аппаратное обеспечение?Обычно это самый дешевый способ.
• У вас действительно есть совершенно разные разрешения, или пользователи распределяются по конечному числу ролей?Если в ролях вы можете записать роль, в которой был пользователь, и использовать специально созданные имена пользователей для доступа к внешней службе, по одной для каждой роли.
• Является ли внешняя служба вашей?Можете ли вы добавить опцию «притвориться Бобом», которая не зависит от олицетворения Windows?
• Можете ли вы запустить отдельный поток под олицетворением, сделать запрос оттуда, сколько бы времени это ни заняло?Затем отправить его обратно пользователю?(да, это будет под прикрытием делать то, что вы просите)
• Наконец, вы можете поместить пользователя в браузерную «очередь продовольствия».Т.е. выдайте им номер, затем обновите браузер каждые 10 секунд (или используйте Ajax), чтобы сообщить им, сколько людей впереди в очереди.Когда наступит их очередь, подайте реальный запрос под видом олицетворения.(Это требует от них держать окно браузера открытым во время ожидания в очереди, а также требует, чтобы вы отслеживали невыполненные запросы и активные браузеры по сравнению с ушедшими браузерами).Противно, но сработает.

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

Answer 2

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

Вот как осуществляется переход по протоколу, при котором учетные данные, отличные от Windows (например, на общедоступном веб-сайте), могут быть сопоставлены с пользователем домена, который выдал себя за доступ к внутренним ресурсам.

Предупреждение: очевидно, что это огромная потенциальная дыра в безопасности, и учетной записи, выполняющей процесс, который вызывает LsaLogonUser, нужно предоставить SeTcbPrivilege («Действовать как часть операционной системы»).

Если есть способ хранения билета, это, очевидно, будет намного лучше, но первое, что я подумал, когда увидел вопрос, была проблема времени истечения, о которой упоминал @Ben.

Edit: Пара из превосходных статей о передаче протокола и ограниченном делегировании с широким охватом связанных рисков.

Answer 3

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

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

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

Хотелось бы, чтобы я мог больше помочь, и публиковать код, а не статьи - но как только вы исследуете, вы увидите, что это проклятие аутентификации Kerberos. Удачи!