При отключении доступа к .Net Business Connector все равно удается подключиться к AX

[gl00mie]

Цитата:

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

доступ к AX внешнему приложению на C# через .Net Business Connector. Версия AX 2009 SP1.
Для доступа к Аксапте извне в домене заведен новый пользователь. Для пользователя создана группа прав, которой в правах доступа включен полный доступ ко всем узлам Business Connector (как к основному, так и ко вложенным) Логин и домен пользователя прописаны в Администрирование -> Настройка -> Контроль доступа - > Системные служебные счета -> в группе полей Business Connector Proxy.

Это не совсем тот способ настройки, который рекомендует Microsoft. В системных служебных счетах прописывается т.н. Business Connector Proxy - специальная учетка, под которой к Аксапте будут подключаться сторонние системы "вообще", включая Корпоративный портал на SharePoint и службу SSRS. Доменная учетка BC Proxy, согласно рекомендациям, вообще не должна быть пользователем Аксапты. Если же вы хотите дать доступ к Аксапте какому-то специфическому приложению (не порталу и не SSRS) и вручную хотите рулить доступом этого приложения в Аксапту, тогда надо завести для него аксаптового пользователя, но не прописывать учетку приложения в настройки BC Proxy. Вот тогда вы сможете назначать учетке этого стороннего приложения права в Аксапте через штатный контроль доступа.

[Mikky]

Цитата:

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

Это не совсем тот способ настройки, который рекомендует Microsoft. В системных служебных счетах прописывается т.н. Business Connector Proxy - специальная учетка, под которой к Аксапте будут подключаться сторонние системы "вообще", включая Корпоративный портал на SharePoint и службу SSRS. Доменная учетка BC Proxy, согласно рекомендациям, вообще не должна быть пользователем Аксапты. Если же вы хотите дать доступ к Аксапте какому-то специфическому приложению (не порталу и не SSRS) и вручную хотите рулить доступом этого приложения в Аксапту, тогда надо завести для него аксаптового пользователя, но не прописывать учетку приложения в настройки BC Proxy. Вот тогда вы сможете назначать учетке этого стороннего приложения права в Аксапте через штатный контроль доступа.

Пробовал и так, но еще раз повторил сейчас.

Убрал данные учетки из настройки ВС Proxy, перезагрузил AOS на всякий случай.
Пользователь "test" в домене "test.ru" и присутствует как пользователь в АX.
В группе прав доступа, к которой он принадлежит, отключены все ключи, вот числе и Business Connector.
Если зайти под этим пользователем в Аксапту, то ему ничего не доступно, только открывается пустое клиентское приложение.

Пытаюсь подключиться внешним приложением, коннект все равно проходит, данные таблиц Аксапты доступны.

Получается, любой пользователь, у которого есть доступ в AX, но нет прав на Business Connector, может написать простенькое приложение, и вытаскивать любые данные из AX, либо запускать бизнес-логику???

[Dreadlock]

Мне казалось группе прав можно дать доступ на конкретные таблицы, поля, пункты меню, контролы на форме и т.д. Может у вас полный доступ для пользователя Ах настроен?

[Mikky]

Цитата:

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

Мне казалось группе прав можно дать доступ на конкретные таблицы, поля, пункты меню, контролы на форме и т.д. Может у вас полный доступ для пользователя Ах настроен?

У пользователя в дереве прав доступа не включено ни одной галочки.

[gl00mie]

Цитата:

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

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

На счет возможности подключиться через BC при отсутствии прав на соотв. ключ контроля доступа - это пока загадка В остальном же, действительно, ключи контроля доступа для различных модулей системы на работу BC практически не влияют. Исключение составляет часть критически важных таблиц (в основном транзакционные), имеющих свойство AOSAuthorization, отличное от None: для них при любом из установленных в свойстве типов CRUD-операций AOS проверяет наличие доступа у текущего пользователя к ключу контроля доступа, прописанному в свойствах таблицы. Если доступа нет, то операция завершится ошибкой, в том числе при вызове из BC. Попробуйте, к примеру через BC считать данные из LedgerTrans. В стандартном коде разносок, выполняющемся на сервере, AOSAuthorization временно отключается, таким образом, без прав на ключи контроля доступа создавать/изменять/удалять данные в таблицах с AOSAuthorization можно только через код разносок, а напрямую - нельзя.
Аналогично, ряд "опасных API", таких как интеграция на сервере с .NET и COM, методы класса WinAPIServer, доступ к файлам через TextBuf, AsciiIO и проч., защищены с помощью разрешений на доступ к коду (code access permissions). Если попытаться через BC вызвать такие "опасные API" на сервере, то это тоже закончится ошибкой времени выполнения.

[Mikky]

Все верно.
Именно так и работает с доступом к важным таблицам и "опасным API".
Верно и то, что доступ к BC, дает доступ ко всем данным и бизнес-логике, кроме только что упомянутых "критических", даже если отключить все ключи. Хотя это тоже неправильно, и по-хорошему доступ должен регулироваться.

Но вот эта самая загадка, она у всех так работает?
Может какие-то обновления выходили на залатывание этой дыры?