Как внедрить контроллер домена в локальную сеть организации?

Question

[ilya_shlyahovsky]

Возникла потребность в установке контроллера домена в локальную сеть небольшой организации.
Есть офис в котором 25 ПК, часть из них под windows 7 и часть windows 10 и один из них на debian как файлообмен.
У меня несколько вопросов
1. Сервер AD поднимать на виртуалке или на физически ставить отдельный сервер?
2. Как я понял нужно два сервера AD, чтобы при отключении основного одного второй подхватывал на работу на себя? Или достаточно только одного?
3. Если ли возможность перенести данные с локального пользователя на доменного пользователя, чтобы юзер не увидел разницы и не надо было ему все настраивать 1С и т.д.
4. Что будет если сервер AD один и он допустим отключится , смогут ли пользователи залогиниться и не будет ли такого, что человек пришел утром вводит логин и пароль, а ему окошко мол войти нельзя из-за того что сервер недоступен?
И будет ли у юзеров интернет?
5. В локальной сети раздает ip роутер, могу ли я так и оставить понимаю что это неправильно, плюс у всех ПК стоит статика. То есть, могу ли я обойтись без dhcp сервера на AD?
6. Смогут ли ПК домена видеть сетевые папки ПК которые находятся в рабочей группе?

Comments

[hint000]

5. В локальной сети раздает ip роутер, могу ли я так и оставить понимаю что это не правильно, плюс у всех ПК стоит статика. Тоесть могу ли я обойтись без dhcp сервера на AD?

Если у всех статика, то никто никому не раздаёт и dhcp не нужен.

понимаю что это не правильно

Давно это считается неправильным? А то я почти 25 лет занимаюсь системным администрированием и только сегодня от вас первый раз узнал, что dhcp на роутере - это неправильно. :)

[ilya_shlyahovsky]

hint000, просто встречал людей которые мне утверждали что dhcp сервер должен быть обязательно на AD.

[hint000]

ilya_shlyahovsky, эти люди просто упоротые виндузятники. DHCP можно держать где угодно - на любом виндовом сервере, на любом линуксовом сервере и даже на аппаратном роутере. Другое дело, когда вы говорите слово "роутер", если подразумеваете роутер уровня SOHO (это не обязательно), то вот это как раз неправильно - держать 25 пользователей на таком роутере, он не рассчитан на такую нагрузку. Но это за пределами данного вопроса, просто к слову пришлось.

[Сергей Тарасов]

hint000, а если в роли роутера выступает mikrotik хотя hex или стоечного исполнения, то там такие чудеса можно творить... На прошлой работе на нескольких hex сидели офисы на 25-50 человек, работали по mpls друг с другом кажется (не моя ЗО была, могу перепутать), там и маршрутизация, и dhcp-опции, и VPN для удалёнки (в ковид было прям киллер-фичей)

[hint000]

Сергей Тарасов, только не путайте функциональные возможности (с одной стороны) и производительность железа (с другой стороны). Функциональность Микротика заключена на 90% в его прошивке (на 10% в железных схемотехнических решениях). И она (функциональность) богатая у всех Микротиков. А вот производительность зависит на 99% от железа и какой-нибудь hAP очень, оч-ч-чень слабенький по железу, на то и буква h в слове hAP - "home", т.е. он для домашнего применения. А для офиса у Микротика есть совсем другие модели и цены отличаются на порядок. И никто не говорит про дорогое производительное железо, что это класс SOHO, наоборот, его позиционируют как enterprise (корпоративный уровень). При том, что прошивка может быть та же самая и настроить крутые вещи можно и на hAP, но при 25 активных пользователях загнётся.

хотя hex или стоечного исполнения

И да, очевидно, что SOHO не делают стоечного исполнения (за редкими исключениями).
А ещё я не буду говорить, одну вещь про Микротик (при всех его достоинствах и недостатках), потому что на этом сайте не разрешают об этом говорить.

[Ивор Барханский]

dhcp сервер должен быть обязательно на AD.

Это просто крепкая рекомендация по причине того, насколько удобно работает связка DHCP+DNS в AD.

[IgorGS]

@hint000, А ещё я не буду говорить, одну вещь про Микротик

Нет уж, скажите! Заинтриговали)

Answer 1

[ZERGeich]

1. Лучше ставить на виртуалку и регулярно делать её снапшот на отдельно стоящее хранилище. При таком раскладе - даже если сервер виртуальных машин рухнет - у вас будет точная копия контроллера домена для восстановления.
2. Смотря какие требования у вас к домену. Какие задачи будете реализовывать и так далее. Вообще - для малой сети достаточно и одного.
3. Есть утилита привязки профиля profwiz. Как раз позволяет привязать локальный профиль к доменному логину.
4. Если пользователь уже логинился на эту машину - с вероятностью 90% у него это получится даже без контроллера домена.
5. Можете. DHCP - не обязан быть на контроллере. А вот DNS таки да.
6. Скорее всего таки придётся перекраивать права доступа на сетевые папки. Но вообще, при прямых руках, или умении обращаться к костылями - нет ничего невозможного.

Comments

[ilya_shlyahovsky]

А если будет физический сервер а не виртуалка, есть возможно делать бекапы сервера чтобы потом быстро восстановить домен?

[ZERGeich]

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

[Alexey Dmitriev]

1. На виртуалках.
2. Стандартный подход - минимум два контроллера.
3. Да, есть специалльные утилиты для миграции профилей.
4. Смогут, пока не истечет срок жизни закешированного пароля. Будет или нет интернет, зависит от ваших настроек доступа.
5. Да.
6. Если доступ ограничен - нет, если открыты для гостей - да.

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

[AntHTML]

tasviz/profwiz умер вместе с XP. В семерке был встроенный механизм переноса профиля. С 8, как начали продвигать Azure, все профили нацелили на облака.
На практике сталкивался с тем что profwiz на семерке вместо честного создания профиля users/aduser, тупо переписывал в реестре пути на users/admin и таких профилей создали 3 штуки, ну и потом ловили фееричные глюки от ie и прочего appdata зависимого софта

[ilya_shlyahovsky]

Alexey Dmitriev, понял, спасибо, браться не буду

[ZERGeich]

AntHTML, Ну, так-то автор не забросил софтину и 10\11 винду оно вполне себе корректно поддерживает. Проверял на своих подопытных.

[azqwerty]

hint000,
это какие-то специфические настройки кэширования учёток? По умолчанию - раз зашёл при живом контроллере, и устройство можно хоть домой увезти навечно, и логиниться будет без DC.

[Максим К]

Alexey Dmitriev, ну а где еще брать такой опыт??? Да попробовать развернуть на виртуалке, подключить пару физических машин, попробовать перенести профиль и дальше пробовать в организации, а остальное только так и пробовать набирать опыт.

[Alexey Dmitriev]

Перед получением опыта нужны теоретические знания в необходимом объёме, тне правда ли?

[pindschik]

ilya_shlyahovsky, а вы уверены, что не произойдет ситуация, когда полетит материнка и ваш бэкап просто не стартанет на другой системе? Виртуалка надежнее.

[pindschik]

Еще есть пара очень важных моментов для новичков:
1) Создайте отдельные админские права на рабочие места. Чтоб не администраторы домена у вас сидели за каждым компом, только ради того, чтоб они могли ставить себе софт сами.
2) Забывайте про шары на рабочих местах. И уж как минимум блокируйте доступ по сети к рабочим станциям для локальных администраторов. Иначе только вопрос времени, когда один сотрудник скачает трояна, который вам зашифрует всё, что только можно, включая все рабочие компы.

[Константин Фролов]

ilya_shlyahovsky,

А если будет физический сервер а не виртуалка, есть возможно делать бекапы сервера чтобы потом быстро восстановить домен?

Veeam agent free

[fpir]

azqwerty, Это локальная\доменная политика кеширование паролей, задаёт количество последних учётных записей залогиненых с данной машины в домен, по дефолту 3. Т.е. 3 доменных юзера, которые уже логинелись на этой машине, могут логинится локально под доменными учётками без доступа к контроллеру.

[azqwerty]

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

[fpir]

azqwerty, насколько я знаю, время жизни кешированных паролей равно времени жизни самого пароля, если он не ограничен - то и время жизни кеша не ограничено. Если, конечно, учётка не слетит.

Answer 2

[AntHTML]

0. А какова конечная цель использования AD? Так-то 25 ПК для домена крайне мало, по мне о домене стоит задумываться когда 75, ну или хотя-бы 50+ ПК, иначе это сильное усложнение инфроструктуры.
1. Сейчас наверное лучше уже на виртуалках, новые винды в них лучше живут, раньше во времена нетребовательных 2003/2008 КД ставили на надежный старый комп, 2019 такой финт не поймет.
2. Очень желательно 2+, но скрипя зубами, на таком парке можно обойтись и одним. Также желательно на КД больше никаких ролей не ставить. (Хотя в сетях 35 ПК встречал серваки "все в одном" AD+SMB+1C+SQL)
3. Лучше перенастроить, это не большая проблема
4. Все зависит от настроек групповых политик, можно разрешить логин без синхронизации с КД, а можно запретить. Но на практике, иногда компы не синхронизируются и пару дней могут входить без обновления билета, но в kerberos шары их тогда не пускает
5. DHCP - где угодно, DNS - желательно на КД, но не обязательно. Главное условие, чтобы DNS знал где находится КД и как можно быстрее эту информацию отдавал. Отсюда очень желательное условие - даже при раздаче IP по DHCP на компах адреса DNS забивать статикой
6. Все зависит от настроек доступа к папкам: можно оставить как есть, можно перевести на авторизацию по домену.

Comments

[ilya_shlyahovsky]

AntHTML спасибо, 25 мало? Получается оставвлять одноранговую сеть ? Я думал наоборот в домене будет проще администрировать

[AntHTML]

ilya_shlyahovsky, А что именно Вы собираетесь администрировать при помощи AD?

[mureevms]

0. Не слушайте автора ответа в этом вопросе. Нет минимума компов при создании AD. Можно хоть 10 ввести в домен и юэто будет удобнее, чем без него.

[ilya_shlyahovsky]

mureevms, спасибо

Answer 3

[Ивор Барханский]

1. Пляшите от лицензий по факту. Серверные лицензии это недешево. В остальном, виртуальный сервер воскресить несколько проще чем физический. Но физический не зависит от виртуального хоста. Это исключительно вопрос удобства.
2. Пляшите от требований к непрерывной работе. Если фирма как-то перебьётся пока вы чините вышедший из строй КД, можно обойтись одним. Если стоимость второго КД и лицензии заметно меньше чем денежные потери за простой фирмы - лучше подстелить соломку.
3. Можно.
4. В целом это возможно, но всё же это надо рассматривать как серьёзную критическую аварию инфраструктуры. С соответствующими подходами к решению.
5. Да. Потеряете несколько возможностей, которые я уточнил в комментариях к записи, но работать будет.
6. Нет, само не подхватится, нужно будет переделывать. Если есть финансовая возможность, есть смысл перенести файлошару на windows server core. Это несколько упростит жизнь. Если не заводить в домен, всё будет работать по принципу: ввёл недоменные логин\пароль на доступ в папку, зашёл в папку, ну разве что если она не расшарена гостям.