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

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

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

[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

Поэтому "вот так сразу", видимо, отказаться от 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]

Цитата:

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

Это все понятно, что 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 тестовой базы?

Цитата:

при тестировании под чужим именем не войдёшь.

обычно нужно входить не столько под чьим-то именем, сколько с правами той или иной группы. Достаточно создать тестовый логин и изменять его членство в группах пользователей.

[George Nordic]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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