Какие могут быть подводные камни заведения сервера в домен?
Доброго дня.
Я понимаю что вопрос глупый, но с учётом того что я хочу сделать, лучше лишний раз задать глупый вопрос, чем потом разгребать его последствия:)
У меня есть терминальный сервер (192.168.0.100)на базе Windows server 2016, на котором под hyper-v крутится контроллер домена (192.168.0.250). При этом, сам терминальный сервер в домен не входит.
На терминальном сервер есть огромная куча локальный пользователей который заходит на него по RDP и там уже занимаются своими делами.
Я хочу загнать терминальный сервер под управление контроллера домена, и как я понимаю, чисто в теории, пользователи которые заходили на него под локальной учёткой, так и смогу заходить, а я уже смогу постепенно создавать доменные учётки, и так же постепенно избавляться от локальных.
В службах, все службы запускаются от учётной записи "Локальная система", кроме apache. Он от локального администратора. Но одну службу переправить не сложно.
Вот та схема, что я описал выше, взлетит? Или я упустил какой либо важный момент?
Первичный контроллер домена ВСЕГДА должен быть только на реальной машине, без сопутствующих задач. Хоть целерон, хоть атом, хоть еще какой баребон или древность
Вторичные могут быть виртуальными.
В случае костыля с виртуальным первичным контроллером - его хост НИКОГДА не должен вводится в его домен. Иначе легко отстрелить себе ноги
Но если служба hyper-v будет стартовать от локального администратора, разве это не это не убирает возможность проблемы с тем что контроллер домена не стартанёт?
Я спрашиваю не с целью уличить вас в неправильности мнения, а для самообразования.
Я сам полностью согласен что КД нужно вынести на физическую машину, и будут этим завтра заниматься, но всё же, будь ситуация иной?
В случае костыля с виртуальным первичным контроллером - его хост НИКОГДА не должен вводится в его домен.
В целом согласен. Не согласен, что называете это костылём. Нормально работают у меня 5 (пять) контроллеров одного домена, все на виртуальных машинах, все на разных хостах, хосты линуксовые и не в домене. Ничего костыльного в этом не вижу.
Также сто лет уже нет деления контроллеров на первичный и бэкапный (если не ошибаюсь, начиная с Windows 2000). Все контроллеры сейчас равноправны, роли FSMO можно в любое время назначить любому из контроллеров. То, что выделение "первичного контроллера" устарело, лишний раз подтверждает название одной из ролей FSMO: "'эмулятор PDC" - именно эмулятор, а не настоящий PDC. partisan42,
если служба hyper-v будет стартовать от локального администратора, разве это не это не убирает возможность проблемы с тем что контроллер домена не стартанёт?
не стартануть может по самым разным причинам (не уследили и место на диске закончилось и сто других причин), но важно, чтобы не пропадал доступ, чтобы можно было с незначительным сбоем разобраться за несколько минут, а не тратить кучу времени (и нервов!) на попытки восстановления доступа, прежде чем вообще удастся понять, что же там на самом деле случилось.
Репортёр издания New York Times Шира Френкель рассказала о том, что сотрудники Facebook не могут попасть в дата-центр для устранения проблемы. Из-за сбоя их бейджи не сработали, чтобы открыть двери в офис компании.
Когда удалённо накосячили с настройками сети; удалённый доступ пропал; сотрудники приехали в офис, чтобы разобраться на месте, а попасть в офис нельзя, потому что кто-то шибко умный завёл СКУД в общую сеть, и СКУД тоже не работает и никого не пускает по карточкам в офис. Т.е. не надо строить такую инфраструктуру, которая в результате сбоя (не важно какого; не важно, насколько редкого) в принципе может вас заблокировать и помешать устранению сбоя. Учитесь на ошибках Фейсбука.
hint000, Огромнейшее спасибо за столь развёрнутый ответ:)
Судя по всему что тут было написано, единственный подводный камень, который я не учёл, это запуск виртуальной машины в случае внезапного ребута или подобных вещей. Благо, в конкретно моей ситуации, серверная буквально в 30 метрах от меня, и даже если что то случится я смогу уже в течении пары минут подцепить монитор и клавамышь. Да и RDP под локальной учёткой всё таки никто не отменял.
hint000, когда KVM в качестве гипервизора, то проблем особо не будет, правда линуксы заведенные в керберос пару раз начанали тупить на локальной авторизации при недоступности сети и соответственно кд. А вот когда хостовый hyper-v заводят в гостевой домен и это единственный кд - могут быть проблемы.
КД одна из самых особо не требовательных задач, поэтому в нынешних реалиях купить за 200$ NUC и развернуть на нем корневой DC - вообще не проблема.
Костыли начинаются когда экономисты не разрешают покупать лицензию, потому что у вас еще 2 комплектных гостевых ключа не использованы и выкручивайтесь с ними.
partisan42, А не лучше (возможно) поменять местами. В смысле: DC мигрировать на хост, а TS в гостевую.
Шансы угробить TS на который ходят юзеры гораздо выше чем DC для админов. А вот поднять виртуалку из бэкапа/снапшота проще и быстрее чем хост. Правда можно встрять в траблы с пробросом ключей
AntHTML, я бы даже предложил не или-или, а виртуализировать и TS, и DC, а на хосте никаких ролей кроме гипервизора не крутить, тогда и в домен включать хост никакого резона не будет.
можно встрять в траблы с пробросом ключей
Точно, Hyper-V не научилась. Как компромисс, можно на хосте оставить драйвер ключа и не пробрасывать ключ, а обращаться к нему по сети.
