Вот мой сценарий. Для работы я создал приложение, использующее встроенную проверку подлинности 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 в свою базу данных аутентификации!)
У меня были похожие проблемы в последнее время и, как указано в ответе Robert MacLean , изменения политики группы AviD не работают, если вы не вошли в систему как пользователи.
Я нашел изменение размера LSA Lookup Cache, как описано MS KB946358 работал без перезагрузки или утилизации любого приложения или услуг.
Я нашел это в качестве ответа на этот похожий вопрос: Неверная аутентификация после изменения имени пользователя для входа в систему.
Проблема как AviD - это кеш Active Directory, который вы можете контролировать с помощью реестра. В зависимости от вашего решения параметры политики группы Avid не работают или работают в зависимости от того, действительно ли вы регистрируете пользователей или нет.
Как он кэшируется, зависит от того, как вы выполняете аутентификацию в IIS. Я подозреваю, что это может быть Kerberos, чтобы сделать очистку, если она вызвана Kerberos, вы можете попробовать klist с опцией очистки, которая должна чистить билеты kerberos, которые заставят reauth к AD выполнить следующую попытку и обновить детали.
Я также предложил бы взглянуть на реализацию этого, который немного сложнее, но гораздо меньше подвержен ошибкам.
Я знаю, что в прошлом у меня были проблемы с кэшированием учетных данных в IIS, а после Googling в течение нескольких дней мы сталкивались с неясной (по крайней мере) командой, которую вы можете использовать для просмотра и очистки кэшированных учетных данных.
Пуск → Выполнить (или WinKey + R) и введите control keymgr.dll
Это фиксировало наши проблемы для клиентских машин. Не пробовал это на серверах, но это может стоить того, если его учетные данные кэширования сервера. Наша проблема заключалась в том, что мы получали старые учетные данные, но только на основе клиентской машины. Если пользователь вошел в систему на отдельной клиентской машине, все было в порядке, но если бы они использовали свою собственную машину за своим столом, на которой они обычно работали, у нее были кэшированные старые учетные данные.
Если это не проблема изменения только имени пользователя NT, то похоже, что служба аутентификации кэширует старое имя пользователя.
Вы можете определить, что это отключено, перейдите в "Локальные параметры безопасности" (в "Администрирование" ), и в зависимости от версии/издания/конфигурации наиболее важными параметрами (из памяти) являются "Количество предыдущих входов в систему" и "Сделать не позволяют хранить учетные данные...".
Дополнительные факторы, которые необходимо учитывать:
Как таковой, я рекомендую вам сначала протестировать это перед развертыванием на производстве (конечно).
Перезапуск IIS, а не всей машины, должен сделать трюк.
Когда имена пользователей были изменены, вы изменили только их имена имен NT или их имена UPN? имена UPN являются собственными именами и используются Kerberos - который является стандартным протоколом для IWA; однако, если вы просто нажмете, чтобы изменить свое имя в ActiveDirectory, изменится только имя входа NT, даже если это то, что они будут использовать для входа в систему (используя Windows GINA по умолчанию). Под обложками окна будут переводить (новое) имя входа NT в (старое) имя Kerberos. Это сохраняется до тех пор, пока AD не будет принудительно обновлять имя Kerberos в соответствии с именем входа NT...
Эта ссылка "Изменение интервала по умолчанию для пользовательских токенов в IIS" из поддержки MicroSoft должен помочь.
Войдите на сервер, который запускает IIS, используя новое имя для входа. Это обновит учетные данные без повторного запуска IIS или перезагрузки сервера.
Так же, как FYI, у нас была такая же проблема. То, что, похоже, сработало для нас, - это войти в Active Directory и выполнить "Обновить". Сразу после этого нам пришлось переработать пул приложений на сайтах интрасети, у которых была эта проблема.