У меня вопрос о кэше LSA SID на рядовом сервере домена. Недавно я столкнулся с проблемой, когда некоторые пользователи после того, как их имя было изменено в AD, испытывают трудности с доступом к приложению, которое я поддерживаю, и у них также отображается старое имя пользователя на сайтах SharePoint.
После некоторого поиска / исследования я обнаружил следующее Microsoft KB 946358 и я оказался причиной.
Эта статья немного лаконична и просто говорит о том, что
Записи в кеше истекают по тайм-ауту, однако есть вероятность, что повторяющиеся запросы приложений сохранят существующую запись кэша в течение максимального времени жизни записи кэша.
и предлагает отключить этот кеш на рядовом сервере, установив LsaLookupCacheMaxSize ключ реестра для 0 который отключает локальный кеш LSA.
Это немного странный вариант, поскольку он может сказаться на производительности и не выглядит реальным решением. Погуглить с помощью LsaLookupCacheMaxSize как ключевое слово, с которым многие люди сталкиваются с этой проблемой, но я не нашел окончательного объяснения того, как ее решить.
Итак, я подтверждаю, что отключение локального кеша LSA помогает - но это не вариант для реальных производственных сред, также перезапуск сервера очистит этот кеш - не очень хорошее решение также перезагружать сервер приложений каждый раз, когда пользователь был переименован. Благодаря этому Сообщение блога Я нашел жизнеспособное решение, но все еще заинтересован в том, чтобы решить эту проблему должным образом.
Как я видел эту проблему с приложением только в живой среде, тогда как то же приложение в тестовой среде не имеет такой проблемы (переименованный пользователь работает, старая запись не застревает в кеше), тогда как обе эти среды принадлежат одной и той же домен, и те же пользователи использовались для тестов. Это хорошо согласуется с формулировкой MS KB о том, что некоторые действия приложения могут привести к хранению записи в кеше навсегда, но что дальше? Только еще вопросы ...
Как я могу это воспроизвести?
LsaLookupCacheExpireTime имеет значение по умолчанию 7 дней, поэтому даже не очень активное приложение будет касаться его в течение этого периода, и это не должно вызывать такой проблемы, верно? Я имею в виду, что после того, как приложение запрашивает его, рядовой сервер не должен снова увеличивать TTL записи кеша в течение 7 дней, верно? В противном случае каждая запись будет в кеше навсегда ... И опять же, что мешает серверу рядового домена иногда переходить к DC и, если обнаруживается несоответствие записей, очищать неправильную запись в кеше?
Глядя на время сообщений о подобных проблемах (нет недавних сообщений / вопросов по этому поводу), возможно, они были решены каким-то патчем MS или в более новых версиях Windows Server (в моем случае я видел эту проблему на Windows Server 2008 SP1 Standard, тестовая среда - 2008 SP1 Enterprise).
У меня есть идея, что я могу использовать Procmon для отслеживания пути кэша LSA и определения того, какое приложение слишком часто касается записи в кеше, но неясно, каким может быть мой следующий шаг, поскольку я не понимаю, какие именно условия требуются для сохранения этой записи в кеше навсегда ... Слепое уменьшение этой активности / изменение настроек приложения тоже кажется не очень хорошим решением ....
Короче говоря, я хочу иметь возможность воспроизвести это, то есть понять, при каких условиях устаревшая запись в кеше для переименованного пользователя «застревает» в локальном кеше. Буду признателен, если кто-нибудь сможет пролить здесь свет.