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

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

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

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

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

Ответ 1

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

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

Билет может иметь продолжительность жизни 10 часов, но это время с момента его выдачи. Он может иметь только часть того, что осталось после того, как пользователь выполнит запрос.

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

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

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

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

Ответ 2

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

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

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

Мне бы хотелось, чтобы я мог больше помочь, а также размещать код, а не статьи, но, как вы исследуете, вы увидите, что это ошибка проверки подлинности Kerberos. Удачи!

Ответ 3

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

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

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

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

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