Почему suser_name () не отражает изменение имени учетной записи AD?

Имена одного из наших пользователей были юридически изменены, поэтому мы изменили их имя в Active Directory для соответствия - с домена \ старое имя на домен \ новое имя. Однако, когда suser_sname () вызывается этим пользователем в хранимой процедуре, он возвращает старое имя, а не новое.

Поиск в Google привел меня к 946358 КБ, в которых говорится, что их имя кэшируется на сервере и не обновляется, предположительно потому, что suser_name () вызывает LsaLookupSids. Однако обходной путь в этой статье включает перезапуск сервера, и даже если бы это было так, я все равно хотел бы понять проблему.

Если я изменю свой контекст на их, вернётся правильное имя:

EXECUTE AS LOGIN = 'domain\newname'
GO
SELECT suser_name()   --returns 'domain\newname'

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

Некоторые наблюдения, которые могут иметь значение:

У этого пользователя нет явного логина на сервере. Но они являются членом группы AD, которая делает. Измененное имя (домен \ новое имя) появится в наборе результатов для exec xp_logininfo 'domain\ADGroupName', 'members'; домен \ старое имя не.
Пользователь вызывает suser_name () из хранимой процедуры, вызываемой из сквозного запроса в MDB Access 2003.
В прошлом мы изменили множество имен учетных записей пользователей, но наблюдали эту проблему только на прошлой неделе (две изменения были сделаны на прошлой неделе, обе, похоже, демонстрируют проблему).
Сервер работает под управлением Sql Server 2008 SP3 x64 в выпуске Windows 2008 R2 Datacenter.

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

— Воин Боб
источник

Служба MSSQLSERVER (или как там называется экземпляр) входит в систему как локальная система или как реальный вход в систему? Значение может быть кэшировано в реестре учетной записи, выполняющей поиск. В вашем случае вы вошли в систему и делаете запрос. Я думаю, что, возможно, если вы используете обычную учетную запись для запуска SQL Server (как следует), то, возможно, войдите в SQL Server как «SQL Server», а затем запустите вашу EXECUTE ASи SELECT SUSER_NAME()протестируйте. Кроме того, вы пробовали SUSER_SNAME()и любые другие 100 вариантов?

— Соломон Руцкий

Попробуйте создать логин на экземпляре, используя новое имя. Это не повлияет на их разрешения. Запустите SUSER_SNAME(), это должно быть исправлено в этой точке. Затем вы можете попробовать сбросить логин и посмотреть, сохранит ли оно новое имя.

— Кеннет Фишер

@srutzky Это экземпляр MSSQLSERVER по умолчанию, работающий под учетной записью домена. К сожалению, у меня нет пароля для входа с ним. Я еще не пробовал suser_sname () как пользователь, я полагаю, что это то же самое, что suser_name (), если не дано никаких аргументов. Хотя стоит попробовать - спасибо!

— Воин Боб

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

— Шон Галларди

Вы можете попробовать запустить ipconfig /flushdnsи ipconfig /registerdnsиз командной строки, чтобы посмотреть, решит ли это проблему.

— RLF

Может ли это быть связано с кэшированием с Kerberos? (хотя предположение может быть и не связано) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Normoe
источник

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

— Воин Боб

Это хорошее предложение, я должен был подумать об этом! :-) Это было то, что мы делали до того, как на самом деле прояснили проблемы с кэшированием Kerberos. Рад, что ты был успешным!

— Нормое