IIS, возвращающий старые имена пользователей в мое приложение

Вот мой сценарий. Для работы я создал приложение, использующее встроенную проверку подлинности Windows. В Application_AuthenticateRequest() я использую HttpContext.Current.User.Identity для получения текущего WindowsPrincipal пользователя моего веб-сайта.

Теперь вот смешная часть. Некоторые из наших пользователей недавно вышли замуж, и их имена изменились. (то есть пользовательский вход пользователя NT изменяется с jsmith на jjones), и когда мое приложение проверяет их подлинность, IIS передает мне свой OLD LOGIN. Я продолжаю видеть, что jsmith передано моему приложению, пока я не перезагружу свой СЕРВЕР! Выход из системы не работает. Перезапуск пула приложений не работает. Только полная перезагрузка.

Кто-нибудь знает, что здесь происходит? Есть ли какая-то команда, которую я могу использовать для очистки любого кеша, который дает мне эту проблему? Не настроен ли мой сервер?

Примечание. Я определенно НЕ хочу перезапускать IIS, мои пулы приложений или машину. Поскольку это производственная коробка, это не очень эффективные варианты.

AviD -

Да, их UPN был изменен вместе с их именем входа. И Mark/Nick... Это сервер корпоративного производства... Его нельзя просто перезагрузить или перезапустить IIS.

Последующие (для потомков):

Ответ Grhm был спот-на. Эта проблема возникает на серверах с низким объемом, где у вас не так много людей, использующих ваши приложения, но достаточно запросов, чтобы сохранить личность пользователей в кеше. Ключевая часть KB, которая, похоже, описывает, почему элемент кэша не обновляется после того, как по умолчанию 10 минут:

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

Я не совсем уверен, что в нашем коде вызывало это (повторяющиеся запросы), но разрешение, которое сработало для нас, заключалось в том, чтобы вырезать значение LsaLookupCacheExpireTime из кажущегося непристойным дефолтом в течение 1 недели всего за несколько часов, Это, для нас, уменьшает вероятность того, что пользователь будет воздействовать на реальный мир, по существу, на ноль, и в то же время не вызывает чрезмерного количества поисков SID-имен против наших серверов каталогов. Еще лучшее решение IMO было бы, если бы приложения искали информацию пользователя по SID вместо сопоставления пользовательских данных с текстовым именем входа. (Обратите внимание, поставщики! Если вы полагаетесь на аутентификацию AD в своем приложении, вам нужно поместить SID в свою базу данных аутентификации!)

Ответ 1

У меня были похожие проблемы в последнее время и, как указано в ответе Robert MacLean , изменения политики группы AviD не работают, если вы не вошли в систему как пользователи.

Я нашел изменение размера LSA Lookup Cache, как описано MS KB946358 работал без перезагрузки или утилизации любого приложения или услуг.

Я нашел это в качестве ответа на этот похожий вопрос: Неверная аутентификация после изменения имени пользователя для входа в систему.

Ответ 2

Проблема как AviD - это кеш Active Directory, который вы можете контролировать с помощью реестра. В зависимости от вашего решения параметры политики группы Avid не работают или работают в зависимости от того, действительно ли вы регистрируете пользователей или нет.

Как он кэшируется, зависит от того, как вы выполняете аутентификацию в IIS. Я подозреваю, что это может быть Kerberos, чтобы сделать очистку, если она вызвана Kerberos, вы можете попробовать klist с опцией очистки, которая должна чистить билеты kerberos, которые заставят reauth к AD выполнить следующую попытку и обновить детали.

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

Ответ 3

Я знаю, что в прошлом у меня были проблемы с кэшированием учетных данных в IIS, а после Googling в течение нескольких дней мы сталкивались с неясной (по крайней мере) командой, которую вы можете использовать для просмотра и очистки кэшированных учетных данных.

Пуск → Выполнить (или WinKey + R) и введите control keymgr.dll

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

Ответ 4

Если это не проблема изменения только имени пользователя NT, то похоже, что служба аутентификации кэширует старое имя пользователя.
Вы можете определить, что это отключено, перейдите в "Локальные параметры безопасности" (в "Администрирование" ), и в зависимости от версии/издания/конфигурации наиболее важными параметрами (из памяти) являются "Количество предыдущих входов в систему" и "Сделать не позволяют хранить учетные данные...".

Дополнительные факторы, которые необходимо учитывать:

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

Как таковой, я рекомендую вам сначала протестировать это перед развертыванием на производстве (конечно).

Ответ 5

Перезапуск IIS, а не всей машины, должен сделать трюк.

Ответ 6

Когда имена пользователей были изменены, вы изменили только их имена имен NT или их имена UPN? имена UPN являются собственными именами и используются Kerberos - который является стандартным протоколом для IWA; однако, если вы просто нажмете, чтобы изменить свое имя в ActiveDirectory, изменится только имя входа NT, даже если это то, что они будут использовать для входа в систему (используя Windows GINA по умолчанию). Под обложками окна будут переводить (новое) имя входа NT в (старое) имя Kerberos. Это сохраняется до тех пор, пока AD не будет принудительно обновлять имя Kerberos в соответствии с именем входа NT...

Ответ 7

Эта ссылка "Изменение интервала по умолчанию для пользовательских токенов в IIS" из поддержки MicroSoft должен помочь.

Ответ 8

Войдите на сервер, который запускает IIS, используя новое имя для входа. Это обновит учетные данные без повторного запуска IIS или перезагрузки сервера.

Ответ 9

Так же, как FYI, у нас была такая же проблема. То, что, похоже, сработало для нас, - это войти в Active Directory и выполнить "Обновить". Сразу после этого нам пришлось переработать пул приложений на сайтах интрасети, у которых была эта проблема.