AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.05.2018, 22:06   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Lightbulb D365FO - пропажа доступа пользователей и его восстановление
Симптомы
Пользователь заведен в D365FO, даны права, всё вроде хорошо, но при попытке входа выдается ошибка "You are not authorized to login with your current credentials", как будто пользователя просто нет в списке. Это может проявляться как сразу после заведения пользователя, так и через какое-то время (месяцы).

Диагностика
Сразу после неудачной попытки входа в EventLog на хосте AOS стоит открыть Applications and Services Logs/Microsoft/Dynamics/AX-SystemRuntime/Operational и поискать сообщение c ID 486 из категории ValidateMatchingUserInfoFailed с текстом "Could not find matching AX user in USERINFO table". Если такое сообщение нашлось, то незадолго до него должно быть сообщение с ID 484 из категории GetSidFromClaims, в котором на вкладке Details будет виден "правильный" SID. После этого стоит посмотреть, какой SID у пользователя прописан в базе AX, в таблице UserInfo. Если эти два SID не совпадают, то это, скорее всего, и есть причина ошибки. Почему искать сообщения в EventLog нужно сразу после неудачной попытки входа: лог AX-SystemRuntime/Operational по умолчанию имеет размер в 1Мб, и старые сообщения очень быстро перезатираются.

Как исправить
Если пользователь один, то можно просто "руками" прописать ему правильный SID в UserInfo, если же их много, то можно воспользоваться SQL-скриптом для массового обновления SID. Вот пример:
PHP код:
update USERINFO
set 
[SID] = replace([SID],
N'-2864208061-3273002421-3047239075-1510753008-4077435192',
N'-3265027205-1866819130-1407551012-2573948675-588562861')
where [SIDlike '%4077435192' and [NETWORKALIASlike '%@mycompany.ru' 
Здесь для операции строковой замены искомый суффикс в SID надо взять из базы, а результирующий - из EventLog'а, при этом начало SID'ов одного и того же пользователя должно совпасть.

Как же это всё произошло?
Из моего опыта, у всех проблемных пользователей с учетками в одном домене SID'ы "поменялись" одинаковым образом: при заведении был один суффикс, а при входе стал определяться другой. Это может быть связано с изменением IdentityProvider: в некоторых источниках указывают, что SID'ы пользователей в D365O - это конкатенация хешей кода пользователя (NetworkAlias) и IdentityProvider'а. Отчего он может меняться, я пока не выяснил, но мне встречались две разные ситуации: в одном случае пользователь с "левым" LiveId не мог войти сразу после того, как я его завел, в другом люди с корпоративными LiveId работали несколько месяцев, а потом "вдруг" пропал доступ.

Всё вышеописанное случалось на 7.3 PU 12, возможно, в 8.0 проблема была решена, а может, причина - в каких-то изменениях настроек. Кто-то еще с таким вообще сталкивался?..
За это сообщение автора поблагодарили: trud (10), raz (10), A_BAS (2), fed (7), vmoskalenko (1), sukhanchik (8), Logger (10), MarinaAX (2).
Старый 31.05.2018, 17:43   #2  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
145 / 334 (12) ++++++
Регистрация: 25.01.2007
Адрес: Toronto
Спасибо за инфу!

А еще бывает, что по какой-то причине перестает работать Import пользователей.
Просто вываливает ошибку и все.

Как workaround, всегда можно создать нового пользователя вручную без импорта. Если пользователь из другого домена, то надо указать в поле provider
Код:
https://sts.windows.net/<домен>/
Еще говорят, что слетание Импорта пользователей связано с тем, что пользователь который деплоил сервер (Админ) находился в другом домене. Тогда лечить либо переустановкой всего сервера с нуля, либо выполняем Admin provisioning для пользователя с правильным доменом.
За это сообщение автора поблагодарили: trud (5).
Старый 01.06.2018, 09:20   #3  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
А еще бывает, что по какой-то причине перестает работать Import пользователей.
Это на уровне конкретного инстанса - создавайте тикет для саппорта, починят
__________________
-ТСЯ или -ТЬСЯ ?
Старый 23.06.2018, 13:30   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Сразу после неудачной попытки входа в EventLog на хосте AOS стоит открыть Applications and Services Logs/Microsoft/Dynamics/AX-SystemRuntime/Operational и поискать сообщение c ID 486 из категории ValidateMatchingUserInfoFailed с текстом "Could not find matching AX user in USERINFO table". Если такое сообщение нашлось, то незадолго до него должно быть сообщение с ID 484 из категории GetSidFromClaims, в котором на вкладке Details будет виден "правильный" SID.
К слову, как выясняется, в D365FO on-premises коды сообщений в Eventlog немного другие - 487 и 485, соответственно
Старый 26.06.2018, 00:52   #5  
axotnik88 is offline
axotnik88
Участник
 
82 / 18 (1) ++
Регистрация: 05.06.2012
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
Спасибо за инфу!

А еще бывает, что по какой-то причине перестает работать Import пользователей.
Просто вываливает ошибку и все.

Как workaround, всегда можно создать нового пользователя вручную без импорта. Если пользователь из другого домена, то надо указать в поле provider
Код:
https://sts.windows.net/<домен>/
Еще говорят, что слетание Импорта пользователей связано с тем, что пользователь который деплоил сервер (Админ) находился в другом домене. Тогда лечить либо переустановкой всего сервера с нуля, либо выполняем Admin provisioning для пользователя с правильным доменом.
Некоторые environment были созданы c под другого домена в LCS,хотя и юзер имел полные права на LCS, но после нескольких дней переписки с МС и нескольких изменений в разных конфиг файлах и базах, заново передеплоили environments
Теги
d365fo

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Настройка прав доступа на просмотр всех Пользователей. Ax 2009 Poleax DAX: Администрирование 12 13.05.2011 13:23
Организация доступа внешних веб-пользователей к DAX 4.0 alex55 DAX: Администрирование 1 07.06.2009 17:48
Права доступа Группы пользователей к таблице ta_and DAX: Администрирование 2 19.01.2009 15:19
Список групп пользователей и уровней доступа для каждой группы Андрей К. DAX: Программирование 4 25.01.2008 08:35
Ограничение доступа пользователей к компаниям aevi82 DAX: Функционал 15 23.08.2007 14:23
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.