Ввод удаленного подразделения в домен центрального офиса

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

Имеется ЛВС предприятия. Без Домена
Приведена логическая схема сети с примерным описанием:
• На чем построена сеть.
• какие службы и сервера встречаются в сети.
• Условных групп, на которые можно разделить офисы.
В сети настроена маршрутизация. Любые 2 узла сети могут «видеть» друг друга по ip адресу в рамках всей сети предприятия. Для больших офисов это организовано с помощью интернет шлюза Kerio Control. Одиночные виндовые клиенты подключаются к сети офиса по Kerio VPN.
Есть намерение перевести сеть на доменную архитектуру.
В рамках одного(центрального) подразделения проблем особых не вижу:
• Поднять контроллер домена с ролью DNS сервер.
• Перенастроить службу DHCP на интернет шлюзе так, чтоб клиентам выдавался ip DNS адрес контролера домена.
• Ввести клиентские ПК и сервера в домен.
• На интернет шлюзе DNS сервер указать ip адрес локального контроллера домена
• На контроллере домена сервер пересылки – dns провайдера.
В тестовой среде это заработало.

Вопросы:
1) Как следует настроить Службы AD и DNS в рамках всего предприятия (всех ее удаленных подразделений) таким образом чтоб:
• В каждом из удаленных подразделений можно было поднять свой контроллер домена.
• ПК офисов аутентифицировались в первую очередь на контроллерах своего офиса, а если к ним нет доступа, только потом на контроллере / контроллерах доменов удаленных офисов.
• Контроллеры офисов между собой реплицировались как полагается.
• При падении VPN канала с центральным офисов, не было проблем с разрешением имен в удаленном офисе.
Слышал/читал, что есть технология сайтов AD, настроив которую, можно получить реплики и предпочтительные маршруты авторизации. Но хотелось бы четкую последовательность шагов. Начиная с момента приготовления к разворачиванию домена в удаленном офисе, при условии, что в центральном офисе домен уже развернут. Полагаю основной вопрос как настроить DNS.
2) Как поступить с одиночными клиентами удаленных микро офисов и домашних клиентов:
• Вводить их в домен или нет. Ведь при отсутствии связи с контроллером домена в удаленной сети, у них могут возникнуть проблемы с авторизацией на локальной машине?

На рисунках изображена текущая и плановые схемы сети

Миниатюры

   

0

0

qwertehok, Всю сеть указанную выше, в организации строил я. Просто не связывался с доменами более чем на одно подразделение.
Если выяснить ключевые моменты, думаю у меня серьезных проблем не будет.

0

Эти вопросы лучше задать на форуме системного администрирования windows

0

Сообщение от Джуниор Полагаю основной вопрос как настроить DNS

Так и оказалось.

Сообщение от Джуниор 1) Как следует настроить Службы AD и DNS в рамках всего предприятия (всех ее удаленных подразделений) таким образом чтоб...:

Как сделал:
• В удаленном подразделении, на сервере, который планировалось сделать контроллером домена, указал в настройках сетевого адаптера качестве dns ip 1-ого контроллера из центрального офиса.
• Ввел этот сервер в домен. ( Как оказалось необходимым и достаточным условием ввода в домен являлся сетевой доступ с этого компьютера к DNS серверу домена и учетные данные с правами на ввод в домен)
• Поднял на сервере роль до контроллера домена. Указал сервер КД из центрального офиса, с которым следует реплицироваться. ( он обранужился автоматом)
• Сюда же на этот сервер установилась служба DNS. Настроил DNS - настройках сетевого адаптера указал DNS указал первым свой DNS ( 127.0.0.1) вторым DNS контроллера домена из центрального офиса. AD и DNS зоны синхронизировались с контроллером из центрального офиса.
• Создал в AD сайты, подсети, линки между сайтами.

Сообщение от Джуниор Как поступить с одиночными клиентами удаленных микро офисов и домашних клиентов: • Вводить их в домен или нет. Ведь при отсутствии связи с контроллером домена в удаленной сети, у них могут возникнуть проблемы с авторизацией на локальной машине?

Решение для клиентов (одиночных ПК):
Kerio VPN клиент позволил устанавливать VPN между клиентской машиной и сетью офиса до авторизации пользователя машины в домене/системе.
• Ввел машину в домен
• Для авторизации машины использовал отдельные не доменные аутентификационные данные, чтоб сотрудник не мог подключатся к сети офиса с произвольного устройства со своими доменными данными которые он знает. Теперь только админ знает и вводит имя и пароль на оговоренном устройстве пользователя который сохраняется в зашифрованном виде на ПК пользователя.
•В настройках адаптера который, создал в системе kerio клиент, установил галочку регистрироваться на DNS сервере.

В результате:

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

•Удаленные сотрудники могут входить в домен так же как и локальные сотрудники. И к ним так же есть доступ из офиса. При этом, сотрудник ( если конечно не научится извлекать шифрованный пароль из системы) не сможет попасть в сеть организации с произвольного устройства.


Пока 80-90% возникших проблем решено.

1

Сообщение от Джуниор Как поступить с одиночными клиентами удаленных микро офисов и домашних клиентов: • Вводить их в домен или нет.

Одиночных клиентов я бы не вводил, а выдавал бы им логин-пароль для авторизации на ресурсах сети. (ессно настраивая один раз VPN пароля которого они не знают).
Отключить такого клиента проще простого - откл. учетку керио.
Почему? практика показала, что одиночные клиенты приходят и уходят. А морока с вводом в домен и переносом\созданием профиля на компе забитым доверху вирусами и майнерами будет всегда. Меньше телодвижений - меньше проблем.
если клиент важную работу делает, то ему ставится корпоративный антивирь управляемый с центрального сервера доступного через интернет. В случае чего - папку уничтожить можно и вырусы гонять не сложно.

2

Сообщение от CHESTER-ART А морока с вводом в домен и переносом\созданием профиля на компе забитым доверху вирусами и майнерами будет всегда. Меньше телодвижений - меньше проблем.

Пока не определился. Будем экспериментировать. Текучки пока не так много.
Одним из факторов в пользу домена для отдельных ПК является возможность установки ПО работающих по сети по команде из центра:
Удаленное управление, инвентаризация, блокировка учетной записи и.т.д.

Еще, думаю это избавит от необходимости смены множества паролей при увольнении сотрудников ИТ.
Удаленные ПК и микро офисы в этом отношении уязвимы, про них легко забыть / пропустить/ не доделать.

0

Сообщение от Джуниор Текучки пока не так много

думал я лет так 10-15 назад.
потом отрастил бороду, и мне стало лень...

Добавлено через 4 минуты

Сообщение от Джуниор Одним из факторов в пользу домена для отдельных ПК является возможность установки ПО работающих по сети по команде из центра: Удаленное управление, инвентаризация, блокировка учетной записи и.т.д.

это не работает когда пользователь нахудится в зажо**инске со скорость в 512 кб\с с постоянными обрывами.
пользователи шлюза VPN скажут вам спасибо при глюках передачи особоважного контента в 2-10 ГБ и т.д.
Ну только если это ноуты вашей конторы, может быть, хотя я предпочитаю юзать Касперски центр для управления антивирусом, а ПО они сами наставят какого хотят и вы им врядли помешаете без заморочек. Но зачем?! (сказал я... у меня ведь борода есть!)
Главное от ВПН сервера фильтрануть трафик в сеть - открыть только нужные IP, а если совсем делать нечего , то и порты.

0

Спасибо за информацию. Будем принимать к сведению.

1

0