Цитата:
Сообщение от
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, и стараетесь применять принцип минимальных привилегий,
- стараетесь снизить общую стоимость владения системой и, в частности, сложность и стоимость ее администрирования
поэтому вот вам на выбор два решения:
- завести пользователей AD для соотв. внешних пользователей, которым нужен доступ к DAX, в вашем "рабочем" домене, либо
- завести пользователей AD для соотв. внешних пользователей, которым нужен доступ к DAX, в некоем "фиктивном" домене, который будет доверять вашему (иначе нево... очень сложно будет настроить в нем доступ к ресурсам в вашем домене)
если отбросить то, что написано в пункте "понятное дело, что вы", то остается лишь ограничение по предоставлению с одного сервера доступа к ресурсам на другом (их) сервере (ах) в домене. В остальном же можно делать все, что заблагорассудится, - хоть завести обычных доменных пользователей, которые могут лезть, куда заблагорассудится.