Показать сообщение отдельно
Старый 04.05.2007, 11:12   #14  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
если компьютер пользователя не в домене (ноутбук), то во внутренней сети AX4.0 можно запустить при помощи команды "run as..."
Очень интересно посмотреть, как вы на компе, не входящем в домен, с помощью secondary logon создадите security cotext доменного пользователя
Цитата:
VPN пользователи подключаются в домен, а затем в терминал. VPN пользователи нормально подключаются и работают с AX4.0 через терминал.
В данном случае без разницы, vpn-овские это пользователи или нет. Т.е. при работе через терминал для компов в сети важно только то, как пользователь залогинился в терминале, а его комп может быть даже бездисковой станцией, работающей под линуксом, загруженным по сети и ничего не знающим о виндовых доменах, NTLM2-аутентификации и т.д.
Цитата:
нужно предоставить непосредственный (без терминала) доступ к Аксапте 4.0 внешним пользователям. причем, рассматривается два случая: внешним пользователем является сотрудник с своим ноутбуком (заходит из дома в домен под доменным пользователем, затем пытается войти в Аксапту 4.0)
Тут, насколько я понимаю, при заходе доменным пользователем дома без связи с доменом используется закэшированные данные из профиля пользователя. Т.е. фактически воссоздается security context, который был создан в последний раз "нормального" входа в домен с авторизацией на доменном контроллере.
Цитата:
внешний пользователь не входит в домен (из организации-партнера или наш сотрудник входит с локальной учетной записи своего ноутбука)
Если в ISA разрешить полный доступ VPN клиентов ко внутренней сети, то внешние доменные пользователи подключаются к AX4.0
Еще бы они не подключались! У них тот же SID, что был при создании пользователей в AX на основе доменных пользователей (я так понимаю, AX4 проверяет именно это).
Цитата:
Если на удаленный компьютер зайти под недоменным пользователем, то AX4.0 выдает сообщение Failed to establish connection, даже при разрешенном полном доступе VPN (что ожидалось). Однако это же сообщение появляется даже при использовании run as...
Вот с этого места поподробней... Можно расписать исходные условия и последовательность действий, грубо говоря, от включения ноута до запуска клиента AX после соединения по VPN? Если исходить из того, что для успешного подключения AX4 к имеющейся базе нужно запустить ее с SID пользователя, который прописан в базе, то надо посмотреть, какой SID у пользователя при запуске клиента AX4. Можно просто в консоли набрать whoami /user (для w2k/wxp утилиту можно взять из wxp support tools, c w2k3 она идет штатно), на экран выведется примерно такая информация:
Код:
User Name        SID
================ =============================================
ax4host\testuser S-1-5-21-2925645454-1921501322-1239600718-500
Надо проверить, чтобы такой же SID был прописан в базе AX (в UserInfo).
Цитата:
Как дать доступ в AX4.0 внешним недоменным пользователям? (кроме корпоративного портала и терминала)
На счет этого пока не скажу - надо поэкспериментировать...
Цитата:
Какие минимальные разрешения нужно выставить в ISA, чтобы опубликовать AX4.0? Хотелось бы напомнить, что сейчас используется RPC для взаимодействия AX-AOS, а давать полные разрешения VPN-клиентам как-то неспортивно.
Дык ить... Это зависит от того, что нужно при работе в AX4. В принципе, нужно что: DNS, RPC, DS, AOCP, наверно, еще и LDAP и, может, DHCP, если клиенты будут сидеть долго, и время, на которое выдан IP, истечет. В настройках ISA2004/2006 это будет выглядеть примерно так:
Код:
#  Name           Action Protocols       From/Listener To          Condition
== ============== ====== =============== ============= =========== =========
1. Intranet 2 VPN Allow  All             Intranet      VPN Clients All Users
2. VPN 2 Intranet Allow  DNS,LDAP,
                         LDAP (UDP),
                         LDAP (GC),
                         LDAPS,RPC,
                         DHCP (request),
                         DS,DS (UDP),
                         AOCP	         VPN Clients   Intranet    All Users
где DS - это 445/TCP outbound, DS (UDP) - это 445/UDP send-receive, AOCP - 2712/TCP outbound (или на каком там порту AOS у вас повешен). Впрочем, это все "на вскидку", возможно, какие-то протоколы будут лишними, например, LDAPS, а какие-то понадобится еще добавить для нормальной работы.
Чтобы еще больше "завернуть гайки", можно сделать на исходящий трафик (вместо правила №2) отдельные правила, сгруппировав протоколы по адресатам и в "To" указав computer sets с перечисленными серверами, которым этот трафик предназначен. Вообще же, на isaserver.org есть много информации на тему VPN-клиентов, например, статьи широко известного в узких кругах Thomas Shinder: Using the ISA Firewall to Configure Granular Access Controls for VPN Clients (часть 1 и 2).

Дополнение: В ISA Server 2004/2006 есть чудесный механизм мониторинга (Monitoring/Logging). Можно настроить его на трафик от Source Network = VPN Сlients, Log Time = Live, запустить запрос и при разрешенном полном доступе сделать тестовое подключение по VPN с запуском клиента AX4, выполнить там все обычные операции и завершить работу. После этого скопировать полученные строки логов и посмотреть, трафик по каким протоколам и в каких направлениях нужно разрешить клиенту для нормальной работы с AOS.

Последний раз редактировалось gl00mie; 04.05.2007 в 11:25.
За это сообщение автора поблагодарили: kashperuk (5).