Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

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

Автор: pazdak
Дата сообщения: 23.03.2004 15:23
Встает вопрос объединения 4 офисов в единую сеть, т.е. будет следующая схема:
Офис1, Офис2, Офис3 будут соединены каждый каналом в 2 Миб с Главным офисом, т.е. образуя какбы своеобразную звезду. (причем трафик по этому каналу не имеет значения)
В свою очередь Главный офис будет иметь выход в Инет 512К, для всех офисов.
Парк машин примерно одинаковый около 90-100 машин, в каждом офисе.

Сейчас в каждом офисе поднят свой домен на Win2003 (где-то на 2000), и нужно продумать как правильней будет организовать структуру нового домена для всех офисов ?

Думаю в Главном офисе поднять домен xxx.local, а в остальных трех офисах поддомены office(I).xxx.local.

Раньше не приходилось объединять несколько офисов одну сеть, т.е. чтобы Офис1 мог общать с Офис2 свободно, но это правда не такое уж частое событие, но необходимое !!! Поэтому и прошу Вашей помощи в выборе конфигурации БУДУЮЩЕЙ сети.

Есть еще решение с так называемыми Сайтами и Подсетями, с этим так же не работал, поэтому если кто сможет подсказать, буду ОЧЕНЬ благодарен. Т.е. хочется узнать можно ли применить такое решение, поднять в Главном офисе домен xxx.local, а в Офис1-3 поставить Контроллеры домена xxx.local и настроить Сайты ?
Читал что репликация между сайтами настраивается как тебе нужно, правда пока не вникал в этот вопрос...

Хочу узнать мнение профессионалов в данном вопросе, как правильно мне организовать логическую структуру сетки ?

Заранее спасибо
Автор: trisen
Дата сообщения: 24.03.2004 14:28
желательно проапгрэйдить все будующие DC до 2003

вариант 1.
в головном офисе создаешь forest company.com
филиалы добавляшь в этот форест как child office1.company.com
office2.company.com

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


вариант 2.
в головном офисе создаешь forest company.com
в филиалах создаешь forest-ы child office1.company.com
office2.company.com

далее настраиваешь транзитивные трасты между форестами и усе
все летает
минусы, не будет плюсов 1-го варианта


бтв я не спец в этих вопросах так, что лучше почитать маны от мелкософта







Автор: Duke Shadow
Дата сообщения: 24.03.2004 15:07
pazdak

Цитата:
БУДУЮЩЕЙ

Ну раз так крупно, то может будущей?

Цитата:
Т.е. хочется узнать можно ли применить такое решение, поднять в Главном офисе домен xxx.local, а в Офис1-3 поставить Контроллеры домена xxx.local

Можно. В чём-то даже проще, чем вариант с поддоменами - раскидаешь всё по подразделениям(OU) и будешь жить спокойно. Только, имхо, репликация тебя победит .
Наверное правильнее будет всё же организовать поддомены - сами МС-овцы в своих книжках рекомендуют такие схемы.

Цитата:
Есть еще решение с так называемыми Сайтами и Подсетями

Т.н. сайты и подсети никак не зависят от доменов. Как сказано в официальных руководствах МС (цитирую не дословно): "Один сайт может содержать контроллеры разных доменов, а в один домен входить несколько сайтов". Сайт - это объединение ресурсов по физическим границам.

Цитата:
Читал что репликация между сайтами настраивается как тебе нужно

Совершенно верно. В то время, как внутри одного сайта все соединения считаются достаточно скоростными, и первая попытка репликации данных организуется, кажется, через 5 минут после внесения изменений.

С твоими проблемами рекомендуют обращаться сюда.
Автор: pazdak
Дата сообщения: 25.03.2004 08:29

Цитата:
Можно. В чём-то даже проще, чем вариант с поддоменами - раскидаешь всё по подразделениям(OU) и будешь жить спокойно. Только, имхо, репликация тебя победит

А если все раскидать по OU=Офис(I) и настроить Сайты, тут можно выкрутиться или нет ???


Цитата:
С твоими проблемами рекомендуют обращаться сюда.

Это я уже читаю...

На самом деле я придерживался такой конфигурации сети:
В Главном офисе поднимаю домен xxx.local, а в остальных Офис(I) поднимаю child, так я хотел, но есть еще один перец который хочет чтобы все офисы были в одном домене xxx.local, поэтому меня и интерисует отличная от этой конфигурации работа сети...
Автор: trisen
Дата сообщения: 26.03.2004 07:40

пардон за глупый вопрос, а зачем этот перец так хочет сделать? какие на это причины?

Автор: pazdak
Дата сообщения: 26.03.2004 14:47
trisen

Цитата:
пардон за глупый вопрос, а зачем этот перец так хочет сделать? какие на это причины?

Самое интересное, что у меня возник такой же вопрос, но перец этот вообще никакого отношения не имеет к отделу IT, он просто большой начальник и хранитель денег, поэтому и приходиться доказывать, что ты не верблюд.
Автор: Duke Shadow
Дата сообщения: 27.03.2004 13:33
pazdak

Цитата:
А если все раскидать по OU=Офис(I) и настроить Сайты, тут можно выкрутиться или нет ???

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

Цитата:
он просто большой начальник и хранитель денег, поэтому и приходиться доказывать, что ты не верблюд.

Вот это вот самый большой 3.14зDOS современных российских реалий. Сочувствую Сам также порой...
Автор: tgalina
Дата сообщения: 27.03.2004 19:29
Глядя на приведенные вами факты, я не вижу никаких реальных причин для вас иметь более одного домена. Вам надо установить domain root в главном оффисе, при такой хорошей связи с другими оффисами вам даже не очень то надо внедрять сайты, можно все поместить в один сайт. Но если вы очень хотите (и судя по тому, что в каждом оффисе уже есть какой-то там свой домен, то есть есть хотя бы один домен контроллер, то есть вам не надо покупать дополнительные серверы, можно использовать то, что уже есть), можете пойти по пути "один домен, четыре сабнета = четыре сайта". При этом, можно организовать DHCP из головного оффиса, добавив соответствующие IP forwarders на каждом роутере в других оффисах. Не верьте тем, кто вас пугает репликацией - на 2003 она работает очень хорошо и экономично, и в вашем случае проблем быть не должно. Прошлой весной мы внедрили 2000 домен для клиента, у него было 11 оффисов кроме головного, мы построили один домен, все домен контроллеры в головном оффисе, и все работает как часы. Кстати, связь с удаленными оффисами хорошая, но не супер, managed DSL 1,5. Другой наш клиент имеет 320 удаленных оффисов (магазинов), и тоже живет прекрасно с одним доменом, все домен контроллеры в головном оффисе. Некоторые из удаленных оффисов сидят на 56 к Frame Relay, и успешно логинятся в головной оффис (правда, мы используем Citrix).

Добавлено
Вот вам мой вариант дизайна вашей сети.

Головной оффис

Домен mydomain.lan
Подсеть 10.100.50.x
Сайт Head Office
Два домен контроллера для всех Operations Master ролей
DNS, DHCP службы
DHCP scopes:
10.100.50.x (10.100.50.50-250), mask 255.255.255.0, gateway 10.100.50.1
10.100.1.x (10.100.1.50-250), mask 255.255.255.0, gateway 10.100.1.1
10.100.2.x (10.100.2.50-250), mask 255.255.255.0, gateway 10.100.2.1
10.100.3.x (10.100.3.50-250), mask 255.255.255.0, gateway 10.100.3.1
10.100.4.x (10.100.4.50-250), mask 255.255.255.0, gateway 10.100.4.1
DHCP forwarders для оффисов:

Оффис 1
Домен mydomain.lan
Подсеть 10.100.1.x
Сайт Office1
Один домен контроллер (репликацию вам не надо никак конфигурировать, оставьте все в покое, репликация вполне справится с самонастройкой для такого простого случая как у вас)

Оффис 2
Домен mydomain.lan
Подсеть 10.100.2.x
Сайт Office2
Один домен контроллер

Оффис 3
Домен mydomain.lan
Подсеть 10.100.3.x
Сайт Office3
Один домен контроллер

Оффис 4
Домен mydomain.lan
Подсеть 10.100.4.x
Сайт Office4
Один домен контроллер

Что касается OU, то они нужны только тогда, когда вы знаете, что вы с ними будете делать. Я бы для начала создала один OU в корне mydomain.lan - companyname, от него создала еще один OU - users - и поместила всех юзеров туда. Потом у вас будет время подумать, какие OU вам действительно нужны, создать их и по необходимости переместить туда юзеров.

Успехов

Галина
Автор: euserz
Дата сообщения: 30.03.2004 22:16
я, конечно, tgalina, извиняюсь, но MS и профессиональные консультанты не рекомендуют так делать, как Вы предложили.

Я прекрасно понимаю, что это осуществимо, но из-за соображений security, reliability и data/traffic/user redundancy, а так же самой сути для чего придуманы Active Directory и child объекты, “размазывать” один-единственный xxx.local домен [категорически] не следует (ну, разве что только они все друг от друга находятся в пределах прямой видимости и/или велосипедной досягаемости да и то… кхе-кхЫ…).

Как сказал trisen в самом начале: Вариант 1, и Вариант 2 (либо смешанный вариант) – и только так, не надо ничего больше придумывать, очень прошу не усложнять свою Life и Network Topology

pazdak
А “перцу” тому я б объяснил, что кроме желаемой действительности есть еще и абстрагированная реальность, с технической точки зрения которой выходит, что надо с ней считаться в первую очередь
Автор: trisen
Дата сообщения: 31.03.2004 04:25
вариант который предложила tgalina приемлем в том случает
если есть куча мелки х офисов, в которы находится небольшое кол-во рабочих мест.

у меня по городу порядка 40 точек в котрых работает 2-5 человек, для этих точек у меня стоит отдельный DC, который в свою очередь явлется child-ом фореста.

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

Автор: tgalina
Дата сообщения: 31.03.2004 07:00
Дорогие Tristen и usersz! Мои рекомендации, как странно они бы для вас не звучали, проверены на практике. Наиболее яркое подтверждение моей точки зрения - недавняя Calgary Regional Health Authority имплементация, четыре госпиталя, 25 тысяч пользователей, один домен. Еще одна фирма - IPF - 250 пользователей, из них 110 в головном оффисе, остальные в 8 удаленных оффисах, один домен, 9 сайтов, все домен контроллеры в головном оффисе, все работает отлично (иначе нам бы не заплатили, мы контракторы и нам платят по результатам Set-Met, а не просто так из чувства солидарности). О какой такой "усложненной топологии" вы говорите в ситуации с пятью сайтами?
Автор: trisen
Дата сообщения: 31.03.2004 08:32
дорогая tgalina
вот вам задача тогда

головной офис 300 юзеров
3 удаленных офиса 30-40 юзеров

полоса пропускания между головным офисом и удаленным pir 128k cir 64k, далее канал ПД

в канале ПД должно ходить:

Internet
VoIP (2 линии)
Mail
доступ к сетевым ресурсам которые расположены на DC
нуи всякая мелочь пузатая пита ssh и т.д

PS
подключение к интеренет есть только в головном офисе

PS
все на самом деле зависит от тех условий нет одного решения на все задачи.
2 Мбт, про которые писал pazdak я думаю достаточно для вашего решения

вот только, чтоб будет если рухнет канал между HQ и Branch ?????
имхо, в вашем случае работа будет полностью парализована, а в моем решении покрайней мере можно будет работать с ресурасми DC в Branch.





Автор: ooptimum
Дата сообщения: 31.03.2004 11:39
trisen
tgalina все правильно говорит. Разбиваешь сеть на сайты, ставишь в branch-офис дополнительный DC из того же домена, что и HQ, и указываешь частоту и время синхронизации такое, какое удобно тебе, например только ночью (в свойствах Site Link'а). В остальных случаях синхронизируешь вручную по мере надобности. Все клиенты из branch должны использовать локальный DC в качестве основного. DHCP-сервер в branch-офисе свой, со своим собственным scope. Никакие падения канала между HQ и branch-офисом не приведут к потере работоспособности сети ни там, ни там.
Автор: trisen
Дата сообщения: 31.03.2004 12:09
ooptimum
понятно, я не понял что такое "один домен контроллер"
только щас дошло, что они физически будут стоять в каждом офисе.

пардон





Автор: Duke Shadow
Дата сообщения: 31.03.2004 14:22
ooptimum

Цитата:
ставишь в branch-офис дополнительный DC из того же домена, что и HQ

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

Цитата:
Никакие падения канала между HQ и branch-офисом не приведут к потере работоспособности сети ни там, ни там.

Опять же зависит от того как трактовать предыдущую фразу. Если всё же все контроллеры в HQ - то работоспособность при упавшем канале напрямую зависит от параметра политики "Количество подключений к кэшу" или что-то в этом духе.

tgalina

Цитата:
Кстати, связь с удаленными оффисами хорошая, но не супер, managed DSL 1,5

Пардон, а пользователи авторизации по полчаса ждут? У меня, например, утречком приходят 20 пользователей - у каждого только профиль не меньше 10 метров - так тот 10 мегабитный сегмент на некоторое время, можно сказать, уходит в даун. Конечно есть вариант инкрементальной передачи - когда пользователь постоянно за одни компом работает - у меня, к сожалению, не реализуем по некоторым независящим от меня причинам.

Цитата:
Некоторые из удаленных оффисов сидят на 56 к Frame Relay, и успешно логинятся в головной оффис (правда, мы используем Citrix).

А вы не путаете компот и котлеты? Терминальные решения - это немножко из другой области. Может быть Вы нам про терминалы всё время говорили - а мы с Вами о другом?

pazdak
Как и обещал полистал книженции МС. Правда уложился только к сегодняшнему дню . Ничего толкового прямо не написано (по книжкам получается, что проблема "общее пространство имен или отдельное" - гораздо важнее проектирования структуры домена). По достаточно туманному тексту и иллюстрациям выходит всё же, что при наличии медленных соединений (Что считать медленным в терминологии МС кто-нибудь знает??? Конкретных цифр просто нет) между офисами/подразделениями компании лучше заводить поддомены со своими контроллерами в офисах и разводить всё по сайтам.
Автор: ooptimum
Дата сообщения: 31.03.2004 15:30
Duke Shadow

Цитата:
tgalina означает совершенно противоположное

Согласен. Тогда делать, как я говорю.



Добавлено
Хотя, в общем-то, говоря о том, что она все правильно говорит, я имел в виду данный ее тезис:

Цитата:
Глядя на приведенные вами факты, я не вижу никаких реальных причин для вас иметь более одного домена.

Автор: euserz
Дата сообщения: 31.03.2004 20:42
tgalina
еще раз повторюсь: так как вы в Калгари имлиментируете - печально, ибоЪ.

тут могу лишь пожалеть ваших клиентов, которых так кидают на технологии, или же предположу, что всё было немного не так (или совсем не ), ибоЪ

ooptimum и Duke Shadow дело говорите! Есть предложение: Давайте сначала вас выберем, а потом пошлем в Калгари на разбор завалов?

просьба не обижацца - шутки у меня такие... сам из-за этого комплексую...
Автор: Duke Shadow
Дата сообщения: 01.04.2004 12:19
ooptimum

Цитата:
Тогда делать, как я говорю.

Из политработников будете?

euserz

Цитата:
ибоЪ

Присоединяюсь. К обоим случаям.

Цитата:
Давайте сначала вас выберем, а потом пошлем в Калгари на разбор завалов?

Да ну... Там весь софт лицензионный надо покупать и всё такое... Хотя при их зарплатах... Ладно - согласный!
Автор: ooptimum
Дата сообщения: 01.04.2004 13:13
Duke Shadow

Цитата:
Из политработников будете?

Вообще-то нет -- из начальников...

Добавлено
Типа того перца, который хочет один домен везде. Только в отличие от того перца я еще знаю как это желание воплотить в жизнь технически.
Автор: tgalina
Дата сообщения: 03.04.2004 18:16
Duke Shadow:

ситуация, когда юзер профайл имеет размер 10 мегабайт - не реальность, на которую надо ориентироваться, а реальность, с которой надо бороться, на мой взгляд. Мы не разрешаем профайлу расти больше чем 1.5 мегабайт. Так никакого канала не хватит.
В Калгари на разбор завалов посылать никого не надо - завалов нет.
"А вы не путаете компот и котлеты? Терминальные решения - это немножко из другой области" - да, я кажется неточно обьяснила ситуацию. Мы используем Citrix параллельно с обычным логином для пользователей лаптопов, и через тот-же канал идет траффик кассовых аппаратов (удаленные оффисы - это магазины). К сожалению, у этого конкретного клиента стоит 2000 домен, а не 2003, где наконец вводится Link Value Replication и Partial Attirbute set replication. Но даже если бы они были на 2003, нам бы в голову не пришло закупить 312 домен контроллеров и поставить их в подсобке каждого магазина, так как специального помещения для серверов у них нет. У другого клиента, о котором я говорила что их линк 1,5 Managed DSL, пользователи авторизации по полчаса не ждут, потому что мы не даем их профайлам расти бесконтрольно.

Я всего лишь хотела сказать, что в зависимости от того, какой траффик кроме user-generated и domain services generated идет через каналы между головным оффисом и удаленными, можно или все домен контроллеры (по идее, не больше двух будет нужно) сосредоточить в головном оффисе, или в каждом удаленном оффисе создать сайт и тогда каждый сайт тоже будет нуждаться в домен контроллере. Моя идея заключается в том, что по MS доменная структура планируется чтобы решить задачи security, а сайты решают задачи репликации. Поэтому мне идея для каждого удаленного сайта создавать child domain кажется скорее следствием того, что подающий эту идею имеет большой опыт администрирования NT и не совсем знаком с 2000.

trisen:
"вот только, чтоб будет если рухнет канал между HQ и Branch ?????
имхо, в вашем случае работа будет полностью парализована, а в моем решении покрайней мере можно будет работать с ресурасми DC в Branch. "

Я с вами согласна, но давайте определим, что вы имеете в виду под "можно будет работать с ресурасми DC в Branch". Кроме авторизации, есть еще немало других проблем, о которых придется подумать. Где вы хотите хранить данные? В головном оффисе или в каждом удаленном оффисе тоже? Если по правилам вашей компании данные могут только храниться на сервере в специально оборудованной secure server room, а она существует только в головном оффисе, то в случае падения канала авторизация будет вашей самой маленькой проблемой. Что насчет почты? Она все равно идет через Internet feed, находящийся в головном оффисе - то есть при падении канала почты не будет тоже. Конечно же я не могу посоветовать идеальное решение, не зная ваш бизнес, ваши правила и приемы работы пользователей. Именно поэтому прежде чем порекомендовать решение, мы тратим много времени изучая то, как работает бизнес. Например, у компании может существовать Business Recovery Procedure, в которой написано, что никакие данные не будут храниться на серверах, которые физически не под замком, и не IT персонал не будет касаться бэкап медиа - то есть нет вариантов, все данные могут только храниться в головном оффисе, проще заплатить за улучшение связи с удаленными оффисами, чем быть в следующем году вздрюченными аудитором. Особенно если компания publicly traded, часто их внутренние правила диктуют технологию, а не наоборот.

euserz:

"могу лишь пожалеть ваших клиентов, которых так кидают на технологии" - фраза типа "этого не может быть, потому что этого не может быть никогда". Я сказала, что решение было создано, stress-tested, внедрено, оценено пользователями, показатели эффективности решения замерены и предоставлены клиенту, который признал что решение работает эффективно и уплатил за это деньги. Практика - критерий истины, не правда ли? "Кидают на технологии" - это когда обещают, что будет работать так-то и так-то, а в итоге это не выполнено. Можно спорить о том, как бы это сделали вы, и чье решение лучше, но я лично опасаюсь людей, которые точно знают, как надо, не будучи знакомыми даже поверхностно с обстоятельствами дела. Я думаю, что если бы мы с вами встретились лично и обсудили решения (что, очевидно, невозможно в силу географических обстотельств), которые я упомянула, недоразумения бы рассеялись и вы бы так критически не высказывались о работе многих других людей (как вы наверное догадались, я не работаю одна). Но диалог возможен только в случае заинтересованности обеих сторон узнать что-то новое, взглянуть на вещи под необычным углом. А если на все решения, которые кажутся вам подозрительными, сразу ставить клеймо несостоятельности, это не только задевает людей, о которых вы пренебрежительно высказываетесь, но и обедняет вас лично.
Автор: Duke Shadow
Дата сообщения: 05.04.2004 15:34
tgalina

Цитата:
ситуация, когда юзер профайл имеет размер 10 мегабайт - не реальность, на которую надо ориентироваться, а реальность, с которой надо бороться, на мой взгляд.

Рад бы - да не выходит. Слишком много программ пихает свои шаловливые ручонки в профильные данные - ntuser.dat на мегабайт - нормальное явление. У нескольких специалистов только "Избранное" от IE (те, которые, Favorites) больше 0.5 мега. Переводчик PROMT - это вообще песня.

Цитата:
а не 2003, где наконец вводится Link Value Replication и Partial Attirbute set replication.

Только на функциональном уровне 2003

Цитата:
нам бы в голову не пришло закупить 312 домен контроллеров и поставить их в подсобке каждого магазина


Цитата:
Поэтому мне идея для каждого удаленного сайта создавать child domain кажется скорее следствием того, что подающий эту идею имеет большой опыт администрирования NT и не совсем знаком с 2000.

Кхм, всё-таки кое в чём у нас с Вами нестыковочка. Вы про ситуацию "у меня по городу порядка 40 точек в котрых работает 2-5 человек"(с)trisen. А мы Вам про подсети с числом пользователей чуть поболе . 50 хотя бы.

Цитата:
Именно поэтому прежде чем порекомендовать решение, мы тратим много времени изучая то, как работает бизнес.

А вот это на 100% верно. И именно в связи с недостаточностью исходных данных мы тут и развели этот спор - просто каждый исходит из собственного опыта. В связи с этим, видимо, нужно сказать Вам спасибо за наставление, т.к. возможно получение решения 1 dc в подсети для 1 компьютера.

Позволю себе некоторое лирическое отступление - на этом форуме для удобства пишущих и читающих предусмотрены некоторые дополнительные возможности. Поэтому если у Вас в браузере не отрублен злобно JavaScript - пользуйте! Нажатие на нике - вставка ника в окно ввода + переход на новую строку. Выделение текста + нажатие на ссылку "Цитировать" вверху поста - вставка в поле ввода цитаты из поста + переход на новую строку. Можете использовать коды форума для наглядности. Употребляйте по вкусу - берегите свои и чужие нервы .
Автор: Newbie777
Дата сообщения: 05.04.2004 15:42
tgalina, хотелось бы по возможности в общем разобраться в преимущетсве/недостатке OU перед доменами при объединении офисов.
Каждый из офисов помещается в отдельный сайт. Дальше я вижу два варианты.
1.создается один домен domain.com. Создаются Office1 OU ... OfficeN OU. На каждый OU делегируются полномочия местным аминам.
недостатки: невозможность задавать свои Account Policies(длинна пароля, комплексность пароля и т.д) в филиалах.
преимущества: минимизировано количество DC, и как следствие экономия денег.
2.создается empty root domain domain.com, нужен для отделения Enterprise и Schema Admins. Далее создаются N доменов office1.domain.com... offficeN.domain.com. В каждом из офисов раздаются полномочия Domain Admins.

Хотелось бы собрать преимущества и недостатки каждого из методов. Складывается впечатление, что домены в 2000/2003 AD остались как рудименты NT доменов.




Добавлено
Вот еще недостаток или мое незнание как это обойти.
При OU структуре, при добавлении компьютера в домен он не попадет автоматически в нужный OU, придется руками перетягивать из контейнера Computers в OfficeN, а это значит нарпягать вышестоящих админов. Как workaround использовать netdom.exe join /OU:OfficeNOU. Но это не есть удобно.
Автор: tgalina
Дата сообщения: 06.04.2004 06:53
Duke Shadow:

Простите, кажется я запутанно изъясняюсь. Да, и в случае с 50-60-100-200-800 пользователей в подсетях я все равно не вижу зачем создавать child domains. Domain отвечает за секьюрити и имеет мало общего с тем фактом, в одном или в разных помещениях ли сидят пользователи. Вопрос, в действительности, в том, надо ли помещать domain controller в каждом удаленном оффисе (subnet'е). Ответить на этот вопрос не предоставляется возможности без дальнейшего изучения ситуации. Но изначальный вопрос, кажется, был не про это, а про то, можно ли прожить без child domains. Ответ на этот вопрос - да, можно и нужно, разве что у вас есть необходимость ввести в каждом удаленном оффисе свою domain security policy.
Еще пыталась понять, что бы могло значить "решения 1 dc в подсети для 1 компьютера" и честно говоря ничего в голову не приходит. Что вы имели в виду?

Newbie777:
У OU нет преимуществ или недостатков перед доменами, так как это две очень разные вещи. Домены в 2003 - не рудименты NT доменов, а их улучшенная версия. Прочтите что на эту тему говорит MS. Я понимаю, что принято не читать первоисточники и ругать MS, а до всего доходить своим умом, но когда появляется потребность понять best practices, без документации вендора не обойтись. Child domains создаются не потому что они удобнее OU, а потому что они нужны чтобы решить конкретные задачи дизайна. Если у вас этих задач нет, не надо использовать средства для их решения для решения совершенно других задач. "Не надо умножать сущности сверх необходимости". Золотое правило для любой отрасли, не только для IT.
Автор: Newbie777
Дата сообщения: 06.04.2004 13:33
Child domains создаются не потому что они удобнее OU, а потому что они нужны чтобы решить конкретные задачи дизайна
какие конкретные(выше пример с вводом в домен) задачи поможет решить введение child домена, которые нельзя решить с помощью OU? Хочется разобраться. Если это описано в документации, готов все проштудировать еще раз, но дайте тогда ссылки на MS или на конкретные книжки.
Автор: Newbie777
Дата сообщения: 06.04.2004 22:14
господа, если нету прямых ссылок на документацию, просьба высказываться "от себя" на вопрос "что можно в домене чего нельзя в OU и наоборот?"

Вот что еще в голову пришло. Скажем, каждый из удаленных офисов хочет иметь свою почтовую систему. При этом каждый офис хочет быть независим от доступности почтовика головного офиса(VPN канал упал там или еще что), т.е. необходимо иметь N MX записей. Неприменное условие исользование Exchange.

Office1 - MX office1.domain.com
OfficeN - MX officeN.domain.com

т.е. email адреса для пользователей будут в виде
Office1 - вася@office1.domain.com
OfficeN- шура@officeN.domain.com

дальше у меня не хватает знаний, можно ли наставить N Exchage при одном домене и массой OU или нужны child домены?
Автор: Newbie777
Дата сообщения: 07.04.2004 13:40
всё ясно, пойду-ка я в другие места
Автор: euserz
Дата сообщения: 07.04.2004 19:22
tgalina
Вы так запутанно и длительно-долго изъясняетесь - ведь мысли можно выражать кароче. Начальные посты явно не состыкуются с последними, и наоборот. Остается только верить на слово!

Добавлено
Опять почитал. Подумал… потом еще подумал… опять почитал с самого начала, а потом стал медленно писать. Не пинайте, если что.

Цитата:
то в случае падения канала авторизация будет вашей самой маленькой проблемой. Что насчет почты? Она все равно идет через Internet feed, находящийся в головном оффисе - то есть при падении канала почты не будет тоже.


Я б... ответил, что авторизация будет проблемой, ибо следуя логике, падение канала не относится к авторизации, или, по крайней мере, не должно относиться (и не важно, это большая проблема или маленькая).

Почта – аналогично, кто бы смог поступиться почтой при падении канала? Желающие есть, конечно, всегда. Но, по-возможности, и этого следует избегать при проектировании топологии сетей, тем более, что почта в настоящее время является основным способом общения с внешним миром (опять же - это может не относиться к Калгари, в смысле к канадским гос.учреждениям - не думаю, что они вообще осознают в каком веке они живут).


Цитата:
Я думаю, что если бы мы с вами встретились лично и обсудили решения (что, очевидно, невозможно в силу географических обстотельств), которые я упомянула, недоразумения бы рассеялись и вы бы так критически не высказывались о работе многих других людей


Кстати, кол-во работающих “других людей” я бы так же не относил на правильность конечных решений и результатов: Логика – великий инструмент!
А встретиться – да, всегда пожалуйста нет ничего невероятного.


Цитата:
А если на все решения, которые кажутся вам подозрительными, сразу ставить клеймо несостоятельности, это не только задевает людей, о которых вы пренебрежительно высказываетесь…

Заранее извиняюсь, если мои сообщения кажутся резкими или даже выдаются за нападки! Ничего личного – скорее, они просто сухие и без эмоций (Спасибо товарищу Сталину за наше счастливое детство! Спасибо товарищу Путину за наше недетское счастье! ).



Цитата:
ситуация, когда юзер профайл имеет размер 10 мегабайт - не реальность, на которую надо ориентироваться, а реальность, с которой надо бороться, на мой взгляд.

Опять же, не согласен в корне – я бы не рекомендовал бороться с реальностью, тем более что реальность – вещь упрямая, и юзеры бодают, к примеру, меня по каждому поводу – наличие лишней головная боли и ущемление прав юзверей налицо - прям в процессе дизайна сети . Вопрос: оно того стоит?..


Цитата:
Child domains создаются не потому что они удобнее OU, а потому что они нужны чтобы решить конкретные задачи дизайна.

Exactly! И, как мнение незаинтересованного независимого перца (ну, меня то бишь ), Ваше предложение, точнее, способ внедрения “одного большого домена на всех“ проходит “на ура” лишь для ма-а-аахиньких сайтиков с минимально-низким кол-вом юзверей, а также при условии, что:
1) готовы поступиться и защищать грудью проблемы авторизации юзеров
2) готовы поступиться с проблемами почты (Exchange), при падении канала, к примеру, в Головном офисе
3) для Вас некритичен способ администрирования, Group Policy и Security при таком построении сети, а также подходит именно такой способ администрирования домена (к примеру, OU администратора всегда может “перебить” администратор домена, за что я б, к примеру, его просто пристрелил при встрече в коридорах Головного офиса).
4) Вы гибки в выборе usernames, так как при увеличении числа юзеров будут возникать совпадения (особенно часто такое встречается в Англии, где все Джоны и Джулии Робертсаны и их клоны-производные )
5) В распоряжении имеются широкие каналы и продуманы запасные абсолютно для каждого сайта (или только для тех сайтов, в случае падения которых голову открутят на 100-110%)
6) Вы точно знаете, что не будете быстро расти и сливаться с другими компаниями, ибо тогда мы все будем чесать запястье (а кто и головную кость) и гадать “верить/не верить” вливающейся в общий “котел” компании (я про trust relationship , ибо с child-доменами таких проблем, как Вы понимаете, не возникнет - Security остается на высоте)

И баста!

Плюсы же (в основном, думаю, что они мнимые):
1) упрощенный дизайн;
2) требуется минимальное кол-во железа и админов (опять же, выгода, но сомнительна и/или применима не ко всем, - потребуется серьезный анализ-обоснование типа TCO, ROI и т.д.)
И фсё. И усё, дорогие наши пЭрцЪI и…мАрковки!

Вывод:
Из всей баталии вытекает: когда число пользователей отдельных сайт(ов) велико (>10) и/или их жизнедеятельность (максимальная надежность, стабильность, гибкость, контролируемая (не)зависимость) абсолютно критична, а так же если планируется и/или не исключается возможность роста компании и всевозможных сливаний, следует обратить свой взор на дизайн сети с обязательным присутствием child доменов.

А остальным, в особенности Calgary Regional Health Authority, желаю хорошего полета, командир корабля и экипаж прощаются с вами…
(типа шутки…)

Newbie777

Цитата:
преимущества: минимизировано количество DC, и как следствие экономия денег.

С точки зрения логики это утверждение неверно. Следствие экономии денег неочевидно (ну, разве что, на первом этапе – этапе дизайна сети и подсчете сметы расходов на закупку оборудования, а ведь впереди еще трудовые будни, непрерывный производственный процесс, тех.обслуживание/поддержка).
Автор: Duke Shadow
Дата сообщения: 08.04.2004 09:56
tgalina

Цитата:
Да, и в случае с 50-60-100-200-800 пользователей в подсетях я все равно не вижу зачем создавать child domains.

За тем, чтобы уменьшить траффик, хотя бы. Если я не сильно ошибаюсь, то при создании нового пользователя в поддомене в родительский вообще почти ничего не отправляется. А при создании пользователя в границах одного домена - и SID и все прочие параметры автоматически реплицируются на все контроллеры данного домена. Если в чём-то ошибаюсь - поправьте, плз.

Цитата:
разве что у вас есть необходимость ввести в каждом удаленном оффисе свою domain security policy

А чем GPO не устраивают? Можно для каждого OU перекрывать доменную политику в каких угодно пределах.

Цитата:
Еще пыталась понять, что бы могло значить "решения 1 dc в подсети для 1 компьютера"

Пример: имеем основной офис и несколько ответвлений; задача - реализовать логическую структуру; согласно моим и euserz рекомендациям можно принять решение в каждом филиале поставить по dc; реализатор, наслушавшись умных советов пойдёт и сделает именно так, не учтя при этом, что в большинстве филиалов стоит 1-2 компьютера. Конечно за уши притянуто, но для иллюстрации - пойдёт.

euserz
Молодец, хорошо написал.
Автор: vworld
Дата сообщения: 08.04.2004 12:05
Я наверное не внимательно топик читал, или вы просто умные вещи говорите, но для себя из прочитанного я ничего не смог вынести, а ситуация у меня такая ... есть домен в нем примерно уже 70 юзеров, проблема в том, что некоторые юзеры не принадлежат моей организации и мне не хотелось бы чтобы они просто везде лазили по сетке, но в то же время они используют различные рессурсы, которыми все в организации пользуются, я просто развел все в AD по группам и все больше вроде как ничего и не делал, сервер на 2000 стоит, может посоветуете как правильно надо делать?
И еще вопрос, как сделать так чтобы все в сетевом окружение были по группам, а то все кто входят в домен в одной группе ?
Автор: Newbie777
Дата сообщения: 08.04.2004 12:32
euserz, гуд.
Я не доказываю что лучше.
Теперь по пунктам.
готовы поступиться и защищать грудью проблемы авторизации юзеров
о каких проблемах идет речь? в каждом site будет один DC ну два для полного fault tolerance(FT). При child доменах и частых командировках из офиса в офис, потребуется для комфортной работы дополнительно устанавливать DC на каждый из child'ов. Вот тут и видно, что child уступает перед OU.
готовы поступиться с проблемами почты (Exchange), при падении канала, к примеру, в Головном офисе
в каждом из офисов ставится свой exchange.
перимущества child: все адреса будут @domain.com, множество MX в одной зоне->упала первая MX, принимают почту следующий по cost'у.
недостатки OU: почта зависит только от своего почтовика, для FT потребуется еще один exchage в каждом из сайтов->увеличение TCO
для Вас некритичен способ администрирования, Group Policy и Security при таком построении сети, а также подходит именно такой способ администрирования домена (к примеру, OU администратора всегда может “перебить” администратор домена
согласен насчет "No Override" именно такие примеры я и собираю. Уточни насчет Security, с "Account Policy" понятно - только на уровне домена, есть еще что-то?
Вы гибки в выборе usernames, так как при увеличении числа юзеров будут возникать совпадения
Cогласен, в OU эта проблема более отстро втанет. Еще один плюс за child.
В распоряжении имеются широкие каналы и продуманы запасные абсолютно для каждого сайта
гуд, с OU увеличивается ощий трафик между сайтами. child'у плюс.
Вы точно знаете, что не будете быстро расти и сливаться с другими компаниями, ибо тогда мы все будем чесать запястье (а кто и головную кость) и гадать “верить/не верить” вливающейся в общий “котел” компании (я про trust relationship , ибо с child-доменами таких проблем, как Вы понимаете, не возникнет - Security остается на высоте)
несогласен, сдесь нужен пример, где я не смогу разграничить права в OU и смогу в child и наоборот.

euserz, anyway thanx. Таких бы ответов побольше.

Duke Shadow
А чем GPO не устраивают? Можно для каждого OU перекрывать доменную политику в каких угодно пределах.
не все так просто, No Override и усё, доменные перекрывают политику OU при любых настройках, даже при настройке "Не наследовать"

Страницы: 123

Предыдущая тема: Microsoft Systems Management Server 2003 R2 (MS SMS 2003)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.