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

[gl00mie]

Цитата:

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

Для некоторых пользователей разрешен удаленный доступ к VPN. VPN пользователи подключаются в домен, а затем в терминал. VPN пользователи нормально подключаются и работают с AX4.0 через терминал.
Что нужно:
нужно предоставить непосредственный (без терминала) доступ к Аксапте 4.0 внешним пользователям. причем, рассматривается два случая:
= внешним пользователем является сотрудник с своим ноутбуком (заходит из дома в домен под доменным пользователем, затем пытается войти в Аксапту 4.0)
= внешний пользователь не входит в домен (из организации-партнера или наш сотрудник входит с локальной учетной записи своего ноутбука)
5. Что уже исследовано:
= Если в ISA разрешить полный доступ VPN клиентов ко внутренней сети, то внешние доменные пользователи подключаются к AX4.0
= Если на удаленный компьютер зайти под недоменным пользователем, то AX4.0 выдает сообщение Failed to establish connection, даже при разрешенном полном доступе VPN (что ожидалось). Однако это же сообщение появляется даже при использовании run as...
Как дать доступ в AX4.0 внешним недоменным пользователям? (кроме корпоративного портала и терминала)

По ходу, кое-что проясняется, но вначале немного теории...
Когда пользователь логинится на комп (в домен или локально), на основе введенных данных - логин/пароль/домен - и информации о пользователе, имеющейся в системе или домене, создается access token, а также описываемый им security context (извиняюсь за буржуйские термины). Access token, кроме прочего, содержит SID текущего пользователя, SID'ы групп, в которые он входит, etc. Данный access token используется всеми процессами, запускаемыми в дальнейшем пользователем. При этом у отдельного потока может быть как первичный (primary) token, так и impersonation token. Благодаря последнему обращение к объектам, требующим проверки прав доступа, осуществляется "от имени" того пользователя, на основе данных которого создан impersonation token.
Каким образом работает аутентификация пользователя, подключающегося по VPN к сети с виндовым доменом? В документации по ISA Server 2004 есть небезынтересный раздел под названием How a VPN works Там, в частности, написано следующее:

Цитата:

Credentials used for remote access only provide a communication channel to the target network. The client does not log on to the network as a result of a remote access connection. Each time the client attempts to access a network resource, it will be challenged for credentials. If it does not respond to the challenge with acceptable credentials, the access attempt will fail.
Microsoft Windows Server™ 2003 and Windows® XP add a feature to simplify remote access. After a successful connection, Windows Server 2003 and Windows XP remote access clients will cache these credentials as default credentials for the duration of the remote access connection. When a network resource challenges the remote access client, the client provides the cached credentials without requiring the user to enter them again.

Иными словами, при подключении по VPN используется авторизация пользователя по логину/паролю (домену), но эта авторизация нужна лишь серверу удаленного доступа (RAS) для проверки прав пользователя на подключение к VPN; "вход в сеть", если подключаться к сети, где есть виндовый домен, при этом не осуществляется, т.е. access token пользователя остается неизменным. Однако, клиентская часть RAS в wxp/w2k3 запоминает введенные при авторизации на RAS-сервере данные и затем прозрачно для пользователя использует их при доступе к различным ресурсам, в т.ч. создает и при необходимости "предъявляет" impersonation token.
Это все легко проверить, например, так: залогиниться, подключиться по VPN куда-нить с логином/паролем другого пользователя (напомню, эти данные на "той стороне" используются только RAS'ом), после чего посмотреть той же whoami данные о себе "здесь" и - "там", скажем, с помощью psexec. PsExec запускает указанный процесс на удаленной машине, по умолчанию - используя primary access token, т.е. данные текущего пользователя. Таким образом, если мы зашли на комп под domain1\user1, а подключились к VPN под domain2\user2, то на удаленном компе psexec будет пытаться запустить процесс под domain1\user1. При этом клиент RAS при доступе psexec к удаленному компу подсунет данные пользователя domain2\user2. Так вот, в моем случае данные о текущем пользователе "здесь" и "там" выглядят так (названия доменов и логинов изменены):

[C:\spool\distribs\tools\support-tools-wxp]whoami /user /groups /sid
[User]     = "SOMEORG.RU\gl00mie"  S-1-5-21-1822057450-1364742103-1361462980-3250

[Group  1] = "SOMEORG.RU\Domain Users"  S-1-5-21-1822057450-1364742103-1361462980-513
[Group  2] = "Everyone"  S-1-1-0
[Group  3] = "SOWS0019\Axapta shared"  S-1-5-21-3354534663-136502469-2956773634-1004
[Group  4] = "SOWS0019\Nero"  S-1-5-21-3354534663-136502469-2956773634-1003
[Group  5] = "BUILTIN\Administrators"  S-1-5-32-544                                
[Group  6] = "BUILTIN\Users"  S-1-5-32-545                                         
[Group  7] = "NT AUTHORITY\INTERACTIVE"  S-1-5-4                                   
[Group  8] = "NT AUTHORITY\Authenticated Users"  S-1-5-11                          
[Group  9] = "NT AUTHORITY\This Organization"  S-1-5-15                            
[Group 10] = "LOCAL"  S-1-2-0                                                      
[Group 11] = "SOMEORG.RU\Axapta Dev"  S-1-5-21-1822057450-1364742103-1361462980-1755
[Group 12] = "SOMEORG.RU\Male"  S-1-5-21-1822057450-1364742103-1361462980-1317      
[Group 13] = "SOMEORG.RU\DocsVision Users"  S-1-5-21-3354534663-136502469-2956773634-1014
[Group 14] = "SOMEORG.RU\DepIT"  S-1-5-21-1822057450-1364742103-1361462980-1697     

[C:\spool\distribs\tools\support-tools-wxp]psexec \\192.168.12.5 whoami /user /groups /sid

PsExec v1.58 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com


[User]     = "GSTM-P\pupkin"  S-1-5-21-330527288-2049760794-725345543-1276

[Group  1] = "GSTM-P\Domain Users"  S-1-5-21-330527288-2049760794-725345543-513
[Group  2] = "Everyone"  S-1-1-0
[Group  3] = "BUILTIN\Users"  S-1-5-32-545
[Group  4] = "BUILTIN\Administrators"  S-1-5-32-544
[Group  5] = "NT AUTHORITY\NETWORK"  S-1-5-2
[Group  6] = "NT AUTHORITY\Authenticated Users"  S-1-5-11
[Group  7] = "GSTM-P\VPN Users"  S-1-5-21-330527288-2049760794-725345543-1269
whoami exited on 192.168.12.5 with error code 0.

Помимо запуска процессов на удаленном компьютере, конечно, есть и другие способы проверить, как видится пользователь с точки зрения удаленной системы; psexec и whoami использованы для наглядности.
Так вот, эти функции клиента RAS в wxp/w2k3 замечательно работают и в том случае, когда аутентификация осуществляется "внутри" какого-либо другого протокола, например RPC. В этом мне удалось наглядно убедиться после написания парсера для протокола аутентификации NTLM и просмотра с помощью новой чудесной версии Network Monitor 3 сетевого трафика между клиентом AX и AOS в момент установления связи. На скриншотах видно, что когда сам клиент AX4 был запущен под локальным пользователем wxp-ax4\test2, а не под доменным ax\test, клиент RAS использует для NTLM-аутентификации данные, закэшированные во время подключения по VPN, и аутентифицирует клиента как ax\test. Различия в регистре NetBIOS-имени домена (ax/AX в target в message type 3) тут несущественны.
Но тогда почему же выдается ошибка "Failed to logon to Axapta"? Здесь уже пришлось прибегнуть к "инвазивной хирургии", в результате чего выяснилось, что ошибка возникает при вызове функции NdrClientCall2, которой в качестве параметров кроме прочего передается SID текущего пользователя - того, по которым запущен клиент AX4. NDR - это протокол уровня представления (presentation), в соответствии с которым передаются данные RPC-вызовов, устанавливается порядок маршализации (marshalling) параметров, их выравнивание, etc. В MSDN есть описание формата NDR, думаю, если наложить его на то, что в недрах ax32.exe передается в качестве параметров функциям типа NdrClientCall2, многое прояснится, но пока времени и душевных сил на это не хватает.

[mazzy]

Цитата:

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

Но тогда почему же выдается ошибка "Failed to logon to Axapta"?
...
но пока времени и душевных сил на это не хватает.

Прежде всего, огромное спасибо.
Шел примерно этим же путем. Так же сил душевных не хватило.

По поводу сертификатов. И до этого дошел а также до процедуры CertEnroll (ключевое слово, ищите по нему).

Но, насколько я понял, чтобы получить персонализированные сертификаты безопасности, нужно на сервер накатить Identity Integration Server, но результат не гарантирован.

Тут то силы и кончились

Дайте знать, если кто-то дойдет дальше.

[KiselevSA]

Вот интересно, как поведет себя Axapta, если для удаленного пользователя "принудительным" порядком в SQL указать SID этого пользователя на удаленной машине или удаленном домене?

[KiselevSA]

А если настроить на компьютере, с которого "приходят" пользователи, параметр "Enable computer and user accounts to be trusted for delegation" в правах?

[mmm]

Чем то закончились эксперименты? или все так и зависло до свободных времен?!

Думаю данная тема интересна многим...

[Vladyslav]

А тема еще интересна? А то я только месяц назад добрался до того, чтоб пощупать четверку.
Зато могу с уверенностью сказать, что МОЖНО коннектиться клиентом с другой машине к AOS на другой машине даже при напрочь отсутствующем AD
Способов два (прошу прощения, что "ногой в дверь", но мне так проще, чем читать кучу доки по бизнес-коннектору и пр.):
Первый: прописываем прямо в БД в SysBCProxyUserAccount запись с SID того пользователя, который заведен на сервере (имя пользователя и домена судя по всему пофиг - заполнил несуществующими - сожрало и не ругалось при подключении). А вот в UserInfo прописываем SID, под которым этот пользователь заведен на клиенте (естественно, что завел одинаковые логин и пароль). И все. Клиент под XP в рабочей группе. Сервер под Win2K3 без AD (ну работаю я просто на нем).
Второй способ: изменить команды в исполняемом файле, но ведь этого делать нельзя по соображениям законности? ;-)

[mazzy]

Цитата:

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

SysBCProxyUserAccount

Это таблица для Business Connector. Вы точно ничего не путаете?

[gl00mie]

Цитата:

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

могу с уверенностью сказать, что МОЖНО коннектиться клиентом с другой машине к AOS на другой машине даже при напрочь отсутствующем AD

Вот как раз при напрочь отсутствующем AD неинтересно, потому что в реальных условиях использования 4-ки AD обычно есть.

Цитата:

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

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

Я пробовал так - не работает Правда, в моем случае AOS был в AD-домене.

Цитата:

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

Второй способ: изменить команды в исполняемом файле, но ведь этого делать нельзя по соображениям законности? ;-)

Не совсем так. Ведь можно изменять команды не только в исполняемом файле, но и в памяти, причем изменять именно клиентский код, чтобы он в "приветственном" сообщении посылал нужный SID...

Цитата:

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

Это таблица для Business Connector. Вы точно ничего не путаете?

Дело, наверно, в том, что AOS при попытке подключения первым делом проверяет, не является ли SID пользователя, под которым запущен клиент, SID'ом этого самого BCProxyUser, а уже потом лезет в UserInfo...

[mazzy]

Цитата:

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

Дело, наверно, в том, что AOS при попытке подключения первым делом проверяет, не относится ли SID пользователя, под которым запущен клиент, SID'ом этого самого BCProxyUser, а уже потом лезет в UserInfo...

Я согласен. Но зачем трогать таблицу бизнес-коннектора для того, чтобы входил нормальный пользователь.
Во-первых, это как-то очень подозрительно
Во-вторых, скорее всего лишает возможности запускать бизнес-коненектор

[Vladyslav]

Цитата:

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

Я согласен. Но зачем трогать таблицу бизнес-коннектора для того, чтобы входил нормальный пользователь.
Во-первых, это как-то очень подозрительно
Во-вторых, скорее всего лишает возможности запускать бизнес-коненектор

Ну, это я еще не проверял, но я не думаю, что "трогание" этой таблице лишает возможности запускать бизнес-конектор. Уж по крайней мере под другим логином или с другого компа.

Согласен, "по дороге" я кое-что сломал, но это просто потому, что торопился увидеть результат (ковырять лишнюю неделю только для получения ответа "да" или "нет" на теоретический вопрос этой темы было неохота - мог пропасть интерес). А если честно, то просто было ЛЕНЬ.

[Vladyslav]

Цитата:

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

Вот как раз при напрочь отсутствующем AD неинтересно, потому что в реальных условиях использования 4-ки AD обычно есть.Я пробовал так - не работает Правда, в моем случае AOS был в AD-домене.Не совсем так. Ведь можно изменять команды не только в исполняемом файле, но и в памяти, причем изменять именно клиентский код, чтобы он в "приветственном" сообщении посылал нужный SID...Дело, наверно, в том, что AOS при попытке подключения первым делом проверяет, не является ли SID пользователя, под которым запущен клиент, SID'ом этого самого BCProxyUser, а уже потом лезет в UserInfo...

Ну я же написал: "даже при отсутствующем AD", а не "только при отсутствующем AD", т.е. по факту самому AOS от этого AD ни холодно ни жарко.
Первый способ я проверил и он точно работает, если не работает, то можно просто SQL-профайлером посмотреть, к каким таблицам и скаким SID в запросе лезет AOS.
По поводу "в памяти" - извиняюсь, не умею, так как подмену SID пользователя на клиентский выполняет как раз сервер, а откуда он берет клиентский локальный(вместо доменного под которым подключились) я еще не разобрался (проверяя эту функциональность я "угробил" гостевой вход просто потому, что не хватило места, но можно было бы сделать и красивее).

[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 аккаунта, который выполняется на сервере.

[gl00mie]

Вообще говоря, если описанный способ сработает, то получится, что в механизме аутентификации клиента AX4 кроется здоровенная дыра. Связана она с тем, что аутентификация основывается на информации, посылаемой непосредственно клиентом AOS'у, а информация эта общедоступна. Узнать SID любого пользователя в домене (при наличии доступа к этому домену) не составляет труда: это можно сделать, к примеру, с помощью оснастки adsiedit или с помощью утилиты psgetsid из PsTools, причем никаких особенных прав на это не требуется, достаточно быть обычным пользователем в домене. А узнать SID пользователя и запустить программу под этим пользователем - это, согласитесь, «две большие разницы»

[kashperuk]

Скромненько так: "Какое-то решение появилось, кроме вышеуказанного? На 5ке кто-то проверял это?"