Путает навижен Windows Login? - NAV: Администрирование

alexb_imported · 31.08.2011, 00:17

Жил-был windows user Иванова, вашла замуж и стала Петровой.
Админ стирает в active directory domane account Иванова и заводит domane account Петрова.
То же самое делает и на SQL Server'e
Петрова заходит под новым account'ом в свой windows (т.е. domanename\petrova) и всё вроде нормально, пока дело не доходит до навижена.
Заходит в навижен через Windows Login и навижен показывает её в Status Bar'e внизу справа как domanename\иванова!
В таблице Windows Login есть только Петрова, Ивановой нет. Т.е. по идее user иванова вообще не может зайти в навижен, т.к.Windows Login domanename\иванова вообще отсутствует, но заходит!? Если выдать MESSAGE(USERID)- то навижен выдаёт иванова!?
Но ведь user'a Ивановой нет ни в домене, ни на локальном компе!
Батник с user'ом выдаёт петрова, в реестре всюду- петрова. Откуда навижен берёт user'a иванову?
Синхронозацию логинов в навижене провели (несколько раз).
В навижене работают только через Windows Login, database login нет и никогда не было.
Версия NAV2009 R2 Classic / SQL Server 2008R2
Есть у кого ещё идеи, где можно копать?

**mazzy** · 31.08.2011, 09:33

Цитата:

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

Админ стирает в active directory domane account Иванова и заводит domane account Петрова.

А что значит "стирает"?
он удаляет учетную запись и создает новую? (в этом случае меняется идентификатор SID учетной записи)
или все-таки в той же учетной записи ИЗМЕНЯЕТ имя? (в этом случае SID не изменяется, изменяется только имя)

windows аутентификация происходит по SID, а не по name учетной записи.

в вашем случае, скорее всего, админ всего-лишь сменил имя в учетной записи (так гораздо легче и не надо пользователю указывать группы и привязывать к остальным программам).
А Навик запомнил старое имя и старый SID.

alexb_imported · 31.08.2011, 11:10

Цитата:

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

А Навик запомнил старое имя и старый SID.

Да, так оно и было, админ лишь изменил учётную запись. Стирать и заводить по-новой слишком большая морока (права, оутлоок итд.)
Но где навик "запоминает" SID? Как уже сказал, в таблице Windows Login есть только Петрова, Ивановой нет. Т.е. по крайней мере там показывает к SID новое имя учётной записи правильно. Виртуальные таблицы типа "SID - Account ID", "Windows Account" итд. заполняются же вроде при старте NAV-клиента.
Как заставить навик "запомнить" новое имя учётной записи? Что-бы при заходе в навижен USERID вадавало новое имя?

**Sancho** · 31.08.2011, 11:17

навик не запоминает вин значение SID, а рассчитывает его (calcfield) каждый раз.
так что оно закешировалось в винде.
имхо, перезагрузка сервера поправит дело.
ну или пусть разводится нафик. Иванова тоже не плохая фамилия

.Quattro. · 31.08.2011, 11:24

А пробовали удалить пользователя из нава и завести заново?
Можно даже просто попробовать завести новую Петрову, чтобы скопировать все права с Ивановой.
А потом Иванову удалить, конечно же.

alexb_imported · 31.08.2011, 11:39

Цитата:

Сообщение от .Quattro.

А пробовали удалить пользователя из нава и завести заново?
Можно даже просто попробовать завести новую Петрову, чтобы скопировать все права с Ивановой.
А потом Иванову удалить, конечно же.

Конечно пробовали, не помогло.
Попробуем при случае перестартовать серверы. Если не поможет, тогда развод "по-навиженски" (нафик)

**mazzy** · 31.08.2011, 14:39

Цитата:

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

навик не запоминает вин значение SID, а рассчитывает его (calcfield) каждый раз.

точно не хранит? всегда думал, что наоборот, хранит как раз SID, а имя вычисляет.

**mazzy** · 31.08.2011, 15:01

Цитата:

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

Петрова заходит под новым account'ом в свой windows (т.е. domanename\petrova) и всё вроде нормально, пока дело не доходит до навижена.
...
Версия NAV2009 R2 Classic / SQL Server 2008R2

извините, дальше будут скриншоты classic.

а что видит администратор в списке "Учетные записи Windows"? domanename\petrova или domanename\иванова?
может быть, просто перещелкнуть эту запись?

alexb_imported · 31.08.2011, 16:32

Цитата:

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

а что видит администратор в списке "Учетные записи Windows"? domanename\petrova или domanename\иванова?
может быть, просто перещелкнуть эту запись?

Там ведь то же самое что в таблице "Windows Login":там видно только новое имя "domanename\petrova", прежнее "domanename\иванова" отсутствует
Что Вы имеете в виду с "перещёлкнуть": отвалидэйтить с F2? NAV не даёт, говорит, что user уже имеется. Удалить и занести снова не помогает.

.Quattro. · 31.08.2011, 21:31

Цитата:

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

Цитата:

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

навик не запоминает вин значение SID, а рассчитывает его (calcfield) каждый раз.

точно не хранит? всегда думал, что наоборот, хранит как раз SID, а имя вычисляет.

Я думаю, Серега имел в виду именно это - ведь когда разворачиваешь копию базы у себя, вместо имен видишь эти SID'ы

**Sancho** · 01.09.2011, 15:24

угу
я как раз имел ввиду ОПИСАНИЕ SID.
Нав его не хранит

AnDr · 24.01.2013, 12:46

Цитата:

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

Жил-был windows user Иванова, вашла замуж и стала Петровой.
Админ стирает в active directory domane account Иванова и заводит domane account Петрова.
То же самое делает и на SQL Server'e
Петрова заходит под новым account'ом в свой windows (т.е. domanename\petrova) и всё вроде нормально, пока дело не доходит до навижена.
Заходит в навижен через Windows Login и навижен показывает её в Status Bar'e внизу справа как domanename\иванова!
В таблице Windows Login есть только Петрова, Ивановой нет. Т.е. по идее user иванова вообще не может зайти в навижен, т.к.Windows Login domanename\иванова вообще отсутствует, но заходит!? Если выдать MESSAGE(USERID)- то навижен выдаёт иванова!?
Но ведь user'a Ивановой нет ни в домене, ни на локальном компе!
Батник с user'ом выдаёт петрова, в реестре всюду- петрова. Откуда навижен берёт user'a иванову?
Синхронозацию логинов в навижене провели (несколько раз).
В навижене работают только через Windows Login, database login нет и никогда не было.
Версия NAV2009 R2 Classic / SQL Server 2008R2
Есть у кого ещё идеи, где можно копать?

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

max_hl_imported · 24.01.2013, 20:52

Цитата:

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

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

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

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

AnDr · 25.01.2013, 18:04

Цитата:

Сообщение от 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.

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

/>