AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.02.2007, 12:40   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
Amand: Доступ в Microsoft Dynamics AX 4.0 без Active Directory
Источник: http://www.amand.ru/modules/wordpress/archives/17
==============

Так уж получилось, что мне регулярно приходится анализировать «чужие» базы Аксапты. И, как следствие, «взламывать» доступ к ним (всё в пределах разрешённого, клиент сам хочет, чтобы его базу взломали ;) ).С версиями Axapta 2.5 и 3.0 процедура получения доступа в восстановленной базе была предельна проста – удаляешь пароли у всех пользователей простейшим скриптом (типа update [...]

Источник: http://www.amand.ru/modules/wordpress/archives/17
Старый 26.02.2007, 13:21   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Следующий улучшайзер, который может появиться, это скрипт на T-SQL, который правит параметры пользователя admin автоматически...

Не согласен, что это "взлом".
Для проведения такой операции нужен доступ к базе.
Взлом, это несанкционированное получение доступа.

Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях.

По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/

На практике это означает, что надо держать 2 набора логинов.
1. для АОСа - с полными правами
2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав.

Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права...

В общем, тема благодатная.
Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?
__________________
полезное на axForum, github, vk, coub.
Старый 26.02.2007, 13:39   #3  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё. Никакой интеграции прав доступа реально нет. Впрочем, это и не декларируется. Но зачем указан идентификатор пользователя в AD вместо варианта пользователь/домен? Старый добрый способ, только на другой лад? По сути, ничего же не поменялось. Или я что-то не понимаю?
__________________
Михаил Андреев
https://www.amand.ru
За это сообщение автора поблагодарили: mazzy (5).
Старый 26.02.2007, 13:51   #4  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от mazzy Посмотреть сообщение
Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях.

По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/

На практике это означает, что надо держать 2 набора логинов.
1. для АОСа - с полными правами
2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав.

Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права...

В общем, тема благодатная.
Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?
Ну, не знаю. На мой взгляд "чайника" проще выделить SQL сервер в отдельную сетку, куда никто, кроме админов, доступа не имеет. А профайлер можно и из AX смотреть. Средства есть.
__________________
Михаил Андреев
https://www.amand.ru
Старый 26.02.2007, 13:51   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Михаил Андреев Посмотреть сообщение
Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё. Никакой интеграции прав доступа реально нет.
(удалил длинный текст)
Интересное наблюдение...
Надо подумать.
__________________
полезное на axForum, github, vk, coub.
Старый 26.02.2007, 15:36   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Михаил Андреев Посмотреть сообщение
Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo.
Мне кажется, UserInfo - это скорее legacy механизм. Конечно, по хорошему интеграция должна быть на таком уровне: при установке AX в домене обновляется схема AD, пользователям и группам добавляются дополнительные атрибуты, как это происходит при установке Exchange Server, затем и информация о пользователе берется каждый раз из AD, и права доступа привязываются к группам из AD. Однако здесь есть свои заковырки:
  • есть поля CreatedBy, ModifiedBy в таблицах, для которых длина SID великовата;
  • есть куча кода, обращающегося к UserInfo и мало приспособленного к работе с AD;
  • есть необходимость работать с базой без связи с исходным доменом (скажем, на ноутбуке);
  • мало ли чего еще...
Поэтому "вот так сразу", видимо, отказаться от UserInfo не получится.
Цитата:
Но зачем указан идентификатор пользователя в AD вместо варианта пользователь/домен? Старый добрый способ, только на другой лад? По сути, ничего же не поменялось. Или я что-то не понимаю?
SID однозначно идентифицирует пользователя из определенного домена, а связка SAM Account Name (логин в терминах AD) и DNS/NETBIOS Domain Name - нет. Логин может быть изменен, при том что пользователь (т.е. объект в AD и его SID) останется тот же самый; домен может быть переименован, причем могут измениться как оба названия (DNS и NETBIOS) домена, так и отдельно одно из них, при этом SID'ы объектов в AD останутся прежними. Поэтому полагаться на пару логин+домен в плане идентификации пользователей Windows-доменов нельзя. В виндах привязка пользователей/групп к тем же доменным политикам, спискам контроля доступа (ACL) и т.п. всегда идет по SID.
Старый 26.02.2007, 15:52   #7  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях. По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/
На практике это означает, что надо держать 2 набора логинов.
1. для АОСа - с полными правами
2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав.
Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права...
Ограничение прав доступа администраторов - это абсурд. Применительно к администраторам может imho работать только один способ ограничения доступа к информации: криптографическая защита (как, например, это делается при шифровании файлов средствами NTFS). Вспомним хотя бы о том, что кроме настройки параметров БД с помощью профайлера администраторы занимаются еще и созданием резервных копий баз, которые можно потом разрвенуть на совершенно другом сервере с совершенно другими правами доступа.
Цитата:
В общем, тема благодатная. Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?
Если разделение прав доступа нацелено на снижение вероятности и тяжести последствий НСД (несанкционированного доступа), то здесь в первую очередь надо сформулировать модели нарушителей, а уже потом на основании этих моделей думать, как разделять права доступа.
Старый 26.02.2007, 15:53   #8  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Поэтому "вот так сразу", видимо, отказаться от UserInfo не получится.SID однозначно идентифицирует пользователя из определенного домена, а связка SAM Account Name (логин в терминах AD) и DNS/NETBIOS Domain Name - нет. Логин может быть изменен, при том что пользователь (т.е. объект в AD и его SID) останется тот же самый; домен может быть переименован, причем могут измениться как оба названия (DNS и NETBIOS) домена, так и отдельно одно из них, при этом SID'ы объектов в AD останутся прежними. Поэтому полагаться на пару логин+домен в плане идентификации пользователей Windows-доменов нельзя. В виндах привязка пользователей/групп к тем же доменным политикам, спискам контроля доступа (ACL) и т.п. всегда идет по SID.
Это все понятно, что SID не меняется при сих изменениях. Только вопрос. Поменяли мы имя домена (поменяли зону, например). В AX в таблице UserInfo данные обновятся? Вряд ли. Но они там тоже есть. Тогда какую смысловую нагрузку они несут? То, что для идентификации не используются, понятно - SIDа до ушей хватает.
Такое ощущение, что единственное изменение по доступу - замена проверки пользователя с комбинации пользователь/домен в 3.0 на SID в 4.0.
Но явных преимуществ сего действа я не вижу. Зато проблем стало вагон: без AD нового пользователя не добавить, тестовую базу из боевой быстро не приготовишь, при тестировании под чужим именем не войдёшь.
__________________
Михаил Андреев
https://www.amand.ru
Старый 26.02.2007, 16:21   #9  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Источник: http://www.amand.ru/modules/wordpress/archives/17
==============
Ищете запись в реестре о своей учётной записи, она лежит примерно по адресу типа HKEY_USERS\S-1-5-21-3315197946-3928004927-2519785031-500\Software\Microsoft\Active Setup\Installed Components\{44BBA840-CC51-11CF-AAFA-00AA00B6015C} и значение данного параметра является именем Вашей учётной записи.
В данном случае предлагается сопоставить логин текущего пользователя и его SID через параметры установки Microsoft Outlook Express (GUID {44BBA840-CC51-11CF-AAFA-00AA00B6015C} относится именно к нему), при том что он может в общем случае и не быть установлен на компьютере. Наверно, более надежно будет смотреть, для какого SID текущий логин будет указан в качестве значения "Logon User Name” в ветках HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer
Цитата:
Короче, достаточно в REGEDIT по поиску найти имя Вашей учётной записи.
логин текущего пользователя может много где встречаться в реестре, в т.ч. и в ветке HKLM (например, в значении HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName), не сочтите за занудство
В любом случае, очень полезный рецепт запуска AX4 под "левым" пользователем.
Старый 26.02.2007, 17:17   #10  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Михаил Андреев Посмотреть сообщение
Это все понятно, что SID не меняется при сих изменениях. Только вопрос. Поменяли мы имя домена (поменяли зону, например). В AX в таблице UserInfo данные обновятся? Вряд ли. Но они там тоже есть. Тогда какую смысловую нагрузку они несут?
Imho все это дублирование данных из AD служит для того, чтобы нормально работал старый код, который напрямую в AD лазить не умеет.
Цитата:
Такое ощущение, что единственное изменение по доступу - замена проверки пользователя с комбинации пользователь/домен в 3.0 на SID в 4.0.
Пардон, одно дело - аутентификация по логину/паролю, прописанному в табличке SQL-базы, и совсем другое - аутентификация средствами Windows и управление пользователями на уровне домена AD; по крайней мере, не авторизовавшись в системе под тем или иным пользователем (надо знать его пароль в домене, да еще чтобы пользователь не был заблокирован) технически весьма проблематично создать security context с SID нужного пользователя.
Цитата:
Но явных преимуществ сего действа я не вижу.
Теперь для входа в систему необходимо знать логин/пароль доменного пользователя; администраторы могут управлять возможностью существующих пользователей AX работать в системе на уровне домена AD, а не на уровне той или иной БД Axapta. А на уровне домена AD для пользователя можно задать, с каких рабочих станций он может логиниться, в какие часы он может работать в домене, а в какие - нет, через доменную политику можно задать, как часто он должен менять пароль, какой длины и сложности этот пароль должен быть...
Цитата:
Зато проблем стало вагон: без AD нового пользователя не добавить
эх, надо будет все-таки на досуге поиграться с ADAM
Цитата:
тестовую базу из боевой быстро не приготовишь
это почему же? что мешает автоматизировать перебивание SID'ов в UserInfo тестовой базы?
Цитата:
при тестировании под чужим именем не войдёшь.
обычно нужно входить не столько под чьим-то именем, сколько с правами той или иной группы. Достаточно создать тестовый логин и изменять его членство в группах пользователей.

Последний раз редактировалось gl00mie; 26.02.2007 в 17:25.
Старый 27.02.2007, 06:09   #11  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от gl00mie Посмотреть сообщение
В данном случае предлагается сопоставить логин текущего пользователя и его SID через параметры установки Microsoft Outlook Express (GUID {44BBA840-CC51-11CF-AAFA-00AA00B6015C} относится именно к нему), при том что он может в общем случае и не быть установлен на компьютере. Наверно, более надежно будет смотреть, для какого SID текущий логин будет указан в качестве значения "Logon User Name” в ветках HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer
логин текущего пользователя может много где встречаться в реестре, в т.ч. и в ветке HKLM (например, в значении HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName), не сочтите за занудство
В любом случае, очень полезный рецепт запуска AX4 под "левым" пользователем.
По поводу реестра принято. Мне было абсолютно все равно, откуда SID брать. А ветка Microsoft Outlook Express была выше
Как под "левым" пользователем входить, понятно: делаешь на своем компе нового пользователя, прописываешь его в AX и всё. Можно даже сделать ярлык, который будет запускать AX от "левого" пользователя
__________________
Михаил Андреев
https://www.amand.ru
За это сообщение автора поблагодарили: Lemming (2).
Старый 27.02.2007, 09:28   #12  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Михаил Андреев Посмотреть сообщение
Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё.
Не только: еще проверка производится при внесение изменений в параметры.
Один из вариантов - пользоваться виртуальными машинами.

С Уважением,
Георгий
Старый 27.02.2007, 09:44   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Ограничение прав доступа администраторов - это абсурд
А где я говорил, про ограничение прав администраторов?
Я говорил про ограничение прав к данным. Эта задача актуальна не для администраторов, а для консультантов-программистов.

Должен ли консультант иметь возможность непосредственной правки UserInfo.SID?
Через Аксапту - да, а через EM - нет.
Также он не должен иметь возможность правки через ODBC, ADO и другое.
Только через Аксапту.
__________________
полезное на axForum, github, vk, coub.
Старый 27.02.2007, 09:50   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Один из вариантов - пользоваться виртуальными машинами.
George, См исходную тему.

В исходной теме Михаил говорит о доступе к базам клиентов. Базы клиентов не на виртуальной машине.
Если создать виртуальную машину и перенести туда базу, то SID все равно будут другими.

Виртуальная машина решит проблему только демобаз.
И вряд ли решит другие проблемы.
__________________
полезное на axForum, github, vk, coub.
Старый 27.02.2007, 13:04   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
А где я говорил, про ограничение прав администраторов?
Цитата:
Сообщение от mazzy Посмотреть сообщение
На практике это означает, что надо держать 2 набора логинов.
1. для АОСа - с полными правами
2. для захода из Enterprise Manager для администраторов, программеров и консультантов, у которыхна таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав.
Цитата:
Я говорил про ограничение прав к данным. Эта задача актуальна не для администраторов, а для консультантов-программистов.
Возможно, я просто неправильно понял, и имелось в виду, что нужно иметь 3 набора паролей: для AOS, для администраторов Axapta/СУБД, для консультантов-программистов.
Цитата:
Должен ли консультант иметь возможность непосредственной правки UserInfo.SID?
Через Аксапту - да, а через EM - нет. Также он не должен иметь возможность правки через ODBC, ADO и другое. Только через Аксапту.
На практике это означает, что консультант не должен иметь возможность:
  1. получать доступ к машине, где запускается AOS, и, соотв., его настройкам (узнает пароль на полный доступ к БД);
  2. иметь возможность запускать AX в двухзвенке на рабочей базе (опять-таки, узнает пароль из конфигурации).
Впрочем, при определенных условиях и это может не помочь. Отсюда следует, что:
  • вырисовывается четкая роль администратора Axapta, который имеет полный доступ к рабочей БД, поскольку ему необходимо настраивать AOS(ы);
  • именно этот администратор должен отвечать за перенос изменений на рабочее приложение, потому что для этого приходится запускать AX в двухзвенке (см., например, тему Меточные файлы).
Цитата:
Сообщение от mazzy Посмотреть сообщение
Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?
Интересная тема Надо будет подумать, какие роли тут возникают, и какие им надо раздать права...
Старый 27.02.2007, 13:11   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
ага. виноват. администраторов зря перечислил.

согласен, тема стоит того, чтобы над ней подумать.
__________________
полезное на axForum, github, vk, coub.
Старый 14.09.2007, 16:09   #17  
rser is offline
rser
Участник
 
13 / 11 (1) +
Регистрация: 21.11.2006
Может кто сталкивался? Как войти в AX4.0 под разными пользователями одновременно с одного компа. Т.е. в тройке когда я настраивал права доступа я одновременно заходил под админом и тестовым пользователем, под админом делаешь настроику, заходишь под тестовым проверяешь что получилось. Сейчас занялся изучением четверки, не могу понять как реализовать такой механизм. Тестового пользователя в домене завести не проблема, а вот как одновременно под разными именами подключиться не понимаю. Тут писали что можно как то сделать ярлык для запуска, можно по подробнее как?
Старый 14.09.2007, 16:18   #18  
MironovI is offline
MironovI
Участник
 
724 / 77 (4) ++++
Регистрация: 30.05.2005
run as вас спасет
Старый 14.09.2007, 17:40   #19  
rser is offline
rser
Участник
 
13 / 11 (1) +
Регистрация: 21.11.2006
Цитата:
Сообщение от MironovI Посмотреть сообщение
run as вас спасет
Спасибо! Решение было перед носом!
Старый 27.12.2012, 09:21   #20  
sable102 is offline
sable102
Участник
Аватар для sable102
Злыдни
 
34 / 21 (1) +++
Регистрация: 22.07.2011
Адрес: тундра
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Источник: http://www.amand.ru/modules/wordpress/archives/17
==============

Так уж получилось, что мне регулярно приходится анализировать «чужие» базы Аксапты.[...]

Источник: http://www.amand.ru/modules/wordpress/archives/17
Цитата:
А если аос и база гдето в сети (в домене к томуже, а ты нет), этот номер не проходит (по крайне мере у меня не получилось)
Лекарство есть?
Источник: http://www.amand.ru/modules/wordpres...17#comment-264
AX 4.0
У меня тоже не получилось зайти в систему, не авторизует. Машине не в домене, аос в сети.
так есть ли лекарство?
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Dynamics AX: WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack Blog bot DAX Blogs 0 10.03.2009 16:05
Dynamics AX: Microsoft's strategy and vision for Dynamics AX and SOA Blog bot DAX Blogs 0 05.03.2009 18:05
Dynamics AX: Microsoft Dynamics AX Enterprise Portal - Team Blog Blog bot DAX Blogs 0 23.07.2008 19:05
Inside Dynamics AX 4.0: Usage Scenarios Blog bot DAX Blogs 0 04.10.2007 05:15
Что дает интеграция Microsoft Dynamics AX с Active Directory??? nicko DAX: Администрирование 10 23.04.2007 23:27
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.