Amand: Доступ в Microsoft Dynamics AX 4.0 без Active Directory

[Blog bot]

Источник: http://www.amand.ru/modules/wordpress/archives/17
==============

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

Источник: http://www.amand.ru/modules/wordpress/archives/17

[mazzy]

Следующий улучшайзер, который может появиться, это скрипт на T-SQL, который правит параметры пользователя admin автоматически...

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

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

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

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

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

В общем, тема благодатная.
Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?

[Михаил Андреев]

Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё. Никакой интеграции прав доступа реально нет. Впрочем, это и не декларируется. Но зачем указан идентификатор пользователя в AD вместо варианта пользователь/домен? Старый добрый способ, только на другой лад? По сути, ничего же не поменялось. Или я что-то не понимаю?

[Михаил Андреев]

Цитата:

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

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

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

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

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

В общем, тема благодатная.
Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?

Ну, не знаю. На мой взгляд "чайника" проще выделить SQL сервер в отдельную сетку, куда никто, кроме админов, доступа не имеет. А профайлер можно и из AX смотреть. Средства есть.

[mazzy]

Цитата:

Сообщение от Михаил Андреев

Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё. Никакой интеграции прав доступа реально нет.

(удалил длинный текст)
Интересное наблюдение...
Надо подумать.

[gl00mie]

Цитата:

Сообщение от Михаил Андреев

Меня другое удивило. Оказалось, что реально 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.

[gl00mie]

Цитата:

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

Отдельная тема - это ограничение доступа к таблицам на уровне SQL от несанкционированного доступа к информации о лицензиях, пользователях и паролях. По поводу ограничения доступа для подобных действий в свое время писалось здесь http://axapta.mazzy.ru/lib/2db_owner/
На практике это означает, что надо держать 2 набора логинов.
1. для АОСа - с полными правами
2. для захода из Enterprise Manager для администраторов, программеров и консультантов у которых на таблицу UserInfo установлены права только на чтение, а на SysConfig никаких прав.
Но с другой стороны, администраторы, программисты и консультанты должны иметь доступ к профайлеру. А это значит, они должны иметь полные администраторские права...

Ограничение прав доступа администраторов - это абсурд. Применительно к администраторам может imho работать только один способ ограничения доступа к информации: криптографическая защита (как, например, это делается при шифровании файлов средствами NTFS). Вспомним хотя бы о том, что кроме настройки параметров БД с помощью профайлера администраторы занимаются еще и созданием резервных копий баз, которые можно потом разрвенуть на совершенно другом сервере с совершенно другими правами доступа.

Цитата:

В общем, тема благодатная. Может кто-нибудь напишет о грамотном разделении прав в 3хуровневой Аксапте?

Если разделение прав доступа нацелено на снижение вероятности и тяжести последствий НСД (несанкционированного доступа), то здесь в первую очередь надо сформулировать модели нарушителей, а уже потом на основании этих моделей думать, как разделять права доступа.

[Михаил Андреев]

Цитата:

Сообщение от 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 нового пользователя не добавить, тестовую базу из боевой быстро не приготовишь, при тестировании под чужим именем не войдёшь.

[gl00mie]

Цитата:

Сообщение от 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 под "левым" пользователем.

[gl00mie]

Цитата:

Сообщение от Михаил Андреев

Это все понятно, что 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

В данном случае предлагается сопоставить логин текущего пользователя и его 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 от "левого" пользователя

[George Nordic]

Цитата:

Сообщение от Михаил Андреев

Меня другое удивило. Оказалось, что реально AX просто "спрашивает" у AD информацию о пользователе только в момент его создания и прописывает в таблицу UserInfo. Далее просто сверяет его данные с записью в БД. И всё.

Не только: еще проверка производится при внесение изменений в параметры.
Один из вариантов - пользоваться виртуальными машинами.

С Уважением,
Георгий

[mazzy]

Цитата:

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

Ограничение прав доступа администраторов - это абсурд

А где я говорил, про ограничение прав администраторов?
Я говорил про ограничение прав к данным. Эта задача актуальна не для администраторов, а для консультантов-программистов.

Должен ли консультант иметь возможность непосредственной правки UserInfo.SID?
Через Аксапту - да, а через EM - нет.
Также он не должен иметь возможность правки через ODBC, ADO и другое.
Только через Аксапту.

[mazzy]

Цитата:

Сообщение от George Nordic

Один из вариантов - пользоваться виртуальными машинами.

George, См исходную тему.

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

Виртуальная машина решит проблему только демобаз.
И вряд ли решит другие проблемы.

[gl00mie]

Цитата:

Сообщение от 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хуровневой Аксапте?

Интересная тема Надо будет подумать, какие роли тут возникают, и какие им надо раздать права...

[mazzy]

ага. виноват. администраторов зря перечислил.

согласен, тема стоит того, чтобы над ней подумать.

[rser]

Может кто сталкивался? Как войти в AX4.0 под разными пользователями одновременно с одного компа. Т.е. в тройке когда я настраивал права доступа я одновременно заходил под админом и тестовым пользователем, под админом делаешь настроику, заходишь под тестовым проверяешь что получилось. Сейчас занялся изучением четверки, не могу понять как реализовать такой механизм. Тестового пользователя в домене завести не проблема, а вот как одновременно под разными именами подключиться не понимаю. Тут писали что можно как то сделать ярлык для запуска, можно по подробнее как?

[MironovI]

run as вас спасет

[rser]

Цитата:

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

run as вас спасет

Спасибо! Решение было перед носом!

[sable102]

Цитата:

Сообщение от 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
У меня тоже не получилось зайти в систему, не авторизует. Машине не в домене, аос в сети.
так есть ли лекарство?