|  16.10.2015, 17:59 | #1 | 
| Участник | При отключении доступа к .Net Business Connector все равно удается подключиться к AX 
			
			Добрый день! Не могу разобраться с настройкой доступа к AX внешнему приложению на C# через .Net Business Connector. Версия AX 2009 SP1. Для доступа к Аксапте извне в домене заведен новый пользователь. Для пользователя создана группа прав, которой в правах доступа включен полный доступ ко всем узлам Business Connector (как к основному, так и ко вложенным) Логин и домен пользователя прописаны в Администрирование -> Настройка -> Контроль доступа - > Системные служебные счета -> в группе полей Business Connector Proxy. Подключение внешнего приложения проходит успешно, данные таблиц Аксапты доступны. Отключаю в группе прав, к которой принадлежит пользователь, доступ ко все узлам Business Connector (как к основному, так и ко вложенным). Подключение все равно происходит, данные таблиц Аксапты доступны! Замечу, что оба раза в активных пользователях появляется пользователь Business Connector, а в гриде 2 пользователя: один с типом сеанса Рабочий, другой с типом сеанса Business Connector. После выполнения кода оба пользователя пропадают, и в активных пользователях нет пользователя Business Connector. При этом если я пытаюсь присоединиться в Аксапте через ax.Logon() под своим текущим пользователем, то настройка отключения доступа к Business Connector работает. В первом случае удается подключиться, во втором нет. Кто-нибудь сталкивался с подобным? Не могу никак разобраться, что я не так делаю. Привожу, как пример, код, который при нажатии на кнопку выводит в окне формы код номенклатуры. Код:  
            System.Net.NetworkCredential login;
            String inventItemIdField = "ItemId";
            Object inventItemId;
            using (Axapta ax = new Axapta())
            {
                try
                {
                    login = new System.Net.NetworkCredential("test", "test");
                    
                    ax.LogonAs("test", "test.ru", login, "aaa", "ru", "axapta-01.test.ru:2712", "");
                    
//                    ax.Logon("aaa", "ru", "axapta-01.test.ru:2712", null);
                    AxaptaRecord axRecord = ax.CreateAxaptaRecord("InventTable");
                    axRecord.ExecuteStmt( "select * from %1");
                    axRecord.Next();
                    inventItemId = axRecord.get_Field(inventItemIdField);
                    richTextBox1.Text = (string)inventItemId;
                                        
                    ax.Logoff();
                }
                catch (Exception excep)
                {
                    richTextBox1.Text = excep.Message;
                    ax.Logoff();
                }
            } | 
|  | 
|  16.10.2015, 18:51 | #2 | 
| Участник | Цитата: 
		
			Сообщение от Mikky
			   доступ к AX внешнему приложению на C# через .Net Business Connector. Версия AX 2009 SP1. Для доступа к Аксапте извне в домене заведен новый пользователь. Для пользователя создана группа прав, которой в правах доступа включен полный доступ ко всем узлам Business Connector (как к основному, так и ко вложенным) Логин и домен пользователя прописаны в Администрирование -> Настройка -> Контроль доступа - > Системные служебные счета -> в группе полей Business Connector Proxy. | 
|  | |
| За это сообщение автора поблагодарили: EVGL (3), Stitch_MS (3), alex55 (5). | |
|  19.10.2015, 10:11 | #3 | 
| Участник | Цитата: 
		
			Сообщение от gl00mie
			   Это не совсем тот способ настройки, который рекомендует Microsoft. В системных служебных счетах прописывается т.н. Business Connector Proxy - специальная учетка, под которой к Аксапте будут подключаться сторонние системы "вообще", включая Корпоративный портал на SharePoint и службу SSRS. Доменная учетка BC Proxy, согласно рекомендациям, вообще не должна быть пользователем Аксапты. Если же вы хотите дать доступ к Аксапте какому-то специфическому приложению (не порталу и не SSRS) и вручную хотите рулить доступом этого приложения в Аксапту, тогда надо завести для него аксаптового пользователя, но не прописывать учетку приложения в настройки BC Proxy. Вот тогда вы сможете назначать учетке этого стороннего приложения права в Аксапте через штатный контроль доступа. Убрал данные учетки из настройки ВС Proxy, перезагрузил AOS на всякий случай. Пользователь "test" в домене "test.ru" и присутствует как пользователь в АX. В группе прав доступа, к которой он принадлежит, отключены все ключи, вот числе и Business Connector. Если зайти под этим пользователем в Аксапту, то ему ничего не доступно, только открывается пустое клиентское приложение. Пытаюсь подключиться внешним приложением, коннект все равно проходит, данные таблиц Аксапты доступны. Получается, любой пользователь, у которого есть доступ в AX, но нет прав на Business Connector, может написать простенькое приложение, и вытаскивать любые данные из AX, либо запускать бизнес-логику??? Последний раз редактировалось Mikky; 19.10.2015 в 10:13. | 
|  | 
|  20.10.2015, 09:06 | #4 | 
| Участник | 
			
			Мне казалось группе прав можно дать доступ на конкретные таблицы, поля, пункты меню, контролы на форме и т.д. Может у вас полный доступ для пользователя Ах настроен?
		 | 
|  | 
|  20.10.2015, 09:40 | #5 | 
| Участник | |
|  | 
|  20.10.2015, 10:44 | #6 | 
| Участник | Цитата: 
		
			Сообщение от Mikky
			   В группе прав доступа, к которой он принадлежит, отключены все ключи, вот числе и Business Connector. Пытаюсь подключиться внешним приложением, коннект все равно проходит, данные таблиц Аксапты доступны. Получается, любой пользователь, у которого есть доступ в AX, но нет прав на Business Connector, может написать простенькое приложение, и вытаскивать любые данные из AX, либо запускать бизнес-логику???  В остальном же, действительно, ключи контроля доступа для различных модулей системы на работу BC практически не влияют. Исключение составляет часть критически важных таблиц (в основном транзакционные), имеющих свойство AOSAuthorization, отличное от None: для них при любом из установленных в свойстве типов CRUD-операций AOS проверяет наличие доступа у текущего пользователя к ключу контроля доступа, прописанному в свойствах таблицы. Если доступа нет, то операция завершится ошибкой, в том числе при вызове из BC. Попробуйте, к примеру через BC считать данные из LedgerTrans. В стандартном коде разносок, выполняющемся на сервере, AOSAuthorization временно отключается, таким образом, без прав на ключи контроля доступа создавать/изменять/удалять данные в таблицах с AOSAuthorization можно только через код разносок, а напрямую - нельзя. Аналогично, ряд "опасных API", таких как интеграция на сервере с .NET и COM, методы класса WinAPIServer, доступ к файлам через TextBuf, AsciiIO и проч., защищены с помощью разрешений на доступ к коду (code access permissions). Если попытаться через BC вызвать такие "опасные API" на сервере, то это тоже закончится ошибкой времени выполнения. | 
|  | |
| За это сообщение автора поблагодарили: alex55 (-2), Mikky (1). | |
|  20.10.2015, 11:21 | #7 | 
| Участник | 
			
			Все верно. Именно так и работает с доступом к важным таблицам и "опасным API". Верно и то, что доступ к BC, дает доступ ко всем данным и бизнес-логике, кроме только что упомянутых "критических", даже если отключить все ключи. Хотя это тоже неправильно, и по-хорошему доступ должен регулироваться. Но вот эта самая загадка, она у всех так работает? Может какие-то обновления выходили на залатывание этой дыры? Последний раз редактировалось Mikky; 20.10.2015 в 11:31. | 
|  | 
| Теги | 
| logonas, интеграция, business connector | 
|  | 
| 
 |