.NET Remoting дает ошибку KRB_AP_ERR_MODIFIED

Question

У нас есть ошибка в нашем приложении, я надеюсь, что кто-то может помочь. Вот краткое изложение того, что происходит:

1) Наше приложение имеет трехуровневую архитектуру - приложение Silverlight, веб-уровень и базовый бизнес-логический уровень.

• Уровень бизнес-логики (в основном устаревший код) работает как служба Windows.
• У нас есть один сервис для каждого клиента.
• В системе имеется несколько серверов бизнес-логики, каждая из которых выполняет несколько служб Windows для наших клиентов.
• Приложение браузера Silverlight будет связываться с веб-уровнем через набор веб-сервисов WCF, и веб-уровень будет связываться с бизнесом с помощью .NET Remoting.
• Службы Windows каждого клиента устанавливают TCP-порт для удаленного доступа к конечным точкам при его запуске.
• Роль веб-уровня заключается в получении входящего запроса и маршрутизации его к правильному сервису.

2) У нас есть спорадическая проблема в нашем приложении SilverLight. Пользователи получат сообщение в интерфейсе, в котором говорится: «Не удается открыть журнал для источника ExceptionManagerInternalException». Возможно, у вас нет доступа на запись »или« Сбой вызова SSPI, см. Внутреннее исключение ». Обе ошибки вызваны одной и той же проблемой, пользователи с правами администратора в системе будут видеть второе сообщение,« обычные »пользователи-клиенты будут видеть первый.

3) Более подробную информацию об этой ошибке можно увидеть в журналах событий на веб-сервере. В системном журнале событий, мы видим:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED от ааа $. В качестве целевого имени использовался HOST/bbb.cab.local. Это указывает, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это может произойти, если имя участника-целевого сервера (SPN) - , зарегистрированное в учетной записи, отличной от учетной записи, которой предназначена целевая услуга: . Убедитесь, что целевой SPN зарегистрирован, и зарегистрировано только , учетная запись, используемая сервером. Эта ошибка также может быть вызвана , если целевая служба использует другой пароль для учетной записи целевой службы , чем то, что для центра распределения ключей Kerberos (KDC) для целевой учетной записи службы. Убедитесь, что служба на сервере и KDC обновлены для использования текущего пароля . Если имя сервера не полностью определено, а целевой домен (domain.LOCAL) отличается от домена клиента (domain.LOCAL), проверьте, есть ли одинаковые имена серверов в этих двух доменах или используйте полностью -qualified для идентификации сервера .

4) Мы захватили файлы трассировки, которые позволили нам увидеть события, которые происходят, когда мы получаем эту ошибку:

• Вызов SOAP приходит в Web API (WCF)
• A Идентификатор клиента восстанавливается из заголовка http. Идентификатор клиента позволяет нам однозначно идентифицировать пользователя, работающего в экземпляре браузера, и был помещен в заголовок, когда клиент впервые зашел в систему.Когда они вошли в систему, мы также кэшировали идентификатор клиента вместе с сервисом, к которому они подключаются, на веб-сервере. Это реализовано в поведении WCF на нашей конечной точке.
• Используя этот поиск, адрес системы (то есть имя сервера и порт tcp) и SPN службы (HOST \) помещаются в хранилище потоков.
• Мы использовали ведение журнала (NLOG), чтобы подтвердить, что этот процесс происходит.
• Код на веб-уровне затем сделает вызов .NET Remoting на сервер.
• Затем код в веб-уровне делает вызовы .NET Remoting для уровня бизнес-логики. В ClientChannelSink мы получаем адрес сервера и SPN из хранилища потоков и настраиваем удаленный вызов для перехода к правильному адресату. Трассы NLOG подтвердили, что правильные данные извлекаются из хранилища потоков и используются для настройки вызова. Мы увидели трассировку, когда запрос UserA@domain.local был сделан, чтобы перейти к aaa, используя SPN HOST \ aaa).
• С трассировки сетевого монитора мы можем увидеть пакеты DNS и верные IP-адреса для имен серверов.
• Из трассировки сетевого монитора мы видим, что запрос на авторизацию Kerberos отправляется в DC.
• Этот запрос будет содержать SPN для другого сервера, чем ожидалось (в нашей трассе запрос, запрошенный для HOST \ bbb)
• Служба билетов Kerberos возвращает действительный билет Kerberos для пользователя (UserA@domain.local) для запрошенной услуги (HOST \ bbb)
• Запрос отправляется ожидаемой службе (сервер aaa), используя действительный билет Kerberos за неправильную услугу.
• Служба (на сервере aaa) отклоняет запрос. Это законно, так как билет Kerberos для не HOST \ ааа, но HOST \ ГЭБ

Я не думаю, что какой-либо из «советов» в журнале событий является причиной этой проблемы: - Мы не У нас нет дублирующих SPN в нашей системе - Оба компьютера находятся в одном домене - Проблема носит спорадический характер; проблемы, перечисленные в сообщении, выглядят так, что они будут вызывать полный сбой все время.

Я читал об агитировании потоков asp.net, но я не думаю, что это вызывает эту проблему, поскольку мы всегда отправляем наш запрос на правильный сервер, но с неправильным билетом Kerberos. Если мы использовали «неправильные» настройки из хранилища потоков, мы отправили запрос на неправильный сервер с соответствующим билетом Kerberos для этого сервера. Любая помощь делу или как исследовать это дальше будет очень ценится.

Answer 1

Я не уверен в вашем интерфейсе бэкэнд, но вам не нужно явно пропускать сам билет Kerberos. Вам просто нужно создать директиву Windows и определить, хотите ли вы разрешить олицетворение на своем сервере. Если это так, то вы должны доверять определенной службе для делегирования, создав SPN в домене.

У вас есть SPN, определенный для учетной записи и адреса уровня бизнес-уровня/уровня данных HOST \ aaa-сервера в домене?

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