Мне непонятно, что вы можете и не можете сделать со своим вариантом использования, но я могу ответить на вопрос для чего предназначалась делегация Kerberos.
Сначала поговорим о том, что делает Kerberos до делегирования. Важно хорошо понимать эту часть, потому что она неуловима.
Kerberos проверяет подлинность ОБА концов связи между двумя конечными точками в сети, эти конечные точки могут быть интерактивными пользователями или службами, работающими на компьютере.
Это строгая аутентификация , поэтому она не допускает атаку "человек посередине" в любой форме. При правильной настройке конечная точка может гарантировать, что они не будут скомпрометированы. На уровне имени службы (если вы подключаетесь к II на компьютере, это отличается от подключения к SQL Server на том же компьютере). Он интенсивно использует современные методы шифрования и требует использования безопасных сертификатов. Детали протокола аутентификации сложны и не стоит вдаваться в подробности, но он включает в себя около 20 различных отдельных этапов подтверждения между двумя конечными точками аутентификации и сервером аутентификации (в окнах контроллер домена является сервером аутентификации).
Так какого чёрта это делегирование?
Делегирование - это расширение Microsoft к стандарту Kerberos, которое
позволяет доверенному источнику продолжить аутентификацию для другого
оконечный.
Это позволяет вам действовать как «человек посередине» - однако многие параметры должны быть явно настроены, установлены сертификаты и т. Д., Чтобы это работало. Это далеко не просто. (РЕДАКТИРОВАТЬ: Вот еще один SO ответ на детали - https://stackoverflow.com/a/954154/215752)
Так, например, вы можете попросить кого-нибудь пройти аутентификацию на веб-сайте, а затем подключить код .NET к SQL Server КАК ТО ЖЕ ПОЛЬЗОВАТЕЛЬ для чтения данных с правами этого пользователя.
Теперь, чтобы ответить на ваш вопрос, поскольку я не уверен, что вы хотите сделать, я предлагаю три варианта:
1) Вы хотите подключиться к бэкэнд-системе как тот же пользователь, что и пользователь, аутентифицирующийся на сайте.
- В этом случае делегирование Kerberos идеально - оно делает именно то, что вы хотите.
2) Вы хотите подключиться к серверной системе как другой пользователь, а не тот, кто проходит аутентификацию на веб-сайте (например, учетная запись службы).
- В этом случае вы не хотите делегировать. Kerberos для веб-сайта и Kerberos (как другой пользователь) для серверной части будут отлично работать.
3) Вы хотите подключаться к серверной системе как один и тот же пользователь, а иногда как другой пользователь. (Например, вам нужно подтвердить, что это законный пользователь для серверной системы, но в другое время вы хотите выполнять доверенные действия в качестве системной учетной записи. Это (по моему опыту) наиболее распространенный вариант использования.)
- В этом случае вы используете оба. Делегирование для соединений, которые должны подтвердить личность пользователя, а затем вернуться к идентификатору учетной записи службы для тех случаев, когда вам необходим системный доступ к серверной части. (Мой предыдущий вопрос касался подробностей о том, как вернуться к идентификатору системы на платформе .NET, см. Как «отменить олицетворение» (без делегирования?) В Kerberos .)