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

Question

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

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

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

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

---

AviD -

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

---

Продолжение (для потомков):

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

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

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

Answer 1

В последнее время у меня были похожие проблемы, и, как указано в ответе Роберта Маклина , изменения в групповой политике AviD не будут работать, если вы не входите в систему как пользователь.

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

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

Возможно, вы захотите взглянуть на следующие системные вызовы, такие как следующие:

LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()

Вы можете использовать их для написания приложения на C ++ / CLI (/ Managed-C ++) для опроса кеша LSA.

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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