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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.08.2008, 23:07   #1  
alex55 is offline
alex55
MCTS
MCBMSS
 
224 / 145 (5) +++++
Регистрация: 13.02.2007
Адрес: Москва
Организация доступа внешних веб-пользователей к DAX 4.0
В статье "Active Directory user topology" (http://msdn.microsoft.com/en-us/libr...43(AX.10).aspx) рассматривается 2 варианта организации доступа внешних веб-пользователей к DAX 4.0 (если я правильно понимаю):

1. "Standard perimeter network" - в отдельную организационную единицу (organizational unit) Active Directory основного домена добавляются пользователи со следующими ограничениями прав: "Cannot log on locally" и "Cannot access the network". Далее эти пользователи добавляются в DAX в качестве внешних пользователей (Администрирование/Пользователи/Пользовательские связи/Разное/Внешние пользователи) и используются для доступа к DAX через Интернет.

2. "Traditional perimeter network" - создается дополнительный домен с односторонним доверительным отношением к основному. В дополнительный домен добавляются пользователи, учетные записи которых будут использоваться внешними веб-пользователями. Они не имеют никаких прав в основном домене, а в дополнительном их права ограничены следующим образом: "Cannot log on locally" и "Cannot access the network". Далее эти пользователи добавляются в DAX в качестве внешних пользователей (Администрирование/Пользователи/Пользовательские связи/Разное/Внешние пользователи) и используются для доступа к DAX через Интернет. При этом на веб-сервере предлагается перекрыть политику "Cannot access network" для открытия доступа к нему.

Хотелось бы задать следующие вопросы тем, кому приходилось реализовывать эти варианты на практике, или тем, кто имеет опыт администрирования Active Directory:

1. В чем вы видите основные достоинства и недостатки каждого из предложенных вариантов?

2. Возможно ли применение других вариантов? Например, заводить не доменные а локальные аккаунты в Enterprise Portal server для внешних пользователей.

Последний раз редактировалось alex55; 18.08.2008 в 11:19.
Старый 07.06.2009, 17:48   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от alex55 Посмотреть сообщение
Хотелось бы задать следующие вопросы тем, кому приходилось реализовывать эти варианты на практике, или тем, кто имеет опыт администрирования Active Directory:
Я, как говорится, "книгу не читал, но осуждаю" в смысле, эти варианты реализовывать не приходилось, но опыт администрирования AD, в т.ч. в доменных лесов, имеется.
Цитата:
Сообщение от alex55 Посмотреть сообщение
1. В чем вы видите основные достоинства и недостатки каждого из предложенных вариантов?
В общем случае, лишний домен - это лишний, извините, геморрой и накладные расходы. На домен AD нужно, по хорошему, минимум два доменных контроллера, чтобы обеспечивать какую-никакую отказоустойчивость. Конечно, есть Windows Small Business Server или, ныне, Windows Essential Business Server, в рамках которого вроде как предлагается положить все яйца в одну корзину и думать, что вы сэкономили денег, но это в определенном смысле заблуждение, потому что, дубль два, на домен AD нужно минимум два доменных контроллера (считайте это выдержкой из инструкции по безопасности, каждая строчка в которых, как известно, написана кровью). Заводить два дополнительных доменных контроллера, да еще держать в этом "фиктивном" домене серевер под EP (что в определенном смысле затрудняет его администрирование), и все ради горстки внешних пользователей - оно кому-то надо? По-моему, куда проще завести и администрировать отдельную OU.
Цитата:
Сообщение от alex55 Посмотреть сообщение
2. Возможно ли применение других вариантов? Например, заводить не доменные а локальные аккаунты в Enterprise Portal server для внешних пользователей.
Использование локальных пользователей, заведеннных на сервере EP (или любом другом сервере в приведенной топологии, кроме контроллеров AD), совершенно неприемлемо по ряду причин:
  • SID'ы доменных пользователей сохраняются неизменными, покуда жив последний доменный контроллер или последняя резервная копия AD или system state доменного контроллера, т.е. сколько бы ни падало доменных контроллеров и не вводилось новых, SID'ы доменных пользователей и групп в отдельно взятом домене будут неизменны (это очевидно, но стоит упоминания для сравнения), равно как и настройки, в т.ч. настройки списков доступа, привязанные к SID'ам доменных пользователей и групп. SID'ы локальных пользователей любого сервера, не являющегося доменным контроллером (а на доменных контроллерах локальные пользователи и группы просто недоступны), уникальны для данного сервера и "живут", пока живет этот конкретный сервер. Если у вас есть кластер серверов, если у вас есть "ферма" серверов, выполняющих схожие роли (например, сервера MOSS), то на каждом из серверов локальные пользователи и группы будут иметь свои уникальные SID'ы, которые вы никак не воспроизведете на другом сервере, кроме как клонированием образа сервера, а иметь в AD компьютеры-клоны - даже с разными netbios-именами - чревато. Соотв., если вам вдруг понадобится использовать два и более сервера с MOSS или переустановить такой сервер с нуля (пусть даже с сохранением netbios-имени и всех настроек, но не за счет использования резервной копии system state или образа загрузочного раздела сервера), то вы получите почти по всем признакам тех же самых локальных пользователей, но с другими SID'ами. А это, в свою очередь, приведет к проблемам при доступе пользователей к базе DAX, поскольку AOS в 4-ке и выше ориентируется на SID пользователя.
  • Вендор вообще рекомендует использовать локальные группы (но никак не локальных пользователей) лишь для разграничения доступа к локальным же ресурсам того или иного сервера в домене. Это, в частности, облегчает кое-какие экзотические операции, вроде "пересаживания" домена из одного доменного дерева в другое или "слияния и поглощения" доменов. Но если сервер должен использоваться для организации доступа пользователей к ресурсам, находящимся на другом сервере (а это, очевидно, так и есть в случае с сервером MOSS/WSS и доступом к DAX через EP на этом сервере), то следует использовать исключительно доменных пользователей и группы.
  • Наконец, маленькая техническая деталь: в общем случае, ни мастер настройки "пограничной" сети (Microsoft Business Solutions Perimeter Network Wizard), ни мастер импорта пользователей AD не смогут создать новых пользователей DAX на базе локальных пользователей отдельно взятого сервера MOSS/WSS.
Собственно, что вообще вендор пишет касаемо организации доступа внешних (по отношению к организации) пользователей к DAX через EP? А пишет он примерно вот что. Для доступа к DAX, начиная с 4-ки, нужны не просто пользователи DAX, но доменные пользователи, к которым уже будут привязаны пользователи DAX, соотв., на каждого внешнего пользователя, которому нужен доступ к вашей DAX, вам придется завести отдельного доменного пользователя в том же домене, в котором работает (ют) AOS(ы), либо в домене, которому доверяет домен, в котором работает (ют) AOS(ы). Понятное дело, что вы
  • заботитесь о безопасности вашей сети, которая во многом полагается на AD, и стараетесь применять принцип минимальных привилегий,
  • стараетесь снизить общую стоимость владения системой и, в частности, сложность и стоимость ее администрирования
поэтому вот вам на выбор два решения:
  1. завести пользователей AD для соотв. внешних пользователей, которым нужен доступ к DAX, в вашем "рабочем" домене, либо
  2. завести пользователей AD для соотв. внешних пользователей, которым нужен доступ к DAX, в некоем "фиктивном" домене, который будет доверять вашему (иначе нево... очень сложно будет настроить в нем доступ к ресурсам в вашем домене)
если отбросить то, что написано в пункте "понятное дело, что вы", то остается лишь ограничение по предоставлению с одного сервера доступа к ресурсам на другом (их) сервере (ах) в домене. В остальном же можно делать все, что заблагорассудится, - хоть завести обычных доменных пользователей, которые могут лезть, куда заблагорассудится.

Последний раз редактировалось gl00mie; 07.06.2009 в 18:24. Причина: typo...
За это сообщение автора поблагодарили: sukhanchik (8), konopello (3), alex55 (1).
Теги
ax4.0, enterprise portal

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Тестирование прав пользователей. DAX 4.0. petergunn DAX: База знаний и проекты 17 15.12.2014 15:15
Права доступа Группы пользователей к таблице ta_and DAX: Администрирование 2 19.01.2009 15:19
Список групп пользователей и уровней доступа для каждой группы Андрей К. DAX: Программирование 4 25.01.2008 08:35
Ограничение доступа пользователей к компаниям aevi82 DAX: Функционал 15 23.08.2007 14:23
Проблемы настройки прав доступа пользователям axot DAX: Администрирование 25 16.05.2002 10:47
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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