1. Раз уж ABAP-дамп про duplicate record относится к таблице USREFUS -
удалите из этой таблицы строку про SAP*, и пробуйте заново создавать пользователя SAP* в TA SU01.
2. В целом, метод "На уровне базы данных найти в usr02 запись для sap* в 000 манданте и удалить" -
это метод грубой силы из прошлого века. В старых версиях ПО SAP это, действительно, работало.
В более современных версиях в процедуру логина пользователя добавились проверки
change documents for user (например, записи в таблице USH02 и т.п.). Именно по этой причине,
если пользователь SAP* был заблокирован, а потом строка про SAP* удалена из таблицы USR02,
то залогиниться как SAP*/pass не удавалось.
3. Кроме этого, лучше не удалять строку из USR02, a
в этой строке изменить BNAME с SAP* на другое (например, SAPXYZ),
залогиниться как SAP*/pass,
в строке, где BNAME = SAPXYZ, изменить его обратно на SAP*,
в TA SU01 изменить пароль пользователя SAP*,
не разрывая прежнюю сессию (на всякий случай), залогиниться как SAP* с измененным паролем.
(Как вариант - временно перемещать строку в несуществующий новый мандант, потом обратно.)
4. Более правильная методика основана на следующем. Кодированный пароль пользователя хранится в
USR02-BCODE и USR02-PASSCODE. Поле USR02-CODVN влияет на то, какие именно из тех двух полей актуальны.
Значения USR02-BCODE и USR02-PASSCODE вычисляются исходя из USR02-BNAME и пароля, который вводит пользователь,
и не зависит от номера манданта, имени системы и т.п. Поэтому можно скопировать строку в USR02
из манданта (можно даже из другой системы), где пароль для SAP* известен и SAP* не заблокирован,
в нужный мандант, и логиниться с паролем из того манданта.
При необходимости - позаботиться про значения других полей USR02 и про записи в USH02 и т.п.
Для того, чтобы понять, какие именно таблицы нужны, есть трассировка
Алгоритм вычисления USR02-BCODE был одинаковым для версий 4.6B .. ECC6.0,
и скорее всего, остался таким же и в более поздних версиях (из соображений совместимости версий).
Вход
Регистрация
FAQ пользователя
Поиск
