» Помогите продумать логическую структуру домена между офисами

vworld

Цитата:

просто развел все в AD по группам и все больше вроде как ничего и не делал, сервер на 2000 стоит, может посоветуете как правильно надо делать?

А чего тебе посоветовать? Если у тебя всё в локалке - распихай по OU для удобства, назначь GPO для ограничения прав... Ограничения на доступ всё равно делаются на уровне NTFS - а там ни OU, ни поддомены не фигурируют. Так что успокойся - всё правильно сделал.

Newbie777

Цитата:

При child доменах и частых командировках из офиса в офис, потребуется для комфортной работы дополнительно устанавливать DC на каждый из child'ов. Вот тут и видно, что child уступает перед OU.

Пардон - не вижу, чем тут OU выигрывает у child. Только что для администрации OU можно взять в филиал менее подкованного человека... А так - количество DC одно и то же, всё можно администрировать со своего места - в чём проблема-то?

Цитата:

не все так просто, No Override и усё, доменные перекрывают политику OU при любых настройках, даже при настройке "Не наследовать"

Здесь вопрос в том, чего мы хотим добиться - если следовать изначальным условиям, то вроде как хотели в каждом офисе вести свою политику. В таком случае смысл заводить на домен политику с "No Override"?

Newbie777
сорри, пал, буду краток - ибоЪ сил нетуть сегодня шутить...
да и Duke Shadow уже меня опередил



Цитата:

о каких проблемах идет речь? в каждом site будет один DC ну два для полного fault tolerance(FT). При child доменах и частых командировках из офиса в офис, потребуется для комфортной работы дополнительно устанавливать DC на каждый из child'ов. Вот тут и видно, что child уступает перед OU.

ответ Duke Shadow
+ tgalina замечает следующее (бедные админы в Калгари! - прим. автора):

Цитата:

Мы не разрешаем профайлу расти больше чем 1.5 мегабайт. Так никакого канала не хватит.

Цитата:

Уточни насчет Security, с "Account Policy" понятно - только на уровне домена, есть еще что-то?

не думаю - иначе бы упомянул, поправьте если ошибаюсь.



Цитата:

несогласен, сдесь нужен пример, где я не смогу разграничить права в OU и смогу в child и наоборот.

пример - попробуй сам взглянуть КАК вводится trust relationship между двумя foreign сайтами: речь идет ТОЛЬКО о (child)доменах, между которыми устанавливается trust. OU тут не причем. И самое важное - это закон под названием KISS: Keep it simple-simple

так... про частые командировки, поясняю что я имел ввиду

пользователь из child1.domain.com разъезжает по всем остальным childx,
т.е. чтобы каждый раз не логиниться по wan линку, ставим в childx DC от child1, теперь тоже самое для пользователя child2 ставить DC child2 в childx и т.д.
с OU количество DC в приведенном примере не будет множиться как кролики.

с трастами опять не понял. трасты нужны... в итоге для раздачи прав, так? тогда накой они мне, если мне хватит возможностей одного домена. Плиз без общих теоретических отступлений. Нужет пример такого типа: дано то-то то-то, надо то-то то-то, в OU фигу, в child пожалуйста.

С этим думаю разберемся, неужели это вcё? Видимо, никно не отважился организовать один домен с тучей OU, делали по типу NT-систем.

Еще к выбору между отдельными доменами и дополнительными DC в сайтах.

Тот, кто имеет права локального администратора на один из DC, при наличии несложных хакерских утилит может делать очень многое со всей Directory - изменять схему, чужие пароли, членство в группах, доставать хэши паролей и проводить brute-force атаку на них. Так что, если вы не доверяете _полностью_ администратору другого сайта, сервер DC придется отдавать в запломбированном корпусе с замком и без пароля администратора.

Профайл в 1.5 Мб - такое может быть с только с mandatory profile. Контролировать размеры профайлов хотя бы у десятка пользователей практически невозможно. Если кому-либо необходимо работать со многих машин, то стоит использовать терминальный доступ.

Newbie777

Цитата:

пользователь из child1.domain.com разъезжает по всем остальным childx,
т.е. чтобы каждый раз не логиниться по wan линку, ставим в childx DC от child1, теперь тоже самое для пользователя child2 ставить DC child2 в childx и т.д.

Ээээ. А ты не перегибаешь? Для одного-двух пользователей ставить дополнительный DC?
Не понятно почему ты так боишься авторизации по wan. Всё равно профиль в случае изменения придётся подтягивать с сервера не из этой подсети => в любом случае грузить wan-линк. Как сделать так, чтобы профиль тянулся с ближайшего сервера - не знаю.

Цитата:

идимо, никно не отважился организовать один домен с тучей OU

Ну с кучей не делал, а вот с двумя-тремя было дело. Пока в OU было 10 компов и 15 пользователей - нормально себя чувствовал. А потом пришлось резко в одно OU добавить ещё чуть меньше 40 компов - резко поплохело. Пришлось DC ставить в той подсети и профили на него перекачивать.

Refugee

Цитата:

Так что, если вы не доверяете _полностью_ администратору другого сайта, сервер DC придется отдавать в запломбированном корпусе с замком и без пароля администратора.

А никто и не спорит. В ситуации с OU - просто делаем "Delegate control..." на нужный объект - и никаких административных прав давать не нужно. Хотя без доверия не обойтись никак - такова специфика.

Недостаток OU перед доменом: как бы я не раздавал права у меня не получится разрешить логиниться выбранным пользователям на DC с возможностью администратора. Имееются ввиду установка программ, старт/стоп сервисов. Только добавление его в группу Domain Admins, в этом случа человек становиться админом не только своего OU, что не есть хорошо.

В случае падения локального DC, локальные админы длолжны иметь возможность поднять его. С отдельным child и правами Domain Admin это выполнимая задача, с OU... сомневаюсь.

Duke Shadow
Ээээ. А ты не перегибаешь? Для одного-двух пользователей ставить дополнительный DC?
к сожалению не перегибаю, минимизация DC - главное преимущество OU перед child domain. А количество блуждающих пользователей потенциально равно 1/2 персонала всех офисов.

Добавлено
стоп. предыдущий пост отменяется. Если вдруг упадет региональный DC, локальные админы будут знать пароль для входа в Directory Restore Mode(это по f8 при загрузке).

Цитата:

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

А также без флоппи- и CD-приводов, с выключенным PXE, паролем на BIOS и т.д.

Newbie777
Кроме администраторов домена есть еще такие группы как "Server Operators" и "Account Operators".

ooptimum, Поясни о чем ты.

Account Operators - будут иметь права создавать объекты computers и users в любом месте домена, это лишнее.

Server Operators - получат права на все DC, поскольку с несколькими OU у нас подразумевается один домен, тогда админы OU включенные в "Server Operators" получат контроль над DC из других сайтов, что не есть хорошо.

Newbie777

Цитата:

Поясни о чем ты.

Что ты имеешь в виду?

Цитата:

... тогда админы OU включенные в "Server Operators" получат контроль над DC из других сайтов, что не есть хорошо.

Можно попробовать урегулировать это настройками безопасности в свойствах сайта (Active Directory Sites and Services), т.е. дать некторым деятелям доступ только на чтение на некоторые сайты. Просто идея...
Хотя сама Microsoft говорит, что
Цитата:

Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups.

Newbie777

Цитата:

к сожалению не перегибаю, минимизация DC - главное преимущество OU перед child domain.

Я имел в виду будет ли оправдано поднятие DC-офис1 в офис2, если туда наезжают всего один-два пользователя из офис1? Может проще резервирование каналов связи провести?

Цитата:

В случае падения локального DC, локальные админы длолжны иметь возможность поднять его. С отдельным child и правами Domain Admin это выполнимая задача, с OU... сомневаюсь.

А если дать им только локальных админов или "Server Operators"?

Цитата:

получат права на все DC, поскольку с несколькими OU у нас подразумевается один домен, тогда админы OU включенные в "Server Operators" получат контроль над DC из других сайтов, что не есть хорошо.

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

ooptimum
Можно вопрос оффтопом: Как сделать так, чтобы профиль тянулся с ближайшего сервера? Т.е. домен разбит на несколько сайтов, в каждом по DC, пользователь разъезжает по этим сайтам и утягивает профиль с ближайшего к нему DC. Ну и там репликацию какую-нибудь настроить, чтобы профиль между DC тоже копировался.

Я имел в виду будет ли оправдано поднятие DC-офис1 в офис2, если туда наезжают всего один-два пользователя из офис1? Может проще резервирование каналов связи провести?
полностью согласен насчет "один-два пользователя", каналы резервировать - гуд. на самом деле при количестве объектов <10000 на репликацию хватает и 14400bps.

А если дать им только локальных админов или "Server Operators"?
...
В политиках запретить локальный и сетевой вход на другие DC. Долго и муторно, конечно
как не крути местные админы должны иметь право LogonLocaly. т.е. включить в ServOp+потом настройка прав на каждом сервере по времени равна просто настройке политики разрешения прав логинится локально(изначально админы в OU не имеют имеют таких). Child доменам плюс, OU минус.

Я тут пришел к такому сравнению.
Домен это своего рода OU с предустановлеными правами и группами. Почти всё, что реализовано заранне в домене можно реализовать в OU, но потребуется много дополнительных телодвижений.
Вывод: (мой) при наличии местных админов с правами делать с метстыми серверами и их настройками почти все - нужен домен иначе можно обойтись OU.

Duke Shadow

Цитата:

Как сделать так, чтобы профиль тянулся с ближайшего сервера?

А не знаю я -- никогда такой задачи не стояло. За доверие спасибо, конечно. Тут у нас есть как минимум один сертифицированный инструктор Microsoft -- kibkalo, ты ему лучше этот вопрос задай. Я подумаю тем временем.

зы. А он точно с удаленного тянется?

Newbie777

Цитата:

... тогда админы OU включенные в "Server Operators" получат контроль над DC из других сайтов, что не есть хорошо.

ooptimum

Цитата:

Можно попробовать урегулировать это настройками безопасности в свойствах сайта (Active Directory Sites and Services), т.е. дать некторым деятелям доступ только на чтение на некоторые сайты. Просто идея...

хм... это я пропустил, надо посмотреть

ooptimum

Цитата:

зы. А он точно с удаленного тянется?

Ну вообще-то в профиле указывается путь в UNC формате и подразумевает под собой \\server\share. Хотя на 100% не уверен - раньше никогда не занимался, а сейчас встала проблема расширения в одной сети - так там бы поднять DC, копирнуть на него профили и пусть дальше сам решает - было бы шоколадом, благо каналы пухлые.

Цитата:

Тут у нас есть как минимум один сертифицированный инструктор Microsoft -- kibkalo

И то верно. ПоПМю-ка я его

Newbie777

Цитата:

Я имел в виду будет ли оправдано поднятие DC-офис1 в офис2, если туда наезжают всего один-два пользователя из офис1? Может проще резервирование каналов связи провести?
полностью согласен насчет "один-два пользователя", каналы резервировать - гуд. на самом деле при количестве объектов <10000 на репликацию хватает и 14400bps.

Именно. И еще - исходя из реалий и стоимостных показателей подобных внедрений для 1-2 пользователей: примерно 2-3 года тому назад склонился к мысли, что дешевле будет просто устанавливать VPN линки к таким SOHO locations (SOHO - Small Office / Home Office, т.е. до 10 юзеров). это оказалось намного проще/практичнее, чем OU/Child! (Почему 2-3 года назад - потому что инет стал стоить значительно дешевле, а так же появились достаточно широкие каналы за меньшую стоимость (по-сравнению с T1, E1 и т.д.))

К примеру, я логически поделил domain.com на child-объекты (Калгари, просьба, дальше не читать! не, ну я вправду просто шутю!), получилось что-то сходное с child1.domain.com, childN.domain.com и тд. (а именно, взял ISO-коды стран, и начал фигачить child-объекты для каждой страны свой: us.domain.com, ca.domain.com, gb.domain.com, uk.domain.com и тд).

Почти в каждой стране наблюдалась ситуация с присутствием одного крупного офиса и нескольких небольших и/или mobile users групп (около 3-5-10 человек максимум). Т.е. нет смысла городить огород - ставится 2 DC в крупный офис (как child), а всем остальным (региональным офисам данной страны) были высланы pre-configured файерволы для работы по VPN туннелю с этим child-доменом (Branch Office VPN) и с одновременной поддержкой mobile users (они теперь еще могут работать и из дома!). Как видно из этой модели - убиваются зайцы всем косяком, прям один за одним

К тому же, в момент слияния регионального child-домена с какой-либо другой местной компанией, у меня не возникает НИКАКОЙ головной боли - все решается локально в той стране, в которой они 'мусолят' мой бедный child (лишь изредка время от времени запрашивая Administrator пароль - к сожалению есть еще мелкие недоделки, в частности это связано со спецификой (пере)установки Exchange 2000).

Из региональных главных офисов решаются и вопросы бакапов, как почты, так и user-файлов. А также antivirus апдейты (в момент, когда только user логинится из дома или через Branch).

kibkalo ответил. Цитирую ответ:
На 2003 виндах поднимаешь DFS и размазываешь корень по контроллерам.
В 2003 при обращении к DFS выбирается сервер из твоего сайта.

Duke Shadow

Цитата:

На 2003 виндах поднимаешь DFS и размазываешь корень по контроллерам.
В 2003 при обращении к DFS выбирается сервер из твоего сайта.

Именно это я и имел в виду, спрашивая:

Цитата:

А он точно с удаленного тянется?

Т.е. я подразумевал, что профили находятся на DFS, отреплицированном во все OU, раз уж тут такой разговор шел про репликацию. Ты же сам спрашивал как сделать так, чтобы профили тянулись с локального сервера. Вот я полагал, что профили уже находятся на этом локальном сервере. DFS -- единственный знакомый мне способ добиться этого без лишней головной боли. Если ты еще не сделал этого, самое время начинать.

Duke Shadow
Можно вопрос оффтопом: Как сделать так, чтобы профиль тянулся с ближайшего сервера? Т.е. домен разбит на несколько сайтов, в каждом по DC, пользователь разъезжает по этим сайтам и утягивает профиль с ближайшего к нему DC. Ну и там репликацию какую-нибудь настроить, чтобы профиль между DC тоже копировался.
А если так.
Профиль перенаправить таким образом \\domain.com\sysvol\%username%
при таком раскладе domain.com разбирается в ближайший DС, репликация между DC пройдет по расписанию сайта

ooptimum

Цитата:

Т.е. я подразумевал, что профили находятся на DFS, отреплицированном во все OU, раз уж тут такой разговор шел про репликацию.

Не DFS у меня пока нету. Пока всё валяется на отдельном файл-сервере.

Цитата:

Вот я полагал, что профили уже находятся на этом локальном сервере.

Полагал-то ты правильно - по условию задачи я и хотел копирнуть их туда. Только не сказал, что DFS не хочу поднимать - согласен, мой косяк .

Newbie777

Цитата:

Профиль перенаправить таким образом \\domain.com\sysvol\%username%

Хм, может быть. Вот только в sysvol не охота лезть, тем более на системном разделе я стараюсь держать минимум - даже системный софт крайне осторожно на него леплю. А профили так вообще сгружаю на отдельный файл-сервер. Если только организовать софт-линк в sysvol'е. Хорошо, спасибо за идею - попробую обязательно.

Newbie777
Вопрос - а эти твои "командировочные" юзеры ездят со своими ноутбуками или в каждом офисе им дают место за компом ? Для них так необходимо работать именно со своими профилями ?

Добавлено
У меня такая ситуация:
Одно предприятие, главный офис, 8 удаленных офисов (из них 4 находятся рядом, а 4 на расстоянии 200 км от центрального). Между центральным офисом и подразделениями - каналы связи от 1 до 2 мбит.

Кол-во юзеров:
Центральный офис - 200
Подразделения - примерно по 50 в каждом.

Сейчас в центральном офисе, подразделениях 1,2,3 один домен dom.ru, а в других соответсвенно p1.dom.ru, ... p5.dom.ru.

Столкнулись с тем, что в сетевом окружении уже достаточно компьютеров и их поиск усложняется. Стали думать, стоит ли подразделения 1,2,3 тоже выделять в отдельные домены ? Или может наоборот подразделения 4-8 влить в общий домен ? Проблем с количеством серверов нет, в каждом подразделении стоит минимум 2 сервака.

Что подскажите ?

zzzolegzzz

Цитата:

Столкнулись с тем, что в сетевом окружении уже достаточно компьютеров и их поиск усложняется.

Кхм, странно. Теоретически никаких проблем с поиском компов у тебя быть не должно, т.к. функции Master Browser'а выполняет контроллер домена. Соответственно при выполнении поиска компьютер-клиент должен просто обратиться к сервису Network Browser, а тот ему отдаст инфу.

Вообще по твоей проблеме кроме банального "если всё работает - ничего не трогайте" в голову не приходит.

Если тебя интересует только решение проблемы медленного поиска - попробуй организовать поиск только в Active Directory. Через вызов rundll32 dsquery делается. Только вот имя функции призабыл.

Duke Shadow

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

Вопрос в том, что мы сейчас находимся на распутье - половина подразделений сидит в отдельных доменах, половина - в одном. Надо что-то одно - но что ? Вот в чем вопрос ?

Для меня вопрос нескольких доменов - это вопрос порядка (ну там все по полочкам разложено типа). Но интересно - что посоветует умный люд ?

И еще - какие требования по безопасности могут стать основанием для деления сети на отдельные домены ? Конкретнее !

zzzolegzzz
конкретнее - посоветую почитать этот трэд с самого начала, все разложено по полочкам - остается только тебе самому решить как поступить, применительно к твоему окружению, правильно расставив приоритеты.

ку?

euserz
Да читал, с самого начала. Только ситуации разные немного. Одно дело - магазинная сеть, другое дело - большое предприятие.

И кстати насчет
Цитата:

И еще - какие требования по безопасности могут стать основанием для деления сети на отдельные домены ? Конкретнее !

так толком ничего и не сказали ...

И еще интересно, что-же скажет kibkalo. А то хотели спросить его про деление сети на домены, а он ответил про DFS.

zzzolegzzz

Цитата:

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

Ну извини. В данном случае ничего толкового предложить не могу. Переучивай пользователей пользоваться созданным тобой ярлычком следующего содержания

Код:
rundll32.exe dsquery,OpenQueryWindow

тот самый witepaper на тему домен или OU!!!
Design Considerations for Delegation of Administration in Active Directory

This guide includes a step-by-step methodology that describes how to select the appropriate directory structure (forest, domain, or OU) for a delegation based on organizational requirements and security considerations.

All
Хочу воразить свою благодарность всем откликнувшимся !!!
Спасибо за разъяснения.

Хочу подвести итоги, что планируется сделать:
Сейчас предстоит следующее:
Объединить (ПОКА) два офиса Офис1 и Главный офис, т.к. пока канал (2Мб) брошен только между этими двумя точками. Причем оба офиса должны быть в одном доменном пространстве имен xxx.local и все будет раскидано по OU.

Что имеем сейчас:
Главный офис: 2 DC, оба на 2000, DNS, DHCP, MsSQL2000, домен yyy.local, 192.168.0.x
Офис1: 2 DC, оба на 2003, DNS, DHCP, домен xxx.local, 192.168.100.x

Т.е. как видно в Главном офисе нужно будет поднимать домен с другим именем, т.к. я интересовался (может плохо интересовался) и не нашел простого решения переименования домена, то было решено переустановить вообще сервер с 2000 на 2003 (думаю, создавать новую структуру, так уж полностью на одной системе, логично?) и поднять домен xxx.local на вновь установленном сервере, причем имя нового домена будет такое же как у домена в Офис1, в этом еще одна проблема.

Теперь хочу изложить список проблем с которым мне придется столкнуться и которые придется решать, поэтому прошу совета в их решении:
1) Нужно перенести всех пользователей/компы/группы со старого домена yyy.local на новый xxx.local и затем туда же влить еще пользователей из моего старого домена xxx.local, который находиться в Офис1.
Возможно пароли не удастся передать, но хотя бы без них ?
Какие методы решения этой задачи посоветуете ?
2) Можно ли еще перетянуть групповые политики со старого домена yyy.local на новый xxx.local ?
Или все заново ?
3) Я так понимаю, мне не удастся поднять домен xxx.local, т.к. в сети уже есть такой ?
Как выход можно ли поднять этот домен на компе выключенном из сети, загрузить туда базу пользователей (все что в первом пункте), пробить пароли (если потребуется) и когда все будет готово включить в сеть, а остальные DC в обоих офисах понизить до рядовых ?
Ну и потом уже в Офис1 поднять контроллер домена для нового xxx.local.
4) В Главном офисе на одном из DC стоит сервер SQL 2000, так вот при поднятии W2003 не возникнет ли проблем с установкой SQL2000 на нем ?

Цитата:

1.создается один домен. Создаются Office1 OU … OfficeN OU
недостатки: невозможность задавать свои Account Policies в филиалах

В 2003 ситуация таже или меняется в лучшую сторону ?

pazdak

Цитата:

1) Нужно перенести всех пользователей/компы/группы со старого домена yyy.local на новый xxx.local

Active Directory Migration Tool (aka ADMT) должен помочь. Только пароли он, кажется нифига не сохраняет.

Цитата:

3) Я так понимаю, мне не удастся поднять домен xxx.local, т.к. в сети уже есть такой ?

Заново - не удастся. Просто поднимай сервер как ещё один DC в xxx.local. После этого жди или запускай вручную репликацию - по завершении получишь всех пользователей. После этого можешь вывести из домена контроллеры вОфис1, переставить их на Win2003 и подключив к домену провести репликацию - получишь сеть полностью на Win2003.

Цитата:

4) В Главном офисе на одном из DC стоит сервер SQL 2000, так вот при поднятии W2003 не возникнет ли проблем с установкой SQL2000 на нем ?

Возникнут. Windows 2003 поддерживает только SQL 2000 SP3 (более ранние просто не запускаются) - так что позаботься заранее.
По поводу п.2 ничего сказать не могу.

Добавлено
А вот и тема MS SQL 2000 и Windows 2003

Duke Shadow
Спасибо за совет.

1)
Цитата:

Active Directory Migration Tool (aka ADMT) должен помочь. Только пароли он, кажется нифига не сохраняет.

В последней версии ADMT v2 реализована миграция паролей учетных записей пользователей. Это радует.
Попробую разобраться с этой штучкой.

Вопросик к Вам, кто-нибудь пользовался такой програмкой Ideal Migration 3 от PointDev ? Для этих целей она подойдет ?

3)
Цитата:

Заново - не удастся. Просто поднимай сервер как ещё один DC в xxx.local. После этого жди или запускай вручную репликацию - по завершении получишь всех пользователей. После этого можешь вывести из домена контроллеры вОфис1, переставить их на Win2003 и подключив к домену провести репликацию - получишь сеть полностью на Win2003.

Значит мои действия:
3.1) Устанавливаю W2003
3.2) Включаю в домен xxx.local и поднимаю на нем AD
3.3) Вот насчет ручной репликации можно подробнее, как она делается ? Извиняюсь за тупой вопрос...
3.4) Из старых DC на xxx.local, нужен только один, он уже на W2003, тут значит только хозяев операций нужно передать или лучше все же понизить до member server, а потом поднять опять до DC ?
3.5) Далее пользуюсь утилитой ADMT v2 или подобной для переноса инфы из домена yyy.local в xxx.local
3.6) После этого нужно прогонять какой-нибудь тест в домене, так для проверке ?
3.7) Избавляюсь от домена ууу.local

Может забыл, что ?

4) За ответ спасибо, правда я не совсем понял, что нужно sp внедрять в SQL или последовательно ставить SQL, а потом накатывать sp3, но попробуем...