Организация доменной сети внутри предприятия
 

Здравствуйте.

Работаю в группе компаний с несколькими филиалами, но и логически и по бухгалтерии это разные организации.

Сетевая структура всех компаний такова: несколько каналов от провайдеров, шлюз под UbuntuServer, свитчи в которые подключены все стевые клиетны.
В головной организации порядка 60 машин, 20 iPad (сидящих через wi-fi), ноутбуки, IP телефоны пользователей мобильные телефоны пользователей.

Все филиалы связаны full-mesh VPN сетью и трафик ходит во все стороны свободно (сети 192.168.(0-6).0/24).

Хочу поднять контроллер домена, вот какие цели преследую:
- разграничение политик доступа пользователей на локальных компьютерах
- единая система авторизации для всех сервисов (одна учётная записть на всё):
авторизация на ПК,
авторизация в корпоративной почте (IMAP dovecot), +адресные книги всех сотрудников ГК
авторизация в 1С,
авторизация на Jabber-сервере, +списки пользователей сотрудников ГК
авторизация на прокси-сервере (squid)
авторизация в системе IP телефонии (Asterisk) +адресные телефонные всех сотрудников ГК
авторизация при доступе к wi-fi (+ организация гостевого доступа)
авторизация на терминальных серверах

А вопросы возникают вот какие:
У всех компаний есть свои сайты: maincompany.ru, secondcompany.ru и т.д. Во многих мануалах, которые я встречал в интернете указаны примеры типа maincompany.local. Стоит ли поднимать домен с таким именем или сделать его с существующим именем maincompany.ru?
Если я сделаю домены в разных компаниях не принадлежащими одному дереву, можно ли каким-то образом связать и, к примеру, группе пользователей одного домена дать права на доступ к терминальному серверу работающему в другом домене?
Возможно ли в свойства пользователя добавить какие-то свои поля, которые потом получать по LDAP? Например номер магнитного ключа используемого для входа в офис.
Какое железо лучше взять для контроллера домена на 100 пользователей? Стоит ли использовать виртуальные машины? Какая нагрузка на сеть будет?

Tonny_Bennet, в чём вопрос?
читать
читать
читать
включается в 1С
читать

exo, спасибо за статьи. Я сам бы немного позже нашёл наверное, но всё равно спасибо :). При создании темы случайно нажал на Tab, а затем на Enter. Тема создалась и мне пришлось её редактировать. Так что большая часть интересующей меня информации появилась позже.

я рекомендую "название_ассоциирующиеся_с_компанией.internal". Домен в интернете и домен AD могут быть не связанными.
доверительные отношения между доменами. Ну и собственно, управление доступом через членство в группах.
скорее всего через атрибуты.
пару серверов базового уровня. Использование виртуальных КД поддерживается. Нагрузка на контроллер домена не очень большая. Я бы сказал никакая, по сравнению с нагрузкой на файловые сервера.
Сколько пользователей в филиалах?

У меня сейчас в компаниях почтовые адреса имеют такой формат: n.sername@maincompany.ru. Серверы и некоторые железки во внутренней зоне просмотра BIND9 имеют названия server1.maincompany.ru. И вот чтобы не менять структуру да и логику работы думал сделать реальное имя.
Почему так делать не стоит? или наоборот стоит?

У меня в головной организации есть сервер (2Х E5410, 16GB, RAID10 500GB), на котором сейчас крутится служба сервера 1С предприятия (сервер с БД - отдельная машина). Я думал поставить на него гипервизор и развернуть две виртуалки: сервер 1С и контроллер домена. Стоит ли?

В первом около 30, еще в двух по 20.

Там предполагал сделать похожую архитектуру и поднять контроллер домена на виртуальной машине.

вполне. но лучше если один из контроллеров домена будет отдельной железкой.
там есть свои админы? там можно установить RODC.
Почтовые домены также могут быть не связанны с доменом AD. А вот связь с интернет доменом - обязательна.
2008 R2 Полное руководство. Со стр. 191:

Или удобство или безопасность.

Админ, а точнее IT специалист, есть только в одном офисе и давать ему какие-либо права на AD я не планировал. Обслуживанием офиса будет занимается один человек, обслуживанием серверов занимаюсь я.

Прочитав про RODС я не увидел преимуществ в предполагаемой мной архитектуре. Пусть будет четыре равноправных DC и между ними будут доверительные отношения.

Предположим я выбираю доменное имя, зарегистрированное в интернете и у меня компьютеры и серверы будут иметь имена типа: buhgalter.maincompany.ru, server1.maincompany.ru и т.д. У меня сейчас есть DNS сервер BIND9, который обслуживает зону maincompany.ru и отдаёт адреса записей в интернет или в локальную сеть. В зависимости от того откуда пришёл запрос я отдаю локальный или внешний адрес. Теперь получается за ответы в локальную сеть будет отвечать DC и он будет мастером, а свой BIND9 я могу сделать слейвом. У клиентов можно будет в настройках оставить только адрес BIND9 и при необходимости он будет стучаться на DC. Т.о. запрос из внешней сети дальше BIND9 не пройдёт, а запрос из локальной сети я перенаправлю на DC.

Или может как-то иначе сделать в этом случае?

безопасность в филиалах.
в одном домене они и так есть. Сети нужно только VPN объединить.
пользователь отправил запрос http://maincompany.ru - что вернёт ему ДНС ? любой, на важно BIND или Windows.

Источник

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

Я предполагаю в каждой компании делать свой домен: maincompany.ru, secondcompany.ru, thirdcompany.ru, fourthcompany.ru. И они не будут деревьями одного леса. Сети уже объединены по VPN.

Сейчас, как и задумано, вернёт IP адрес нашего интернет-магазина. Но если отправить запрос mail.maincompany.ru из внутренней сети он вернёт локальный адрес почтового сервера, если отправить запрос из интернета то вернёт внешний адрес почтового сервера. Также внутри сети сейчас пользователи подключаются к терминальном серверам по именам компьютеров 1c.maincompany.ru или 1c.secondcompany.ru.

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

точно? =)
думаю что он ему вернёт список DNS серверов отвечающих за зону maincompany.ru
проверьте nslookup'ом.
а вот если ввести http://www.maincompany.ru и будет соот-щая запись А на ваших DNS'ах, то ему отдадут нужный адрес в интернете.

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

я так понял, что BIND и есть ответственный за зону maincompany.ru.
А вот что будет, когда Tonny_Bennet настроит домен - ему предстоит узнать )
это просто приведено в пример как вариант, какие схемы бывают.

ничего не будет, нет записи A, ну а скрещивать AD + bind - удовольствие ниже среднего, хотя это допустимая конфигурация.

тогда нужно ещё осветить вариант разных лесов и доверия меджу ними, ведь утопий мало не бывает ;)

запись А конечно же в домене есть. и будут они указывать на контроллеры домена.
а так, как бразуеры, к сожалению, всё ещё не поддерживают SRV для 80 порта, то развести запросы по http и smb на maincompany.ru не получится.
Хотя с IE 11 не тестировал пока...

я имела ввиду A=www

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

Обращается он, как я понимаю, к контроллеру домена, который должен располагаться по адресу maincompany.ru. Если так, то подойдут только зоны типа .local или .internal.

А может он обращается к компьютеру с именем типа dc.maincompany.ru? Тогда моя схема вполне реализуема.




Я не вижу разницы, за исключением того, что мне сообщили о CNAME записи.

У зоны несколько записей (ns,a,mx,cname). Сейчас за зону отвечает мой BIND и отдаёт её во внешний мир и в локалку. По идее это две разные зоны (bind view) - на адреса 192.168.0.0/24 отдаётся одна зона, всем остальным другая. И мне показалось, что если за зону maincompany.ru внутри сети будет отвечать DC, а BIND будет выступать в качестве slave сервера, то все пользователи могут просто стучаться на BIND и получать от него правильные ответы. Также можно и с обратной зоной для локальных адресов поступить.

в разных случаях по разному. но политики грузятся с \\maincompany.ru\SYSVOL\ и т.д.
имелось ввиду nslookup maincompany.ru
пользователь стучится из внутренней сети, и его перенаправляет на "внутреннюю зону" slave. И там будет две записи:
same as parent folder А 192.168.0.X - адрес контроллера домена
WWW A реальный.адрес.вашего.сайта
Но смысл, если всё тоже самое делает Windows DNS ?

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

Всем спасибо за ответы. Пошёл поднимать гипервизор :).

:up