Чому suser_name () не відображатиме зміну назви облікового запису AD?

Ім’я одного з наших користувачів було юридично змінено, тому ми змінили ім’я користувача Active Directory на відповідність - від домену \ oldname до домену \ newname. Однак, коли suser_sname () викликає цей користувач у збереженій процедурі, він повертає стару назву, а не нову.

Гуглінг привів мене до KB 946358, що говорить про те, що їх ім'я кешується на сервері та не оновлюється, імовірно, тому, що suser_name () викликає LsaLookupSids. Однак вирішення цієї статті передбачає перезапуск сервера, і навіть якщо це було б, я все одно хотів би зрозуміти проблему.

Якщо я зміню свій контекст на їхній, повернеться правильна назва:

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

... Я би припустив, що це також буде викликати LsaLookupSids, і тому поверне неправильне ім'я. Здається, ймовірно, що я не дуже розумію механізми роботи тут.

Деякі спостереження, які можуть мати значення:

Цей користувач не має явного входу на сервер. Але вони є членом групи AD, яка це робить. Змінене ім'я (домен \ нове ім'я) відображається в наборі результатів для exec xp_logininfo 'domain\ADGroupName', 'members'; домен \ oldname не робить.
Користувач викликає suser_name () зсередини збереженої процедури, викликаної з прохідного запиту в MDB Access 2003.
Ми багато змінювали імена облікових записів користувачів у минулому, але спостерігали цю проблему лише за останній тиждень (дві зміни були внесені за останній тиждень; обидві, здається, є проблемою).
На сервері працює Sql Server 2008 SP3 x64 у версії Windows 2008 R2 Datacenter.

Що відбувається? Як DBA, що я можу зробити або де я шукаю, щоб вирішити це?

— Воїн Боб
джерело

Чи входить служба 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. Якщо воно було кешоване, повернеться стара назва. Якщо логін вже існує, ім’я для входу буде повернуто, чи все одно це те саме ім'я чи ні, поки збігаються SID. Це те саме для користувачів баз даних.

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

Ви можете спробувати запустити ipconfig /flushdnsі ipconfig /registerdnsз командного рядка, щоб побачити, чи усуває це проблема.

— RLF

Чи може це бути пов’язано з кешуванням з Kerberos? (лише здогадка, хоч і може бути не пов’язана) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Нормо
джерело

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

— Воїн Боб

Це гарна пропозиція, я мав би про це подумати! :-) Це було те, що ми робили раніше, щоб усунути проблеми з кешованими kerberos. Рада, що ви були успішними!

— Нормо