20.09.2006, 16:44 | #1 |
Участник
|
AX-4.0 Права для службы под которой работает сервис AOS
Добрый день, Уважаемые коллеги!
Начали изучать процесс развертывания MS Dynamics AX 4.0 и есть кое какие проблемы После установки предполагается что сервис будет AOS работать под пользователем NT AUTHORITY\NETWORK SERVICE. Но стартовать под этим пользователем AOS упорно отказался. В логах шли две следующих ошибки: =========================================== Object Server 01: Fatal SQL condition during login. Error message: "[Microsoft][ODBC SQL Server Driver][SQL Server]SqlDumpExceptionHandler: Process 62 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. =========================================== Object Server 01: SQL diagnostics: [Microsoft][ODBC SQL Server Driver][SQL Server]SqlDumpExceptionHandler: Process 62 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. . Connect information was: Userid = [], Database = [DynamicsInt], Server = [AXAPTA], DSN = [], Other = [] =========================================== Продалжая эксперименты, я запустил AOS от имени своего пользователя, под которым я заходил на сервер. Данный пользователь имеет права на базу данных(SysAdmin, Secur Admin, DataBase Creator) - токо после этих ролей установка тронулась с места, хотя возможно мы что то делали не так. Итак AOS запустился, но при попытки добавить нового пользователя и установить для него галочку Enabled выскакивает сообщение, что данный пользователь отсутствуют в Active Directory Я так полагаю что AOS все таки должен работать под NT AUTHORITY\NETWORK SERVICE , но не понимаю как эту группу добавить в пользователей SQL Server? Собственно, два вопроса: 1.Как добавить указанный логин в список пользователей СУБД? 2.Как вернуть этот логин службе AOS, когда я его указываю, то меня просят ввести пароль...вопрос какой пароль должен быть у NT AUTHORITY\NETWORK SERVICE? |
|
20.09.2006, 16:55 | #2 |
Участник
|
Цитата:
Сообщение от Lemming
Продалжая эксперименты, я запустил AOS от имени своего пользователя, под которым я заходил на сервер. Данный пользователь имеет права на базу данных(SysAdmin, Secur Admin, DataBase Creator) - токо после этих ролей установка тронулась с места, хотя возможно мы что то делали не так.
В последних 4.0.2130.0 проблем нет. Цитата:
AOS штатно работает только под Windows Server 2003. Если хочется установить на windows xp читайте http://axapta.mazzy.ru/lib/axapta40_setup/ Цитата:
Она появилась в моем SQL 2005 сама. Я дал ей роль dbcreator. Ей хватает. |
|
20.09.2006, 17:49 | #3 |
Участник
|
Европейская версия
KernelVersion: 4.0.1659.35.0 ApplicationVersion: 4.0.1659.35.0/PMF0400 Цитата:
Сообщение от mazzy
Читайте мануалы - они рулез.
AOS штатно работает только под Windows Server 2003. Если хочется установить на windows xp читайте http://axapta.mazzy.ru/lib/axapta40_setup/ SQL Server 2000 SP4. Более того, я уже ставил на аналогичную конфигурацию локально(с собственным локальным доменом итп) и там пользователь под которым по умолчанию предлагается запускать AOS добавился в СУБД, но в каком момент, в момент установки аксапты или в момент установки SQL Server я не знаю |
|
20.09.2006, 18:03 | #4 |
Участник
|
Цитата:
Не знаю. На сервере у меня проблем не было и с американской... Цитата:
Сообщение от Lemming
SQL Server 2000 SP4. Более того, я уже ставил на аналогичную конфигурацию локально(с собственным локальным доменом итп) и там пользователь под которым по умолчанию предлагается запускать AOS добавился в СУБД, но в каком момент, в момент установки аксапты или в момент установки SQL Server я не знаю
Но я эксперементировал пока только с SQL 2005. Про SQL 2000 пока ничего сказать не могу. Думаю, что надо перечитать документ по установке, особенно про требования. Особенно по части прав того, кто устанавливает. Сначала слева направо, затем справа налево (чтобы ничего не пропустить ) |
|
21.09.2006, 16:11 | #5 |
Участник
|
охх...поставили на тот же сервер, где разворачиваем AOS, 2005 SQL, все установилось. Все подготовил, вхожу со своего рабочего места клиентом, меня пускает(по умолчанию я там админ). Попробовал добавить и активировать нового пользователя, опять вылезает сообщение, что данный пользовательно остуствует в Active Directory
Сейчас AOS крутится от имени NT AUTHORITY\NETWORK SERVICE, меня пускает, но добавление новых пользователей, по прежнему не происходит. Попробовал поискать этого юзера среди локальных групп или пользователей, что бы в AD попробовать назначить ему права, но ничего не выходит. Вопрос следующий: возможно компьютер на котором работает AOS должен обладать какими либо правами на чтение структуры AD? |
|
21.09.2006, 16:43 | #6 |
Microsoft Dynamics
|
Цитата из Implementation Guide:
All Microsoft Dynamics AX users must first be defined in Active Directory. The computers running Microsoft Dynamics AX must have access to computers in the same domain running Active Directory configured in native mode. По правде говоря, ответы на все Ваши вопросы есть в Implementation Guide, предлагаю ознакомиться с этим архиполезным документом.
__________________
You should use Bing before asking dumb questions. |
|
21.09.2006, 17:02 | #7 |
Участник
|
Цитата:
Правильно ли я понял: Пользователи должны быть вперед заведены в АД - у нас заведены! Компьютеры на которых работает аксапта должны иметь доступ к компьютерам, работающим в этом домене, сконфигунрированном в native mode. Компьютеры на которых работает - речь идет об AOS или клиентских машинах или о чем вообще? И каким компьютерам первые должны иметь доступ? Домен работает в Native режиме, все юзера заведены в AD, но очевидно что AOS не видит AD и их юзеров Хотя меня пускает с моей машины , то есть меня он видит. |
|
21.09.2006, 17:18 | #8 |
Microsoft Dynamics
|
Речь идет как о клиентских машинах, так и об AOS - все они должны входить в один домен и должны иметь доступ к контроллеру домена. Создайте в домене отдельную учетную запись для AOS и запускайте сервис под ней.
__________________
You should use Bing before asking dumb questions. |
|
21.09.2006, 17:32 | #9 |
Участник
|
Цитата:
Цитата:
Более того, есть локальный домен, на котором я разварачивал аксапту 4 для первых тестов и там она спокойно работает под NT AUTHORITY\NETWORK SERVICE, хотя скорее всего, сам сервер имеет привелегированные права на АД, а возможно даже и полные, так как домен развернули на нем физически и видимо сервер на котором развернута служба каталогов и сам компьютер это в структуре АД одно целое, так как на вкладке компьютеры, его нет. |
|
21.09.2006, 17:48 | #10 |
Microsoft Dynamics
|
Полагаю, достаточно свойств обычного пользователя, который имеет доступ у информации Active Directory + право "вход в качестве службы".
__________________
You should use Bing before asking dumb questions. |
|
21.09.2006, 18:02 | #11 |
Участник
|
В том то и дело, что обычный пользователь не может читать структуру актив директори, а мануалы молчат, о том какие права на службу каталогов, должны быть у пользователя, под которым работает AOS.
|
|
21.09.2006, 18:10 | #12 |
Microsoft Dynamics
|
Кто Вам это сказал?! Интересно, а как обычный пользователь в таком случае может обращаться к ресурсам Active Directory, если не может прочитать структуру ресурсов AD (в т.ч. список пользователей домена)? И когда "обычный" пользователь устанавливает разрешения на папки на своем компьютере, разве не списком доменных пользователей он оперирует?
__________________
You should use Bing before asking dumb questions. Последний раз редактировалось Jabberwocky; 21.09.2006 в 18:18. |
|
21.09.2006, 18:34 | #13 |
Участник
|
Цитата:
Сообщение от Jabberwocky
Интересно, а как обычный пользователь в таком случае может обращаться к ресурсам Active Directory, если не может прочитать структуру ресурсов AD (в т.ч. список пользователей домена)? И когда "обычный" пользователь устанавливает разрешения на папки на своем компьютере, разве не списком доменных пользователей он оперирует?
|
|
21.09.2006, 22:13 | #14 |
Участник
|
|
|
22.09.2006, 09:23 | #15 |
Злыдни
|
Среди требований по правам нашел только это:
Сервис AOS должен иметь право на чтение информации из AD (достаточно Domain Users) Network Service на сервере AOS должен иметь права чтения и записи на папку с приложением Для взаимодействия AOS и SQL нужен доменный пользователь, которому назначены специальные роли на SQL Других специфичных требований (если не говорить о ReportService и Enterprise Portal) вроде нет |
|
22.09.2006, 17:29 | #16 |
Участник
|
Новая порция инфы, по нашей проблеме.
Сразу забыл сказать, что сервер на котором развернута служба каталогов Active Directory работает на базе ОС Windows 2000. На форме Users есть кнопочка импорт, она позволяет импортировать пользователей из списка пользователей указанного домена Active Directory. Так вот, при использовании этого мастера, в списке пользователей, я вижу только несколько служб, а так же пользователей, которые так или иначе занимаются администрированием нашего домена. |
|
25.09.2006, 08:47 | #17 |
Злыдни
|
А какому контейнеру в AD принадлежат эти пользователи? Случаем не базовому контейнеру Users? Если так, то необходимо проверять методы в классе импорта. Увы, у меня AX4 нет.
|
|
15.03.2007, 15:22 | #18 |
Участник
|
Цитата:
Сообщение от Lemming
служба каталогов Active Directory работает на базе ОС Windows 2000. На форме Users есть кнопочка импорт, она позволяет импортировать пользователей из списка пользователей указанного домена Active Directory. Так вот, при использовании этого мастера, в списке пользователей, я вижу только несколько служб, а так же пользователей, которые так или иначе занимаются администрированием нашего домена.
Цитата:
Выборку эту можно смоделировать, например, с помощью VBScript и ADSI. Во вложении - два скрипта, которые я использовал для экспериментов. Рабочий скрипт (adsi-list-user-account-groups.vbs) производит выборку, аналогичную той, что делает xAxaptaUserManager, и пишет краткую информацию о выбранных пользователях в текстовый файл; установочный скрипт (adsi-list-user-account-install.vbs) используется для установки рабочего скрипта в качестве сервиса. Сервис нужен для запуска скрипта под аккаунтом LocalSystem (при установке на w2k) либо Network Service (на wxp/w2k3), т.е. теми, которые использует по умолчанию сервис AOS. Особенности установки сервиса:
В домене с несколькими сотнями пользователей, удовлетворяющими критериям выборки, создание выходного файла может занимать до 10-15 секунд, при этом если на одной машине запустить несколько экземпляров скрипта одновременно, то это время существенно возрастет. Так вот, что, собственно получилось у меня. Я проводил тестирование на 3-х разных доменах: один с доменными контроллерами под управлением w2k, один с w2k/w2k3 доменными контроллерами, и один - только с доменными контроллерами w2k3, при этом все домены работают в windows 2000 native mode (см. kb322692). Сбор сведений производился с серверов под управлением w2k sp4 и w2k3 sp1, с правами пользователей LocalSystem, Network Service (только под w2k3), доменного администратора и простого доменного пользователя. Скажу сразу, что запускать скрипт в качестве сервиса непосредственно на доменных контроллерах бессмысленно: дело в том, что в случае DC аккаунт LocalSystem имеет полный доступ к AD, кроме того, вряд ли кто-то станет устанавливать AOS на DC. На картинке приведены результаты тестирования, цифры - количество пользователей, попавших в выборку рабочего скрипта. Разница между 21 и 22 пользователями в случае доменов w2k связана с тем, что при использовании аккаунта доменного пользователя он сам тоже попал в выборку, а и получилось на 1 объект больше, чем при использовании LocalSystem. На какие мысли наталкивают полученные результаты? Ответ, похоже, можно найти в MSDN (раздел How Security Affects Operations in Active Directory Domain Services): Цитата:
Active Directory uses access control to grant or deny access to objects, properties, and operations based on the identity of the user performing the access attempt. When your application binds to the directory, it binds with specific user credentials. When authenticated, these credentials determine your application's security context. Regardless of whether the credentials are those of the logged-on user, a specified user, a service account, a computer account, or an unauthenticated user (Guest/Everyone), Active Directory verifies the user's right to access an object before any operation is performed on that object.
... Security is an implicit filter for searching, enumerating containers, or reading properties. If you do not have the necessary access rights, attempts to list objects or read properties can fail with error even thought the object or property exists. The impact of security on read operations is not necessarily manifested as an error. For example, a search operation can succeed, but the search results do not include objects or properties to which the caller does not have access. |
|
|
За это сообщение автора поблагодарили: KiselevSA (2), Lemming (2), Kabardian (3). |
15.03.2007, 18:22 | #19 |
Участник
|
Спасибо за детальное изучение данной проблемы!
AOS крутится на машине работающей под управлением Win2003 - как только у меня появится к ней доступ, обязательно попробую Ваши скрипты и отпишусь о результате. |
|
Теги |
active directory, ax4.0 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|