Как дать доступ к Аксапте внешним пользователям?

[oleg_e]

Продолжаем тему доступа пользователей,находящихся вне домена в DAX 4.0

Способ от Vladislav
Первый: прописываем прямо в БД в SysBCProxyUserAccount запись с SID того пользователя, который заведен на сервере. А вот в UserInfo прописываем SID, под которым этот пользователь заведен на клиенте

НЕ РАБОТЕТ. Может за последнее аремя возникли новые идеи?

[gl00mie]

Цитата:

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

Может за последнее аремя возникли новые идеи?

Идеи-то есть уже давно, вот времени их воплотить не хватает... А идея простая: как было выяснено, проблема с подключением возникает из-за того, что AOS получает информацию о SID'е пользователя для сопоставления его с тем или иным пользователем Axapta не из характеристик RPC-подключения (при том, что там используется аутентификация и обеспечение целостности данных), а непосредственно от клиента Axapta. Последний для этого получает SecurityToken своего основного потока, для этого SecurityToken запрашивает SID, проверяет его с помощью функции IsValidSid() из kernel32.dll и (та-да!) преобразует в строковый формат с помощью функции ConvertSidToStringSidW() все из той же kernel32.dll, после чего посылает его в таком виде AOS'у.
При этом клиент Аксапты еще для каких-то надобностей грузит ntdsapi.dll и version.dll. Примечательны они тем, что из них импортируется всего лишь 1 и 3 функции, соответственно. Теперь зачем эта информация нужна...
В общем, идея видится такая:

• создать библиотеку (условно назовем ее sidfake), которая будет называться тоже ntdsapi.dll или version.dll, и экспортировать из нее функции с теми же названиями, которые импортирует из них клиент Аксапты;
• в DllMain библиотеки sidfake по событию DLL_PROCESS_ATTACH:
  • проверять, что загружающий ее процесс - ax32.exe, а если не так, то не грузиться;
  • грузить "настоящую" библиотеку ntdsapi.dll/version.dll из виндового каталога и перенаправлять свои экспортируемые функции на настоящие функции этих библиотек (надо только проверить, не будет ли косяков при загрузке одним процессом двух одноименных модулей);
  • править в памяти таблицу импорта ax32.exe с тем, чтобы функция ConvertSidToStringSidW() перенаправлялась на функцию из библиотеки sidfake (на момент ее загрузки импорты из kernel32.dll у ax32.exe уже должны быть настроены, поскольку она в таблице иморта идет раньше ntdsapi.dll и version.dll);
  • читать конфиг/настройку реестра на предмет того, какой SID (в строковом виде) нужно возвращать;
• в функции ConvertSidToStringSidW() библиотеки sidfake (эта функция не обязана экспортироваться и называться может как угодно) подсовывать считанное ранее текстовое представление SID'а вместо того, что соответствует переданному в бинарном виде SID'у.
• положить библиотеку sidfake (напомню, ее файл должен называться в данном сценарии ntdsapi.dll или version.dll) в каталог клиента Axapta.

Идея, собственно, основана на порядке, в котором виндовый загрузчик просматривает каталоги при поиске библиотек, упоминаемых в таблице импорта загружаемого модуля.

[Vladyslav]

Ну раз там такая "дыра", то может провести редактирование файла сервера не как взлом ПО (что является нарушением п 4.4 правил форума "...Запрещено любое обсуждение взлома, обхода защиты любого программного обеспечения..."), а как "исправление ошибки" в безопасности? ;-)

Т.е. "подправить" файл, чтобы он брал не SID, присланный бог весть откуда, а SID аккаунта, который выполняется на сервере.