[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, многое прояснится, но пока времени и душевных сил на это не хватает.