D365FO - пропажа доступа пользователей и его восстановление

[gl00mie]

Симптомы
Пользователь заведен в 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 [SID] like '%4077435192' and [NETWORKALIAS] like '%@mycompany.ru' 


Здесь для операции строковой замены искомый суффикс в SID надо взять из базы, а результирующий - из EventLog'а, при этом начало SID'ов одного и того же пользователя должно совпасть.

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

Всё вышеописанное случалось на 7.3 PU 12, возможно, в 8.0 проблема была решена, а может, причина - в каких-то изменениях настроек. Кто-то еще с таким вообще сталкивался?..

[vmoskalenko]

Спасибо за инфу!

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

Как workaround, всегда можно создать нового пользователя вручную без импорта. Если пользователь из другого домена, то надо указать в поле provider

https://sts.windows.net/<домен>/

Еще говорят, что слетание Импорта пользователей связано с тем, что пользователь который деплоил сервер (Админ) находился в другом домене. Тогда лечить либо переустановкой всего сервера с нуля, либо выполняем Admin provisioning для пользователя с правильным доменом.

[Vadik]

Цитата:

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

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

Это на уровне конкретного инстанса - создавайте тикет для саппорта, починят

[axotnik88]

Цитата:

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

Спасибо за инфу!

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

Как workaround, всегда можно создать нового пользователя вручную без импорта. Если пользователь из другого домена, то надо указать в поле provider

https://sts.windows.net/<домен>/

Еще говорят, что слетание Импорта пользователей связано с тем, что пользователь который деплоил сервер (Админ) находился в другом домене. Тогда лечить либо переустановкой всего сервера с нуля, либо выполняем Admin provisioning для пользователя с правильным доменом.

Некоторые environment были созданы c под другого домена в LCS,хотя и юзер имел полные права на LCS, но после нескольких дней переписки с МС и нескольких изменений в разных конфиг файлах и базах, заново передеплоили environments

[gl00mie]

Цитата:

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