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

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

Цитата:

Сообщение от 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 тестовой базы?

Цитата:

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

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