18.11.2008, 13:16 | #1 |
Участник
|
Тестирование прав пользователей. DAX 4.0.
С согласия автора первоначальной реализации, после некоторой модификации выкладываю проект для тестирования прав групп пользователей и настроек RLS использовавшийся на внедрении Dynamics Ax 4.0. Фактически это программный запуск клиента Dynamics Ax под некоторым логином (что ранее практиковалось консультантами в 3.0 для целей проверки прав).
Основная идея реализации основана на временной подмене SID для тестируемого логина пользователя Dynamics Ax: Amand: Доступ в Microsoft Dynamics AX 4.0 без Active Directory В параметрах необходимо указать конфигурационный файл (экспортировать из Microsoft Dynamics AX Configuration Utility) с которым запускалось приложение. |
|
|
За это сообщение автора поблагодарили: mazzy (2), belugin (6), Pustik (3), sukhanchik (8), Logger (6), jasper (1), farlander (1), longson (2), shogel (1), V777 (1). |
07.02.2009, 13:55 | #2 |
Administrator
|
Навеяло этой темой. Решил выложить модификацию сей утилиты (да простят меня ее авторы, что я ее немного переработал)
Исходная версия утилиты работала следующим образом: 1. Подменялся SID у нужного пользователя 2. Запускалась новая Аксапта с параметром /WAIT, т.е. исходное приложение ожидало завершение нового приложения 3. SID менялся обратно. У данного алгоритма есть 2 существеных недостатка. 1. Если что-то где-то как-то сбойнет и исходное приложение вылетит до завершения нового, то потом придется ручками в БД возвращать на место SIDы 2. Как показала практика - не стоит трогать SID у пользователя Admin, т.к. это может привести к результатам из п.1 Ну и конечно - хочется чтобы была одна кнопка на стандартной форме пользователей. В связи с этим - алгоритм изменился на следующий: 1. Идет проверка на запрет запуска утилиты из под Admin-а и от имени Admin-а 2. Подменяется SID у тестируемого пользователя (как было) 3. Если Аксапта запускалась через конфигурационный файл (в командной строке был указан axc-шник) - то новая Аксапта запускается с этим же конфигурационным файлом. Если конфигурационного файла не было - то Аксапта запускается с тем же портом, что и исходная, но в usr-слое и другими параметрами по умолчанию. Аксапта запускается без параметра WAIT, т.е. исходное приложение не ожидает завершения нового. 4. После запуска новой Аксапты исходная система "ловит" новую запись этого SIDа, сделанную в таблице SysClientSessions. В процессе "ловли" она ждет 10 секунд появления этой записи. Если не дожидается - то выдает запрос - "Подождать/Отменить?", после чего либо снова ждет, либо возвращает SIDы на место. В любом случае - либо после отмены в запросе, либо после перехвата записи - исходный SID возвращается на место. Таким образом, получается, что таблица UserInfo несет в себе некорректные записи только на этапе запуска второй Аксапты и последовательно можно запустить несколько Аксапт под разными пользователями. Пользователь, под которым запущена вторая Аксапта может быть и отключен после запуска - это никак не влияет на его работоспособность (все проверяется только при запуске). Поэтому, считаю, что модификация данной утилиты сделает ее более безопасной в использовании. Ну и конечно все вынесено в отдельную кнопку, которая вешается на стандартную форму SysUserInfo (\Администрирование\Пользователи).
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: raz (10), Pustik (3), Logger (2). |
07.02.2009, 15:47 | #3 |
Модератор
|
Я сейчас наверное какую-нибудь глупость спрошу, но Run as на уже настроенном ярлыке чем не устраивает?
__________________
-ТСЯ или -ТЬСЯ ? |
|
07.02.2009, 16:03 | #4 |
Administrator
|
Необходимость сей утилиты осознаешь - когда настраиваешь права пользователей.
RunAs обладает 2 недостатками: 1. Нужно знать пароль пользователя (внедренец будет собирать пароли пользователей, особенно после запуска?) 2. Нужно иметь этого пользователя в AD (заказчик прям так и кидается дать внедренцу полные права в AD ). Либо (если дело происходит на локале) - надо создавать кучу пользователей самому (особенно, если тестируется функционал, напрямую зависящий от различных ролей пользователей) А так - можно иметь тестового пользователя и на нем отлаживать права групп пользователей, рлсы и т.д.
__________________
Возможно сделать все. Вопрос времени |
|
09.02.2009, 10:18 | #5 |
Участник
|
А можно по-подробнее, как сделать Run as на ярлыке? На ax32.exe - понятно, а как на *.axc? или на *.cmd, когда много разных версий Аксапты?
__________________
Ivanhoe as is.. |
|
09.02.2009, 11:17 | #6 |
Участник
|
Цитата:
"C:\Program Files\Microsoft Dynamics AX\40\Client\Bin\Ax32.exe" "Путь\Конфиг_Файл.axc" |
|
|
За это сообщение автора поблагодарили: Ivanhoe (1). |
09.02.2009, 13:00 | #7 |
Пенсионер
|
Цитата:
PHP код:
__________________
Законы природы еще никто не отменял! А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
За это сообщение автора поблагодарили: Logger (2), Ivanhoe (1). |
30.03.2012, 18:51 | #8 |
Британский учённый
|
Цитата:
Сообщение от sukhanchik
Навеяло этой темой. Решил выложить модификацию сей утилиты (да простят меня ее авторы, что я ее немного переработал)
Исходная версия утилиты работала следующим образом: 1. Подменялся SID у нужного пользователя 2. Запускалась новая Аксапта с параметром /WAIT, т.е. исходное приложение ожидало завершение нового приложения 3. SID менялся обратно. У данного алгоритма есть 2 существеных недостатка. 1. Если что-то где-то как-то сбойнет и исходное приложение вылетит до завершения нового, то потом придется ручками в БД возвращать на место SIDы 2. Как показала практика - не стоит трогать SID у пользователя Admin, т.к. это может привести к результатам из п.1 Ну и конечно - хочется чтобы была одна кнопка на стандартной форме пользователей. В связи с этим - алгоритм изменился на следующий: 1. Идет проверка на запрет запуска утилиты из под Admin-а и от имени Admin-а 2. Подменяется SID у тестируемого пользователя (как было) 3. Если Аксапта запускалась через конфигурационный файл (в командной строке был указан axc-шник) - то новая Аксапта запускается с этим же конфигурационным файлом. Если конфигурационного файла не было - то Аксапта запускается с тем же портом, что и исходная, но в usr-слое и другими параметрами по умолчанию. Аксапта запускается без параметра WAIT, т.е. исходное приложение не ожидает завершения нового. 4. После запуска новой Аксапты исходная система "ловит" новую запись этого SIDа, сделанную в таблице SysClientSessions. В процессе "ловли" она ждет 10 секунд появления этой записи. Если не дожидается - то выдает запрос - "Подождать/Отменить?", после чего либо снова ждет, либо возвращает SIDы на место. В любом случае - либо после отмены в запросе, либо после перехвата записи - исходный SID возвращается на место. Таким образом, получается, что таблица UserInfo несет в себе некорректные записи только на этапе запуска второй Аксапты и последовательно можно запустить несколько Аксапт под разными пользователями. Пользователь, под которым запущена вторая Аксапта может быть и отключен после запуска - это никак не влияет на его работоспособность (все проверяется только при запуске). Поэтому, считаю, что модификация данной утилиты сделает ее более безопасной в использовании. Ну и конечно все вынесено в отдельную кнопку, которая вешается на стандартную форму SysUserInfo (\Администрирование\Пользователи). Обновил для 2009 версии. Тестировалось на SP1 RU7.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
|
За это сообщение автора поблагодарили: coolibin (2), propeller (1). |
25.12.2012, 10:06 | #9 |
Участник
|
Перенес проект на AX 2012
Тот же самый проект, перенесенный на AX 2012.
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
19.11.2014, 16:13 | #10 |
Участник
|
Коллеги! А есть ли у кого-нибудь положительный опыт использования это утилиты на DAX 2012?
Как я вижу, сессия под другим пользователем запускается. Однако, так как непосредственно после её старта запускающая сессия должна возвращать SID'ы пользователей на место, запущенная сессия оказывается нежизнеспособна - любые попытки что то открыть на ней приводят к немедленному падению. Удалось ли кому-нибудь побороть этот эффект и таки воспользоваться этой полезной фичей?
__________________
Здесь могла быть Ваша реклама! |
|
|
За это сообщение автора поблагодарили: Logger (1). |
19.11.2014, 16:31 | #11 |
Участник
|
У меня работает. После переноса на 2012 какую-то мелочь пришлось поправить в коде.
__________________
Ivanhoe as is.. |
|
19.11.2014, 16:56 | #12 |
Участник
|
Т.е. таких проблем сразу не было?
Уточню: у вас DAX 2012 R3? |
|
19.11.2014, 17:22 | #13 |
Британский учённый
|
Если вам нужно тестирование прав, то для 2012 МС выпустил утилиту Security Development Tool . Мы используем на R2, полёт нормальный.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
|
За это сообщение автора поблагодарили: Oz (1), Logger (2). |
19.11.2014, 19:36 | #14 |
Участник
|
Утилита хороша, но как проверить в ней пересечение нескольких ролей?
Привожу код метода, который у меня работал и на R2, и сейчас работает на R3. X++: public boolean runas(UserId _userId) { UserInfo locUserInfo; UserInfo tmpUserInfo; UserInfo userInfoRunAs; UserInfo tmpUserInfoRunAs; FileName fileConfiguration; int iResult; int64 numSessions; SysClientSessions sysClientSessions; int timeStart; OverwriteSystemfieldsPermission permission; xInfo xInfo = new xInfo(); #WinAPI #Admin ; if(_userid == curuserid() || _userId == #AdminUser || curuserid() == #AdminUser) { throw error("!!!"); // тут метка про невозможность запуска } permission = new OverwriteSystemfieldsPermission(); permission.assert(); tmpUserInfo.setTmp(); // для временного хранения текущего состояния tmpUserInfoRunAs.setTmp(); try { ttsbegin; locUserInfo = xUserInfo::find(true, curuserid()); tmpUserInfo.data(locUserInfo); userInfoRunAs = xUserInfo::find(true, _userId); tmpUserInfoRunAs.data(userInfoRunAs); // подменить network привязку login'а userInfoRunAs.networkDomain = locUserInfo.networkDomain; userInfoRunAs.networkAlias = locUserInfo.networkAlias; userInfoRunAs.sid = locUserInfo.sid; userInfoRunAs.enable = NoYes::Yes; if(userInfoRunAs.validateWrite()) userInfoRunAs.update(); // отключить активность текущего пользователя locUserInfo.sid = ''; locUserInfo.enable = NoYes::No; if(locUserInfo.validateWrite()) locUserInfo.update(); ttscommit; } catch { return false; } fileConfiguration = '"' + xInfo::configuration() + '"'; if (!WinApi::fileExists(fileConfiguration)) { fileConfiguration = '-aos2=' + strreplace(conpeek(SysEmailSMTPPassword::currentAOSInstance(), 1), '@', ':'); } select count(RecId) from sysClientSessions where sysClientSessions.userId == userInfoRunAs.Id && sysClientSessions.sid == userInfoRunAs.sid && sysClientSessions.Status == 1; numSessions = sysClientSessions.RecId; iResult = WinAPI::shellExecute(xInfo::componentName(), fileConfiguration, '', #ShellExeOpen, #SW_SHOWNORMAL, false); if (iResult) { sysClientSessions.disableCache(true); timeStart = timenow(); do { select count(recId) from sysClientSessions where sysClientSessions.userId == userInfoRunAs.Id && sysClientSessions.sid == userInfoRunAs.sid && sysClientSessions.Status == 1; if (abs(timenow() - timeStart) > 10) { if (box::yesNo("...", DialogButton::No) == DialogButton::Yes) // тут текст, что клиент не успел стартовать - ждать еще или нет { timeStart = timenow(); } else { break; } } } while (sysClientSessions.RecId <= numSessions); } // восстановить исходное состояние данных ttsbegin ; locUserInfo = xUserInfo::find(true, curuserid()); locUserInfo.enable = tmpUserInfo.enable; locUserInfo.sid = tmpUserInfo.sid; locUserInfo.defaultPartition = tmpUserInfo.defaultPartition; if(locUserInfo.validateWrite()) locUserInfo.update(); userInfoRunAs = xUserInfo::find(true, _userId); userInfoRunAs.networkDomain = tmpUserInfoRunAs.networkDomain; userInfoRunAs.networkAlias = tmpUserInfoRunAs.networkAlias; userInfoRunAs.sid = tmpUserInfoRunAs.sid; userInfoRunAs.enable = tmpUserInfoRunAs.enable; userinfoRunAs.defaultPartition = tmpUserInfoRunAs.defaultPartition; if(userInfoRunAs.validateWrite()) userInfoRunAs.update(); ttscommit; CodeAccessPermission::revertAssert(); return !iResult; }
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: Oz (2), Logger (1). |
25.11.2014, 08:53 | #15 |
Участник
|
Добрый день, а как бы реализовать этот проект в 3.0?
|
|
27.11.2014, 10:11 | #17 |
Участник
|
спасибо, буду пробовать
|
|
15.12.2014, 15:15 | #18 |
Британский учённый
|
Я добавляю нужные роли к тестируемой в узел Sub Roles. Так можно тестировать сразу несколько ролей. В принципе достаточно удобно.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
|
За это сообщение автора поблагодарили: Logger (3), Ivanhoe (3). |
Теги |
rls, run as, тестирование прав, права доступа, ax2009, ax4.0 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|