IIS возвращает старые имена пользователей в мое приложение
https://stackoverflow.com/questions/168946
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Вот мой сценарий.Я создал приложение, которое для работы использует встроенную проверку подлинности Windows.В Application_AuthenticateRequest(), Я использую HttpContext.Current.User.Identity чтобы получить текущий WindowsPrincipal пользователя моего сайта.
А теперь самое смешное.Некоторые из наших пользователей недавно поженились, и их имена изменились.(т.е.Логин пользователя NT изменится с jsmith к jjones), и когда мое приложение аутентифицирует их, IIS передает мне их OLD LOGIN .Я продолжаю видеть jsmith передавался в мое приложение, пока я не перезагружу свой СЕРВЕР!Выход из клиента не работает.Перезапуск пула приложений не работает.Только полная перезагрузка.
Кто-нибудь знает, что здесь происходит?Есть ли какая-то команда, которую я могу использовать для очистки любого кеша, вызывающего у меня эту проблему?Мой сервер неправильно настроен?
Примечание:Я определенно НЕ хочу перезапускать IIS, мои пулы приложений или компьютер.Поскольку это производственная коробка, такие варианты не являются жизнеспособными.
АвиД -
Да, их UPN был изменен вместе с их именем для входа.И Марк/Ник...Это сервер производственного предприятия...Его нельзя просто перезагрузить или перезапустить IIS.
Последующие действия (для потомков):
Ответ Грма был точен.Эта проблема возникает на серверах с небольшим объемом трафика, где не так много людей используют ваши приложения, но делается достаточно запросов, чтобы сохранить личность пользователей в кеше.Ключевая часть КБ который, кажется, описывает, почему элемент кэша не обновляется после 10 минут по умолчанию:
Время ожидания записей кэша истекает, однако есть вероятность, что они повторяются Запросы со стороны приложений поддерживают существующую запись кэша для Максимальное время существования записи кэша.
Я не совсем уверен, что в нашем коде вызывало это (повторяющиеся запросы), но решение, которое сработало для нас, состояло в том, чтобы сократить LsaLookupCacheExpireTime значение от, казалось бы, непристойного значения по умолчанию, равного 1 неделе, до нескольких часов.Для нас это снижает вероятность того, что пользователь пострадает в реальном мире, практически до нуля, и в то же время не вызывает чрезмерного количества поисков SID-имени на наших серверах каталогов.Еще лучшим решением, по моему мнению, было бы, если бы приложения искали информацию о пользователе по SID вместо сопоставления пользовательских данных с текстовым именем входа.(Обратите внимание, продавцы!Если вы используете аутентификацию AD в своем приложении, вам нужно поместить SID в свою базу данных аутентификации!)
Решение
У меня были похожие проблемы в последнее время, и как указано в ответ , изменения в групповой политике AviD не будут работать, если вы не входите в систему как пользователь.
Я обнаружил изменение размера кэша поиска LSA , как описано в MS KB946358 работал без перезагрузки или утилизации каких-либо приложений или служб.
Я нашел это как ответ на этот похожий вопрос: Неправильная аутентификация после изменения имя пользователя для входа .
Возможно, вы захотите взглянуть на следующие системные вызовы, такие как следующие:
LookupAccountName()
LookupAccountSid()
LsaOpenPolicy()
Вы можете использовать их для написания приложения на C ++ / CLI (/ Managed-C ++) для опроса кеша LSA.
Другие советы
Проблема, описанная AviD , связана с кешем Active Directory, которым можно управлять с помощью реестр . В зависимости от вашего решения параметры групповой политики Avid не будут работать или будут работать в зависимости от того, действительно ли вы входите в систему или нет.
Как он кэшируется, зависит от того, как вы проходите аутентификацию в IIS. Я подозреваю, что это может быть Kerberos, поэтому для очистки, если он вызван Kerberos, вы можете попробовать klist с опцией очистки, которая должна очистить билеты Kerberos, что приведет к повторному обращению к AD при следующей попытке и обновлению информации.
Я бы также посоветовал взглянуть на реализацию этой , что немного более сложный, но гораздо менее подверженный ошибкам.
Я знаю, что в прошлом у нас тоже были проблемы с кэшированием учетных данных в IIS, и после нескольких дней поиска в Google мы обнаружили неясную (по крайней мере для нас) команду, которую можно использовать для просмотра и очистки кэшированных учетных данных.
Start - > Запустите (или WinKey + R) и введите control keymgr.dll
Это исправило наши проблемы с клиентскими машинами. Не пробовал его на серверах, но, возможно, стоит попробовать, если это учетные данные кэширования сервера. Наша проблема заключалась в том, что мы получали старые учетные данные, но только на клиентской машине. Если пользователь вошел в систему на отдельном клиентском компьютере, все было в порядке, но если они использовали свой собственный компьютер на своем рабочем столе, на котором они обычно работают, имели старые кэшированные учетные данные.
Если дело не в изменении только имени пользователя NT, то похоже, что служба аутентификации кэширует старое имя пользователя.
Вы можете отключить эту функцию, перейдите в «Локальные настройки безопасности» (в разделе «Администрирование»), и в зависимости от версии/выпуска/конфигурации настройки, которые могут быть релевантными (из памяти): «Количество предыдущих входов в систему для кэширования» и «Выполнить» не разрешать хранение учетных данных...».
Дополнительные факторы, которые следует учитывать:
- Членство в домене может повлиять на это, поскольку рядовые серверы могут наследовать настройки домена.
- Возможно, вам все равно придется один раз перезапустить весь сервер, чтобы это вступило в силу (но тогда вам не придется беспокоиться об обновлениях в будущем).
- Это может повлиять на производительность входа в систему.
Поэтому я рекомендую вам сначала протестировать это перед развертыванием в рабочей среде (конечно).
Перезапуск IIS, а не всей машины, должен помочь.
Когда имена этих пользователей были изменены, вы меняли только их логин NT или их имена UPN? имена UPN являются собственными именами и используются Kerberos - протоколом по умолчанию для IWA; однако, если вы просто нажмете, чтобы изменить их имя в ActiveDirectory, изменится только имя для входа в NT - даже если это то, что они будут использовать для входа (используя стандартные окна GINA). Под крышками окна будут переводить (новое) имя входа NT в (старое) имя Kerberos. Это продолжается до тех пор, пока AD не будет вынуждено обновить имя Kerberos в соответствии с именем входа NT ...
Эта ссылка " Изменение интервала по умолчанию для пользовательских токенов в IIS " из поддержки MicroSoft должно помочь.
Войдите на сервер, на котором работает IIS, используя новое имя входа. Это обновит учетные данные без перезапуска IIS или перезагрузки сервера.
Так же, как к вашему сведению, у нас была точно такая же проблема. То, что нам показалось удачным, - это зайти в Active Directory и выполнить команду «Обновить». Сразу после этого нам пришлось перерабатывать пул приложений на сайтах интрасети, где возникла эта проблема.
