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

[_A_]

приветствую всех участников

Сергей, чем закончились эксперименты, поделись плз?

[mazzy]

Цитата:

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

приветствую всех участников

Сергей, чем закончились эксперименты, поделись плз?

Ничем. Пока дал доступ через Remote Desktop.

Пробовал ISA2006. Но к нему надо пристегнуть Identity Integration Server, чтобы бездоменные пользователи маппились в доменных.
Возобновлю эксперименты, когда будет чуть посвободнее..

[gl00mie]

Цитата:

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

Ничем. Пока дал доступ через Remote Desktop. Пробовал ISA2006. Но к нему надо пристегнуть Identity Integration Server, чтобы бездоменные пользователи маппились в доменных.

Не все так просто На самом деле, как выяснилось, VPN-пользователи и так представляются для серверов как доменные, если использовать для VPN-авторизации учетные данные именно доменного пользователя с разрешенным dial-in, а в качестве клиентской системы - wxp/w2k3. Другое дело, что для AX4 этого оказывается недостаточно...

Цитата:

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

Возобновлю эксперименты, когда будет чуть посвободнее..

Аналогично. Пока выложу, что удалось раскопать на данный момент.

[mazzy]

Цитата:

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

VPN-пользователи и так представляются для серверов как доменные, если использовать для VPN-авторизации учетные данные именно доменного пользователя с разрешенным dial-in, а в качестве клиентской системы - wxp/w2k3.

Да.

Цитата:

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

Другое дело, что для AX4 этого оказывается недостаточно...

Именно!

Такое ощущение, что авторизация происходит на клиенте. Т.е. запрашиваются учетные данные на хосте на котором сидит пользователь, а не учетные данные пользователя, из-под которого он входит на AOS.
И это просто бесит и выводит из себя.

Цитата:

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

Аналогично. Пока выложу, что удалось раскопать на данный момент.

Спасибо. Будет очень интересно.

[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 этого пользователя на удаленной машине или удаленном домене?

[gl00mie]

Цитата:

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

Такое ощущение, что авторизация происходит на клиенте. Т.е. запрашиваются учетные данные на хосте на котором сидит пользователь, а не учетные данные пользователя, из-под которого он входит на AOS.

Нет, по моим наблюдениям авторизация все же происходит на сервере, но используются учетные данные пользователя, под которым непосредственно запущен клиент AX4, а не те, которые были использованы при доступе к хосту AOS. Механизм примерно такой: клиент AX4 получает в строковом представлении SID пользователя, соответствующий primary access token его основного потока (thread), и передает его в качестве одного из параметров RPC-вызова на сервер. В качестве еще одного из параметров передается адрес переменной, куда сервер пишет код возврата (что-то вроде COMVariantInOut::Out_retVal). Сервер обрабатывает полученные данные и возвращает клиенту код завершения, который NdrClientCall2 записывает по адресу переданной переменной. Клиент анализирует эту переменную и, если что-то не так, выдает соответствующее сообщение.

[mazzy]

Цитата:

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

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

Ту же самую: Failed to logon to Axapta

Цитата:

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

Нет, по моим наблюдениям авторизация все же происходит на сервере, но используются учетные данные пользователя, под которым непосредственно запущен клиент AX4, а не те, которые были использованы при доступе к хосту AOS.

Ок. Пусть так.
Как исправить?

[KiselevSA]

Цитата:

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

Нет, по моим наблюдениям авторизация все же происходит на сервере, но используются учетные данные пользователя, под которым непосредственно запущен клиент AX4, а не те, которые были использованы при доступе к хосту AOS ...

Т.е. получается, что для решения проблемы:
a) надо использовать VPN для логина на сервер;
б) запускать клиента Axapta через runas с повторением ввода о логине?
Или и этот трюк не проходит? (Извините за излишние вопросы, сижу на клиенте, четверки и тестового полигона для проверки нет )

[gl00mie]

Цитата:

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

Т.е. получается, что для решения проблемы:
a) надо использовать VPN для логина на сервер;
б) запускать клиента Axapta через runas с повторением ввода о логине?
Или и этот трюк не проходит? (Извините за излишние вопросы, сижу на клиенте, четверки и тестового полигона для проверки нет )

Получается, что:
1) для VPN-авторизации на RAS нужно использовать данные доменного пользователя (а не, скажем, локального пользователя RAS-хоста), что проблемы не составляет;
2) запускать клиента Axapta надо под доменным пользователем (покуда не найден иной способ), а, следовательно, клиентская машина должна входить в домен, в котором работает машина с AOS, - вот в этом-то основная проблема

PS. У меня в качестве тестового полигона - две виртуалки под VMware.

[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]

Цитата:

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

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

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

[Vladyslav]

Цитата:

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

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

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

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

[oleg_e]

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

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

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