Путает навижен Windows Login?

[max_hl_imported]

Цитата:

Сообщение от _Andrey

Тема достаточно старая и скорее всего автор и участники этого обсуждения уже знают решение, но возможно кому-то будет интересно узнать как все-таки это можно решить.
Проблема в функции LsaLookupSids, которая может возвращать старое имя пользователя вместо нового имени, если имя это было изменено. Более подробно можно прочитать вот по этой ссылке Ссылка.
Переименовывать пользователя на сервере SQL следует после создания параметра LsaLookupCacheMaxSize в реестре - в этом случае и в NAV и на SQL будет корректный переименованный логин. После переименования параметр LsaLookupCacheMaxSize можно удалить из реестра.

В статье по ссылке говорится, что отключить кэш SID необходимо на контроллере домена, а не на SQL сервере. Затем переименование выполняется так же на контроллере домена, SQL не при чем тут.
Хотелось бы отметить, что кэш SID на контроллере выдуман не зря и возможны потери производительности при его отключении. MS какое-то радикальное решение предлагает.. Возможно лучше отключить кэш, переименовать пользователя, а затем включить кэш обратно.
Достаточно часто сталкиваемся с подобными ситуациями в связи с уходом сотрудниц в декрет, а затем выходом на работу. Я админам рекомендую бэкапить профиль, но удалять учетку. Проще по выходу заново завести учетку и настроить доступ в соответствии с текущими полномочиями.

Вообще с SIDами все просто.
При открытии Нава отправляется запрос на аутентификацию на сиквэл. Отправляется SID !
В Наве SID транслируется в USERNAME через кэш локального компа, нет в кэше - запрос на контроллер, нет у него в кэше актуальной записи - запрос к AD.
При открытии формы Учетные записи Windows выполняется запрос на SQL сервер предоставить SID всех пользователей, которым разрешен доступ к открытой базе данных.
Разрешение SID в имя выполняется на локальном компе. SQL этой работой не занимается.

[AnDr]

Цитата:

Сообщение от max_hl

Цитата:

Сообщение от _Andrey

Тема достаточно старая и скорее всего автор и участники этого обсуждения уже знают решение, но возможно кому-то будет интересно узнать как все-таки это можно решить.
Проблема в функции LsaLookupSids, которая может возвращать старое имя пользователя вместо нового имени, если имя это было изменено. Более подробно можно прочитать вот по этой ссылке Ссылка.
Переименовывать пользователя на сервере SQL следует после создания параметра LsaLookupCacheMaxSize в реестре - в этом случае и в NAV и на SQL будет корректный переименованный логин. После переименования параметр LsaLookupCacheMaxSize можно удалить из реестра.

В статье по ссылке говорится, что отключить кэш SID необходимо на контроллере домена, а не на SQL сервере. Затем переименование выполняется так же на контроллере домена, SQL не при чем тут.
Хотелось бы отметить, что кэш SID на контроллере выдуман не зря и возможны потери производительности при его отключении. MS какое-то радикальное решение предлагает.. Возможно лучше отключить кэш, переименовать пользователя, а затем включить кэш обратно.
Достаточно часто сталкиваемся с подобными ситуациями в связи с уходом сотрудниц в декрет, а затем выходом на работу. Я админам рекомендую бэкапить профиль, но удалять учетку. Проще по выходу заново завести учетку и настроить доступ в соответствии с текущими полномочиями.

Вообще с SIDами все просто.
При открытии Нава отправляется запрос на аутентификацию на сиквэл. Отправляется SID !
В Наве SID транслируется в USERNAME через кэш локального компа, нет в кэше - запрос на контроллер, нет у него в кэше актуальной записи - запрос к AD.
При открытии формы Учетные записи Windows выполняется запрос на SQL сервер предоставить SID всех пользователей, которым разрешен доступ к открытой базе данных.
Разрешение SID в имя выполняется на локальном компе. SQL этой работой не занимается.

В чем-то безусловно вы правы, но не во всем. Может быть я не совсем ясно выразился. Опишу поподробней как именно с этим столкнулся я.
Отключить на время переименования логина локальный кэш можно на том Windows сервере, где установлен экземпляр SQL сервера, ссылку я привел больше в качестве места где именно это нужно делать. Т.е. это можно делать не обязательно на контроллере домена. И можно навреное и не на время, при условии что пользователей не много, а уходят в декрет они часто. /> Конечно пользователя нужно переименовывать после того как его переименовали в AD. Есть два относительно честных способа как это сделать, ну по крайней мере тех, о которых известно мне и которыми я пользовался, первый переименовать на SQL сервере с помощью команды ALTER Login (условие кэш LSA должен быть временно отключен), второй в самом NAV путем удаления регистрационного имени Windows и создания записи уже с другим переименованным именем логина. SID в этом случае остается старый. Т.е. непосредственно сам SQL сервер я упоминул здесь потому, что из него тоже можно переименовать логин, а не в коим случае не как инструмента для отключения кэша SID />. Еще один момент и клиент NAV и SQL сервер будут обращаться к одому и тому же локальному кэшу учетных записей при условии, что клиент NAV открывает коннект к БД расположенной на Windows сервере на котором установлен экземпляр SQL сервера. Пример могу привести такой:
1. В AD Иванова переименовываем в Петрова. При этом локальный кэш включен.
2. Переименовываем Иванова в Петрова в NAV. Вообще по идее логин должен переименоваться автоматически, но так мы поступим для чистоты эксперимента.
3. Петров открывает БД посредством клинта NAV и спокойно работает. До поры до времени.
4. При последущем коннекте к БД, все тем же клиентом NAV обнаружится что Петров опять стал Ивановым, т.е. получится ситуация описанная выше AlexB. Причем тоже самое будет и на SQL сервере в пользователях БД логин Петров переименуется в Иванова.
В локальном кэше учетных записей Windows сервера на котором установлен и экземпляра SQL cервера - будет две учетных записи Петров и Иванов и у них будет один и тот же SID!
В этом можно убедится например выполнив запрос на SQL сервере использовав команду SUSER_SID('логин', 0), второй параметр должен быть именно 0, в этом он обращается к тому же локальному кэшу. Такая команда для логина Петрова и логина Иванова вернет один и тот же SID. Может быть можно и какими-то другими тулзами умеющимии читать локальный кэш службы LSA - не экперементировал в этом направлении.
Совпадения могут быть конечно, но такое поведение NAV и SQL сервера по части работы с SID указавает на некорректную работу ф-ции LsaLookupSids описанную MS.

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