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

**mazzy** · 01.05.2007, 02:11

Торможу. Не вижу чего-то очевидного.

Есть сейчас:
1. Компания установила у себя AX4.0 (есть домен, сервер, SQL, ISA и прочие полагающиеся пироги)
2. Внутри сети пользователи в Аксапту заходят нормально
= если компьютер пользователя в домене, то с аутентификацией никаких проблем
= если компьютер пользователя не в домене (ноутбук), то во внутренней сети AX4.0 можно запустить при помощи команды "run as..."
3. Для некоторых пользователей разрешен удаленный доступ к VPN. VPN пользователи подключаются в домен, а затем в терминал. VPN пользователи нормально подключаются и работают с AX4.0 через терминал.

Что нужно:
4. нужно предоставить непосредственный (без терминала) доступ к Аксапте 4.0 внешним пользователям. причем, рассматривается два случая:
= внешним пользователем является сотрудник с своим ноутбуком (заходит из дома в домен под доменным пользователем, затем пытается войти в Аксапту 4.0)
= внешний пользователь не входит в домен (из организации-партнера или наш сотрудник входит с локальной учетной записи своего ноутбука)

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

6. Вопросы:
6.1. Как дать доступ в AX4.0 внешним недоменным пользователям? (кроме корпоративного портала и терминала)
6.2. Какие минимальные разрешения нужно выставить в ISA, чтобы опубликовать AX4.0? Хотелось бы напомнить, что сейчас используется RPC для взаимодействия AX-AOS, а давать полные разрешения VPN-клиентам как-то неспортивно.

Пожалуйста, ткните носом в документацию, если данный вопрос где-то освещен.

glibs · 01.05.2007, 05:04

Пока идет мыслительный процесс можно вопрос?

Чем не устроил WTS + аккуратно подрезанные права на файловую систему?

Вариант с доменными пользователями + установка доверительных отношений между доменами рассматривается? Сам никогда не интересовался администрированием доменов, но есть гипотеза, что это может помочь.

**mazzy** · 01.05.2007, 22:06

Цитата:

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

Пока идет мыслительный процесс можно вопрос?

Нашел и перечитал кучу доки.
Пока не понял чего я не понимаю. Ответа не нашел.

Цитата:

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

Чем не устроил WTS + аккуратно подрезанные права на файловую систему?

На худой конец можно сделать и так...
Но хотелось бы дорыть до корней.

Мысль о том, что разработчики "забыли" о внешних пользователях постоянно лезла в голову. Так обнаружил, что в последних вариантах Аксаптовских материалах отсутствует вариант тонкого внешнего клиента (есть либо WTS либо корпоративный портал). В пользу этого предположения говорит также требования 5мс задержки в канале http://www.microsoft.com/dynamics/ax...uirements.mspx

Но пока эту мысль задвигаю в сторонку как самый простой ответ.

Насколько я понимаю, сейчас вопросы авторизации и доступа внешних пользователей переложили на ОС. Что именно и как именно предполагали разработчики организовать доступ к Аксапте для внешних?

Цитата:

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

Вариант с доменными пользователями + установка доверительных отношений между доменами рассматривается?

Э-э-э... Рассамтривается. Но что тогда делать с внешними ноутбуками в рабочих группах?

В общем, хочется понять, могут ли внешние недоменные пользователи подключаться непосредственно к Аксапте? Если могут, то как это сделать?

glibs · 01.05.2007, 23:47

Цитата:

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

...
разработчики "забыли" о внешних пользователях
...

IMHO, не забыли.

В доке по порталу предлагается внешних пользователей заводить в отдельный домен, и не давать им вообще прав в домене. Потом их связывать через Business Connector Proxy с Аксаптой.

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

То, что произошло с Аксаптой, в общем-то, вписывается в общие тенденции развития контроля доступа в Windows. Речь идет об организации полного контроля сетевых администраторов над всеми ресурсами сети с одной стороны, и о возможности контролируемого ограничения возможностей всех остальных пользователей ресурсов сети теми же администраторами.

Так что врядли забыли. Специально так сделали. IMHO.

Почему ты считаешь, что Микрософт должен заботиться о лаптопах, которые подключены к рабочим группам, а не к доменам?

**mazzy** · 01.05.2007, 23:50

Цитата:

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

В доке по порталу предлагается внешних пользователей заводить в отдельный домен, и не давать им вообще прав в домене. Потом их связывать через Business Connector Proxy с Аксаптой.

Вот я и спрашиваю, где?
Можешь дать номер или ссылку на документ?

Цитата:

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

Почему ты считаешь, что Микрософт должен заботиться о лаптопах, которые подключены к рабочим группам, а не к доменам?

Почему ты считаешь, что я так считаю?

**mazzy** · 01.05.2007, 23:59

Цитата:

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

В доке по порталу предлагается внешних пользователей заводить в отдельный домен, и не давать им вообще прав в домене. Потом их связывать через Business Connector Proxy с Аксаптой.

Э... Если ты про этот документ Install and Configure a Microsoft Dynamics AX Enterprise Portal server.doc
то это только про веб-пользователей.

Я спрашивал про нормальный трехуровневый доступ.
1. У человека есть комп.
2. Комп не в домене.
3. На компе установлена Аксапта

Как этому человеку зайти на AOS, на котором он знает логин пароль и в домене, где живет AOS?

glibs · 02.05.2007, 00:05

Цитата:

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

...
Вот я и спрашиваю, где?
Можешь дать номер или ссылку на документ?
...

COURSE 8621A: WHAT'S NRW - TECHNICAL
VERSION 1.0
MICROSOFT DYNAMICS AX 4.0

Лежит на Партнерсорсе.

Цитата:

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

...
Почему ты считаешь, что я так считаю?
...

А с чего бы тогда тебе в голову лезли эти и остальные изложенные в данной ветке мысли?

"...
Мысль о том, что разработчики "забыли" о внешних пользователях постоянно лезла в голову.
..."

**mazzy** · 02.05.2007, 00:14

Цитата:

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

COURSE 8621A

Спасибо... Поищу.

Цитата:

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

А с чего бы тогда тебе в голову лезли эти и остальные изложенные в данной ветке мысли?

"...
Мысль о том, что разработчики "забыли" о внешних пользователях постоянно лезла в голову.
..."

Э-э-э... И как из этой фразы получился вывод что "Майкрософт должен заботиться о лаптопах, которые подключены к рабочим группам, а не к доменам"?

Добавлено:
Каким образом из моей фразы ты сделал вывод, что Майкрософт вообще должен о ком-то заботиться?
И с какой стати этот вывод ты приписал мне?

glibs · 02.05.2007, 00:15

Я понимаю все. Сам хотел бы найти хакерский способ. Ищу. Пока не придумал.

Цитата:

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

...
2. Комп не в домене.
3. На компе установлена Аксапта
...

Это уже нештатная ситуация. Дистрибутив отказывается запускаться на машине, если запускающий его пользователь залогонен не под доменной учетной записью.

Значит дальше мы можем говорить... ну если не о хакерстве, то по крайней мере о вообще НЕ ПОДДЕРЖИВАЕМОЙ вендором конфигурации использования его ПО.

Итого вопрос свелся к тому, как обойти умышленно реализованные ограничения на использование ПО, которые разработал вендор. Со всеми вытекающими. И без каких-либо претензий. IMHO.

**mazzy** · 02.05.2007, 00:19

Цитата:

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

Это уже нештатная ситуация. Дистрибутив отказывается запускаться на машине, если запускающий его пользователь залогонен не под доменной учетной записью.

Ну и что?
Устанавливает под доменной. Дальше перелогинивается в локальный аккаунт и запускает Аксапту (при этом может даже не выводить компьютер из домена)
Почему это не штатная ситуация?

Цитата:

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

Значит дальше мы можем говорить... ну если не о хакерстве, то по крайней мере о вообще НЕ ПОДДЕРЖИВАЕМОЙ вендором конфигурации использования его ПО.

Хм... Надо подумать...

**mazzy** · 02.05.2007, 00:25

Цитата:

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

COURSE 8621A: WHAT'S NRW - TECHNICAL
VERSION 1.0
MICROSOFT DYNAMICS AX 4.0

Лежит на Партнерсорсе.

Не совсем на Партнерсорсе.
Он лежит у тренеров в учебных материалах.

**mazzy** · 02.05.2007, 00:38

Цитата:

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

В доке по порталу предлагается внешних пользователей заводить в отдельный домен, и не давать им вообще прав в домене. Потом их связывать через Business Connector Proxy с Аксаптой.

1. Это тупиковый путь. Это веб-пользователи. Я спрашивал про обычных. Спасибо, конечно, но пожалуйста, не уводи разговор в оффтопик
2. Пожалуйста, если есть документы в открытом доступе, то лучше ссылаться на них, а не на "секретные" материалы с ограниченным доступом. Про Business Connector Proxy User http://msdn2.microsoft.com/en-us/library/aa496652.aspx

В общем, тема не раскрыта.
Если есть соображения, с удовольствием послушаю.

Morfeus · 03.05.2007, 16:23

раньше был такой Checkpoint Firewall-1, на нем можно было поднять secured logon в домен с шифрованием.

gl00mie · 04.05.2007, 11:12

Цитата:

Сообщение от 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.

AndyD · 05.05.2007, 10:12

Сергей, а если попробовать так:

1. Завести для удаленного пользователя еще одну учетную запись в Axapta связав ее с доменной записью (т.е. будет два пользователя с одним доменным именем, но разными UserId - одни для доступа из домена, один - для доступа извне). Изменить у этого пользователя SID (в таблице UserInfo) на SID локального пользователя (получить его можно как описал gl00mie, либо с помощью утилиты getsid.exe из тех же support tools)
2. Подключаться к VPN пользователем Business Connector Proxy
3. Запускать Axapta под локальной учетной записью пользователя (т.е. без всяких RunAs)

**mazzy** · 06.05.2007, 10:48

Прежде всего, спасибо gl00mie, AndyD.

Цитата:

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

Очень интересно посмотреть, как вы на компе, не входящем в домен, с помощью secondary logon создадите security cotext доменного пользователя

Цитата:

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

Еще бы они не подключались! У них тот же SID, что был при создании пользователей в AX на основе доменных пользователей (я так понимаю, AX4 проверяет именно это).

Я привел этот случай, чтобы было понятно, что в самой Аксапте проблем нет.

Цитата:

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

Вот с этого места поподробней...

Если можно, то чуть попозже.

Цитата:

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

Если исходить из того, что для успешного подключения AX4 к имеющейся базе нужно запустить ее с SID пользователя, который прописан в базе, то надо посмотреть, какой SID у пользователя при запуске клиента AX4.

клиента... это интересная и перспективная мысль...
вы думаете, что проверка выполняется на клиенте, а не на сервере?

Цитата:

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

Можно просто в консоли набрать whoami /user (для w2k/wxp утилиту можно взять из

Да, спасибо.
Но от ISA к AOS'у идут неавторизованные запросы.

Цитата:

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

Дык ить... Это зависит от того, что нужно при работе в AX4.

Дык ить... Это ж и интересует: что ей нужно? Где нибудь прописано?

Цитата:

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

В принципе, нужно что: DNS, RPC, DS, AOCP, наверно, еще и LDAP и, может, DHCP

Спасибо.
DNS, RPC, LDAP открывал... DS, AOCP попробую. DHCP не нужен поскольку ISA сам занимается IP-адресами, IMHO.
Вот бы где-нибудь увидеть полный список...

Цитата:

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

Thomas Shinder

О! Бездна секса.
Обязательно почитаю.

Цитата:

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

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

Да, спасибо.

Цитата:

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

1. Завести для удаленного пользователя еще одну учетную запись в Axapta связав ее с доменной записью (т.е. будет два пользователя с одним доменным именем, но разными UserId - одни для доступа из домена, один - для доступа извне). Изменить у этого пользователя SID (в таблице UserInfo) на SID локального пользователя (получить его можно как описал gl00mie, либо с помощью утилиты getsid.exe из тех же support tools)
2. Подключаться к VPN пользователем Business Connector Proxy
3. Запускать Axapta под локальной учетной записью пользователя (т.е. без всяких RunAs)

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

Спасибо.
Буду рад, если появятся еще идеи и советы.

AndyD · 06.05.2007, 13:59

Цитата:

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

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

А если попробовать мимо ISA, то получится подключиться как я предлагал?

**mazzy** · 06.05.2007, 14:17

Цитата:

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

А если попробовать мимо ISA, то получится подключиться как я предлагал?

Да, конечно. Внутри сети входит и выходит.
А вот снаружи - фиг.

AndyD · 06.05.2007, 14:28

Я запутался

Т.е. удалось подключиться внешним недоменным клиентом к Ax4 через VPN?

**mazzy** · 06.05.2007, 14:32

Цитата:

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

Я запутался

Т.е. удалось подключиться внешним недоменным клиентом к Ax4 через VPN?

Э-э-э. Нет.
Можно я не буду экспериментировать и убирать ISA для внешних пользователей?
Внутри сети твой способ работает.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Можно ли в Аксапте отправлять активным пользователям сообщения	Grey	DAX: Администрирование	33	02.06.2009 12:13
Сообщения пользователям в аксапте - порядок важен!	SHiSHok	DAX: Администрирование	13	03.02.2008 01:57
Как дать доступ локальному пользователю если он не в домене?	Kuat	DAX: Администрирование	1	10.12.2007 09:49
Web доступ к Аксапте	Dozer	DAX: Администрирование	8	31.08.2005 12:48
Доступ к Аксапте из внешнего приложения	DenisS	DAX: Программирование	4	13.01.2004 13:57