AD DS / DNS / DHCP.
Для начала давайте подумаем в каких предполагаемых условиях мы начинаем работу. Мы предполагаем что у нас на текущий момент нет никаких сервисов совсем, то есть будем поднимать всё с нуля. У нас есть только провод от провайдера который даст нам выход в интернет. У нас есть конечно некое серверное помещение в котором стоит коммутационный шкаф. В этом шкафу есть кросс с оптикой от провайдера, стоит коммутатор, в который заходит оптический патч.
У нас конечно есть патч- панели, в которые приходят провода со всех кабинетов. И есть коммутатор, порты которого мы соединяем с портами патч-панелей по мере заполненности кабинетов людьми. Также этот коммутатор будет нашем шлюзом так как он скроссирован с коммутатором в который заходит оптика от провайдера. Предположим что доблестными сетевыми администраторами у нас на этом абонентском коммутаторе настроена сеть 10.101.0.0.
Адрес шлюза предположим будет 10.101.0.254. Это всё наша стартовая точка, у нас нет больше ничего но нужно поднять базовые сервисы для пользователей-клиентов. А пользователи уже расселись по кабинетам - включили компьютеры со своей клиентской WIndows 10 - сидят и ждут от вас чудо. Вдруг мы слышим стук в дверь - кто это? Недовольные пользователи? Нет открыв дверь мы видим что доставка привезла 2 большие коробки. Это 2 одинаковых железных сервера, которые купила компания по вашим рекомендациям.
Отлично! Устанавливаем сервера в шкаф, подключаем их к гарантированному питания от источника бесперебойного питания и начинаем устанавливать на первый сервер операционную систему.
Установка Windows Server 2019
Лицензию мы купили. Теперь скачаем образ. Вы можете скачать образ где считаете более правильно. Я иду на адрес https://www.microsoft.com/ru-ru/windows-server **и скачиваю триальную версию. Для моего испытательного полигона это не имеет значение. Вы конечно в условиях своего продакшена ставите именно образ продукта.
Кстати по поводу локализации. В данной статье я буду использовать именно английскую версию. Это субъективно мое решение конечно - я считаю софт нужно изучать именно на английском потому что помощи в интеренет больше именно на английском языке и просто потому что некоторые русифицированные пункты настроек могут больше запутать чем помочь.
Итак после установки загружаемся в сервер, вводим пароль администратора который вводили при установке и нас встретит Server Manager, где нужно сделать предварительные настройки. Часовой пояс, имя компьютера (dc01), разрешить RDP подключение, назначить статический адрес (в нашем случае “10.101.0.253”). Таким образом мы уже забрали 2 адреса из нашей подсети:
10.101.0.254 - Шлюз (коммутатор);
10.101.0.253 - Это адрес нашего первого сервера с ролями AD DC, DNS, DHCP.
После чего отправляем сервер в перезагрузку для применения изменений.
Приступим к установке роли контроллера домена. Это будет новый домен в новом лесу. В IP настройках сетевого интерфейса заранее пропишем DNS 127.0.0.1 так как вмсете с ролью AD DC поднимется и роль DNS.
В server manager идём в Manage - Add Roles and Features:
Жмём несколько раз “Next”. При выборе сервера выбираем пока что единственный dc01
Выбираем роль Active Directory Domain Services.
После окончания установки жмём “Promote this server to a domain controller”
Далее уже становиться интересно - Мы делаем новый лес (new forest). Прописываем название домена. И вот с прописываем домена нужно быть аккуратней. По правилам хорошей практики исходить нужно из имени домена сайта компании. Например я выбрал свой домен в глобальном интернете mrstudio22.ru, но в случае домена активных каталогов нужно добавить субдомен, который будет говорить вам об этой площадке. Например brn.mrstudio22.ru так как brn - Барнаул. То есть в моём примере филиал организации в городе Барнаул.
Далее прописываем пароль восстановления домена и следом заносим в keepass в догонку с паролем от administrator. В современном мире без менеджера паролей никак.
Жмём далее, делегирование DNS пока можно не делать. А вот следующий пункт важен. В строку NetBIOS domain name вводим “BRN” - то есть наш субдомен от полного имени домена “brn.mrstudio22.ru”. Далее просто жмём далее и “install”. После чего сервер сам перезагрузится.
После перезагрузки наблюдаем наличие поднятых сервисов AD DS и DNS
Теперь поднимем очень важный сервис DHCP.
После установки жмём “Complete DHCP configuration”
В разделе “Description” просто жмём next. В разделе “Authorization” просто “commit” и далее “close”. Этим действием мы сделали авторизацию DHCP службы в домене, причем сделали это от имени доменного администратора. Авторизация обязательна так как неавторизованная роль DHCP не будет функционировать.
Теперь у нас практически полный набор базовых сервисов необходимых для работы организации. Но их ещё нужно настроить! Для начала взглянем на службу контроллера.
Идём в “tools” - “Active Directory Sites and Services”:
Для наведения порядка я переименую сайт с “Default-First-Site-Name” в “Barnaul”. Это делать не обязательно, просто мне самому будет так удобней так как если вдруг поставят задачу развернуть филиал в другом городе - это будет другой сайт со своей подсетью, и называться будет в соответствии с расположением. Это не обязательно - просто нагляднее для администрирования. По поводу сайтов вы можете обратиться к предыдущим моим статьям о Windows Server 2016.
Далее давайте обратимся к сервису DNS:
Мы видим что благодаря тому что сервер доменный, у нас уже есть зона прямого просмотра “brn.mrstudio22.ru”. Название зоны не просто так дублирует название домена - это говорит о том что эта конкретная зона обслуживает этот конкретный домен.
В принципе раз зона у нас уже есть, значит она должна работать. Но мы взглянем на один момент - в свойствах зоны есть пункт “Dynamic updates”. И он имеет значение “Secure only” - что означает что записи будут вноситься только тех машин, которые в домене. Если вам нужно чтобы DNS заполнялся адресами от машин, которые не включены в домен, то выставляйте “Nonsecure”.
И как мы можем увидеть, сам для себя сервер уже сделал “А” запись.
Зона прямого разрешения у на есть, теперь давайте активируем зону обратного просмотра. Это нужно для того чтобы мы могли IP адрес разрешать в имя. Правой кнопкой жмём по разделу “Reverse Lookup Zones” - “New Zone”.
На определённом этапе мастер нас спросит как будет в дальнейшем реплицироваться эта обратная зона - на весь лес или только в данном домене. Мы сделаем только в рамках домена:
На этапе идентифицирования сети нужно просто вписать нашу подсеть.
Затем выбираем безопасное или небезопасное наполнение зоны. То есть могут ли туда вписываться адреса НЕдоменных машин.
На этом настройку сервиса DNS мы пока закончим. Займёмся DHCP сервисом. Прежде всего нужно подумать о том что будет раздавать сервис клиентам. Мы знаем что у нас есть подсеть “10.101.0.0.” - значит для клиентов мы выделим диапазон от “10.101.0.1” до “10.101.0.254” исключая пул адресов для серверов (от 10.101.0.241 до 10.101.0.254). Напоминаю что “10.101.0.0” - это адрес сети а “10.101.0.255” - это широковещательный адрес сети и их нельзя задействовать для устройств.
Запускаем средство управления сервисом DHCP:
В открывшейся оснастке управления мы видим что у нас нет ни одной заданной области (scope). мы идём в “Action” и жмём “new scope”
Откроется мастер создания области. Первым делом обозначим имя области и описание. Имя области я обозначил как “brn01” - почему именно так? Так взглянув на название этой области любой поймёт что она применятся к подсети клиенты которой сидят в Барнауле в неком филиале “01”.
Далее обозначим диапазон адресов и маску:
Далее диапазон исключения для серверов и шлюза. Вбиваем и жмём кнопку “Add”.
Соглашаемся продолжить настройки:
Вносим данные о шлюзе:
Вносим данные DNS. Тут наш сервер 10.101.0.253 как и должно быть. Но тут вы можете спросить а что за сервер 10.101.0.252. И это хороший вопрос. На этом этапе начнём раскрывать тайну зачем нам второй железный сервер. И самые догадливые уже догадались что он будет репликой основной железки. То есть на нём будет реплицирование как контроллера домена и DNS зоны так и DHCP области. Поэтому для клиентов в сетевых настройках будет не только основной DNS сервер “dc01” он же “10.101.0.253” но и вспомогательный “dc01” он же “10.101.0.252”.
Далее соглашаемся что мы хотим активировать эту область. Без активации работать не будет.
Область появилась:
Тут может смутить значок восклицательного значка на сервере и области. Но это решается “рефрешем”:
Итак область настроена - а это значит мы можем пойти к пользователю и проверить получит ли клиентская windows адрес из нашего заданного пула. Садимся за компьютер пользователя и смотрим сетевые настройки. Видим что клиент получил первый адрес из области “10.101.0.1”. Отлично.
На этом этапе пользователи уже могут хотя бы пользоваться интернетом. Но самое интересное конечно впереди.
Репликация и отказоустойчивость.
Продолжаем поднимать инфраструктуру на нашем воображаемом предприятии. В прошлой статье мы подняли базовые сервисы AD DS, DNS, DHCP. В этой статье мы возьмемся за второй железный сервер и сделаем так чтобы она повторял все роли первого сервера. То есть настроим репликацию и отказоустойчивость наших базовых сервисов. Не важно сколько учётных записей в организации 10 или 1000, в любом случае нельзя полагаться на один железный сервер.
Для таких важнейших сервисов как AD DC, DNS и DHCP всегда должна быть дублирующая система. Если эти сервисы крутятся не на самом железе а на виртуальной машине, мы точно также реплицируем эти виртуальные машины на отдельном хосте. Отказоустойчивость должна быть обязательно, и не так важно дублируем ли мы зеркально сами виртуальные машины с сервисами, либо имеем параллельные аналогично настроенные виртуальные машины, в которых репликация настроена именно средствами самой windows, как в нашем случае. Проще говоря, имеем два железных сервера работающих как зеркало друг друга и в случае падения одного - пользователя даже не заметят что что-то из сервисов пропало так как всё обслуживание сразу на лету возьмёт на себя второй сервер.
Ну а мы с вами, узнав от Zabbix что один сервер ушёл в офлайн, не спеша чиним его в то время как пользователи продолжают работать. Есть в мире рэйд массивов похожая тема - называется RAID 1 он же зеркало. Это когда 2 одинаковых диска работаю в зеркальном режиме. При этом мы конечно имеем в распоряжении размер только одного диска, но зато если один диск погибает мы просто меняем его и зеркало восстанавливается без потери данных, и практически даже без простоя в работе. Но давайте за дело. На второй железный сервер точно также ставим операционную систему Windows Server 2019. Установка в том же порядке как на первом сервере. По завершению также как в предыдущей статье приводим в порядок определённые настройки:
-
часовой пояс,
-
имя компьютера (dc02),
-
разрешаем RDP подключение,
-
назначаем статический адрес 10.101.0.252,
-
Маска 255.255.255.0,
-
Шлюз 10.101.0.254,
-
DNS 10.101.0.253 и второй записью 127.0.0.1.
Естественно этот сервер для начала нужно ввести в наш домен. Давайте сделаем это. В Server Manager идём в пункт “Workgroup”:
Затем жмём кнопку “Change”
Имя компьютера оставляем, переставляем чек с Workgroup на Domain и прописываем наш домен “brn.mrstudio22.ru”.
Так как у нас ещё нет доменных пользователей, для авторизации используем нашего доменного администратора:
Сервер после перезагрузки станет частью домена:
Отлично! Первым сервисом репликацией которого мы займёмся будет конечно контроллер домена. Устанавливаем роль контроллера домена аналогично как мы делали на первом железном сервере dc01. Отличия начинаются при конфигурировании то есть после нажатия кнопки “Promote this server to a domain controller”.
Что мы меняем в первом окне мастера - да собственно почти ничего, потому что этот сервер уже является частью домена и поэтому он сам определил что мы хотим развернуть контроллер в уже существующем домене, в существующем лесу. Так же сразу прописан и сам домен “brn.mrstudio22.ru”. Но вот данные пользователя нужно сменить на доменного администратора.
То есть чтобы вы понимали - я на втором сервере dc02 всё это время работал через локального администратора. Не доменного! То есть видите разницу, да? Есть сущность “DC02\Administrator” и есть “BRN\administrator” - в первом случае это локальная учётная запись а во втором доменная. Далее скрин с доменным администратором.
Далее вбиваем пароль восстановления службы каталогов. И обратите внимание - он сам определил принадлежность к сайту “Barnaul”. Отметку на пункте “Global Catalog” можно оставить так как мы рассматриваем вероятность того что этот сервер может остаться единственным носителем контроллера в сети на какое-то время (пока чиним первый железный сервер).
Далее делегирование DNS мы пропускаем. А вот следующий диалог мастера очень интересен. Здесь мы собственно выбираем где основной контроллер с которого мы будем реплицироваться. И мы конечно выбираем наш первый сервер “dc01.brn.mrstudio22.ru”. Тут вы можете задаться вопросом - а почему такое длинное имя, почему просто dc01 нельзя? Тут по идеи надо углубиться в теорию о том что есть FQDN то есть полное доменное название компьютера. По сути это просто имя машины плюс полное имя домена, но всё вместе это более правильное название сущности в сети.
Пути NTDS/SYSVOL оставляем по умолчанию. А вот на следующем этапе есть интересная кнопка “View Script”.
И тут мы можем посмотреть скрипт PowerShell. То есть всё что мы делали через мастер этим скриптом можно сделать одной командой PowerShell. Полезно когда нужно поднять 50 контроллеров для репликации.
Жмём “next” и следом “install”. После чего сервер сообщает что он сконфигурирован как контроллер домена и непременно хочет перезагрузки:
После перезагрузки “внезапно” система уже предлагает авторизоваться под доменным администратором.
После перезагрузки в Server Manager наблюдаем что и DNS тоже поднялся. И что особенно примечательно что он стянул данные с основного DNS сервера. То есть репликация DNS у нас уже есть! Обратите внимание что появилась запись типа (NS) и для второго сервера что означает, как раз, именно репликацию.
Теперь когда на сервере dc02 есть репликация DNS мы можем вписать дополнительный DNS на сервере dc01:
Отлично! Но давайте проверим что у нас реплицируется сам контроллер. Мы создадим доменного пользователя и проверим появится ли он на втором сервере. Идём на первый сервер “dc01” - далее в Server manager - tools - Active Directory Users and Computers.
В разделе Users мы видим кучу групп, доменного админа и отключенного гостя. Это всё здорово но нам же надо заводить своих пользователей.
Тут надо остановиться и крепко задуматься! О чём? Жмём правой кнопкой, да создаём Васю Пупкина и дело в шляпе? Нет! Нужно подумать о многих вещах. Например о том что у нас могут быть филиалы в разных городах и поэтому надо делать каталог отдельно для каждого города. И в каждом таком отдельном каталоге уже будут пользователи и компьютеры именно этого филиала. Ещё надо подумать о том что мы захотим распространять на отдельные филиалы групповые политики. То есть на какие-то будем а на какие-то нет, и поэтому нельзя всё складывать в один каталог. И ещё обратите внимание на сами каталоги, у одного другой значок.
И тут просто дело в том что “Domain Controllers” это организационная единица а остальные это контейнеры. И важно знать что групповые политики распространяются только на организационные подразделения. Поэтому, хорошо обдумав всю нашу филиальную инфраструктуру, с вероятной моделью расширения, мы начинаем с того что что создадим OU (Organizational Unit) с названием города.
И в этой OU мы создаём OU “Users” и OU “Computers”:
Вот теперь порядок. Создадим пользователя “Елисеева Анна Петровна”.
Имя пишем латиницей, Last name пишем латиницей. Зачем? Потому что когда начнете поднимать какие-то сервисы, которые будут сами брать учётные данные из домена - они ничего не смогут взять если эти данные будут на кириллице. А вот строчка “Full name”, она же в свойствах учётки “Display name”, можно писать на русском - именно эти буквы увидит пользователь на экране приветствия.
Обратите внимание на то что у пользователя также как и у компьютеров есть тоже полное доменное имя:
Ждём несколько минут, затем переходим на сервер dc02 и наблюдаем что все данные о подразделениях, которые мы создали на dc01 и пользователе успешно реплицировались. И если вам не хочется ждать можно в командной строке сервера dc02 набрать команду repadmin /kcc * да там есть звёздочка на конце. Данная команда форсирует репликацию по всем контроллерам.
команда repadmin /replsummary покажет когда была репликация по расписанию (не форсированная) и были ли ошибки в процессе.
Будучи на самом первом сервере dc01, для форсирования репликации можно также использовать команду repadmin /syncall /aes.
Либо мы можем в оснастке “Active Directory Sites and Services” сделать это в NTDS Settings каждого контроллера. Почему бы и нет если у вас всего пара контроллеров.
Теперь давайте сделаем репликацию DHCP. Вообще-то в рамках сервиса DHCP не происходит именно дублирование самой службы. Тут больше речь об отказоустойчивости методом “на подхвате”. Для достижения цели мы естественно поднимаем роль DHCP Server.
Также как и при установки на первом сервере dc01 мы жмём на “Complete DHCP configuration”.
И также проводим авторизацию через учётную запись BRN\administrator. Открыв оснастку DHCP мы разумеется не видим область которую мы создавали на первом сервере.
Идём на первый сервер dc01 там где мы создавали область (scope) - Жмём правой кнопкой по области и выбираем “Configure Failover…”
Запустится мастер настройки отказоустойчивости DHCP роли. На первом этапе мастер спрашивает какую именно область мы будем делать отказоустойчивой, и предлагает выбрать адрес сети закрепленный за этой областью. Так как область у нас одна мастер по умолчанию поставил галочку “все области”. Просто жмём next.
Далее выбираем сервер dc02.
Хотя проще было просто набрать полное доменное имя второго сервера:
Жмём next. Небольшое отступление - я словил вот такую ошибку:
Такое может произойти если на серверах часы идут в разнобой с разницей в 60 сек и более. У меня вообще на dc01 стоял вчерашний день. Но если у вас с синхронизацией часов между серверами всё хорошо, то вы увидите это:
Мастер нас спрашивает как назвать отношения между этими двумя DHCP серверами - давайте сделаем покороче но так чтобы мы понимали какие сервера тут участвуют, например вот так “dc01-dc02.brn”. Далее режим “Mode” меняем на “Hot standby” - то есть второй сервер dc02 будет “на подхвате”. Режим “Load balance” - это полноценная работа двух серверов сразу, с настраиваемым балансом нагрузки - такой цели мы не преследуем, мы хотим просто страхующий второй сервер. Убираем галочку “Enable Message Authentication” - хотя можете и использовать парольную фразу для аутентификации, это на ваш выбор. Остальное оставляем как есть и жмём Next.
Далее жмём “Finish”:
Идём на сервер dc02 и в оснастке DHCP видим налу область “brn01”. Отлично!
Мы настроили базовые сервисы и сделали отказоустойчивость. Самое время идти на рабочие станции и вводить их в домен. Предварительно создав всех пользователей конечно.
Рабочая станция администратора.
Продолжаем поднимать инфраструктуру на нашем воображаемом предприятии. В прошлой статье мы настроили репликации базовых сервисов AD DС, DNS, DHCP. У нас теперь есть отказоустойчивость в виде двух аппаратных серверов со статическими сетевыми настройками. Рабочие станции у нас конечно будут получать сетевые настройки автоматом от DHCP. Можно идти до пользователей и переводить рабочие станции из рабочей группы в домен brn.mrstudio22.ru.
Но сначала давайте вернёмся в наш первый DC. То что мы заходим на контроллеры под учёткой “BRN\Administrator” - не есть хорошо. Мы конечно не будем отключать эту учётную запись - это делается на рабочих станциях но не на контроллерах домена. Нам нужно создать свою учётную запись, с которой мы будем работать на своей рабочей станции. Например** itmaster@brn.mrstudio22.ru. Затем создать энтерпрайс/доменного администратора itmaster-adm@brn.mrstudio22.ru **с помощью которого мы будем рулить серверами по RDP со своей рабочей станции. Сделать ещё нужно отдельную OU для доменных администраторов и отдельную OU для групп.
После создания пользователя itmaster-adm добавляем его в группы “Domain Admins” и “Enterprise Admins”
Теперь можно выйти из сеанса учётки “BRN\Administrator” и начать привыкать заходить на сервера через учётку “BRN\itmaster-adm”.
На этом этапе можно выйти из серверной и пойти в свой кабинет - вводить свою машину в домен и настроить удаленное управление серверами. Но давайте немного задержимся - дело в том что прежде чем вводить рабочую станцию в домен крайне желательно сначала создать объект компьютера в домене. Давайте сделаем это. Заходим в привычную нам оснастку “Active Directory Users and Computers” - и в подразделении, она же “OU” - “Barnaul\Computers” создадим 3 объекта компьютера, у нас ведь пока что только три пользователя в домене - это мы сами “itmaster”, ещё есть Елисеева Анна Петровна и некая Лазарева Светлана Юрьевна. Соответственно создаем для этих учёток объекты “WKS-BRN01”, “WKS-BRN02” и “WKS-BRN03”. Где WKS - это сокращение от WORKSTATION ну и BRN - указывает на филиал в городе Барнаул.
Обратите внимание - при создании объекта компьютера мы видим путь расположения. То есть - Домен brn.mrstudio22.ru - затем подразделение Barnaul - затем подразделение Computers (А можно было назвать это подразделение Workstations):
Ну вот теперь идём к себе в кабинет и вводим наш компьютер в домен. При этом держим в голове что имя компьютера мы переделываем на “WKS-BRN01”, доменный пользователь будет “itmaster@brn.mrstudio22.ru” и когда мастер нас спросит - какая учётка авторизует ввод в домен, мы укажем конечно “itmaster-adm@brn.mrstudio22.ru”. В истории о том что обычный доменный пользователь может 10 раз ввести машину в домен я не особо верю, хотя если использовать полное UserPrincipalName то есть полное имя доменной учётки, то оно работает. Но сначала, пока не ввели машину в домен, сделаем важную вещь - а именно создать локального пользователя с правами ЛОКАЛЬНОГО администратора. Так как изначальный локальный администратор, который так и называется “Администратор”, отключен - нам всё равно нужны пути отхода назад - например в рабочую группу, или например, для того чтобы подключить расшаренный принтер.
То есть если мы впоследствии выведем эту машину из домена мы не сможем зайти под доменными учетными записями, поэтому всегда должна быть локальная учётная запись и крайне желательно с правами локального администратора. Вы тут можете спросить - А зачем её создавать если при установке Windows мы её уже создали и с помощью неё и сейчас зашли на компьютер? Верно - более того я так и делаю на работе - изначально ставлю windows указывая пользователя soft с паролем который использую для всех машин. Таким образом я, как администратор, знаю параметры локального администратора на каждой машине.
И так заходим в свойства компьютера - жмём кнопку “Изменить параметры”:
Далее жмём “Изменить”:
Имя компьютера разумеется меняем на WKS-BRN01 и переключаемся с рабочей группы на домен. Имя домена “brn.mrstudio22.ru”:
Вводим данные своей доменной учётки:
И я словил ошибку:
Пробуем через доменного администратора “itmaster-adm@brn.mrstudio22.ru” - и таки да всё удачно:
Далее перезагружаемся - и мы в домене. Выбираем другого пользователя:
Обратите внимание на параметр входа “Вход в:” изменился на “BRN” - что говорит о том что система ждёт именно доменных авторизационных данных.
На всякий случай покажу, чтобы вы знали такую возможность, - как вернуться в локального пользователя если вы не знаете имя машины, на которой авторизуетесь - просто в поле пользователя сначала пишем точку - “.\soft”.
Отлично! Мы ввели первую рабочую станцию в домен. Давайте посмотрим как это событие отразилось на серверах. Ныряем в DHCP и видим в разделе “Address Leases” наш компьютер и дату истечения аренды IP адреса:
Теперь взглянем на DNS службу и видим что “A” запись для нашего “WKS-BRN01” красуется в списке зоны. Отлично!:
А теперь вернемся на нашу рабочую станцию и в командной строке набирём команду “ipconfig /all”
И видим тут много интересного. В том числе адрес DHCP сервера, адреса DNS серверов. итд. Отлично! Порядок ввода в домен для других рабочих станций будет такой - же. Только у них будет своё имя для компьютера и свой доменный пользователь. Можно идти по пользователям и вводить машины в домен чтобы люди начали работать. Предположим мы так и сделали, всех обошли и теперь вернулись в свой кабинет заварить чаю и немного отдохнуть. Заодно давайте сделаем так чтобы мы могли работать с пользователями не подключаясь к удаленному рабочему столу сервера. Как это сделать? Ну во-первых доменный пользователь под которым мы зашли в компьютер не имеет административных прав на этой машине. Давайте это исправим - ведь мы не рядовой пользователь а администратор и нам можно у нужно это позволить. Мы просто дадим нашей доменной учётке “itmaster@brn.mrstudio22.ru” права локального администратора. То есть просто включим его в локальную группу “Администраторы” этой машины. там же кстати и прибывает пользователь “soft”. Жмём правой кнопкой по “Пуск” и выбираем “Управление компьютером”.
Далее “Локальные пользователи и группы” - “Группы” - “Администраторы”:
Жмём кнопку “Добавить” - затем пишем имя “itmaster” - затем “Проверить имена” - где возможно нужно выбрать среди похожих учёток нужную. Затем “ОК”:
И ловим такую ошибку:
Давайте запустим оснастку “Управление компьютером” через доменного администратора. Как это сделать? В пуске выходим на “Средства администрирования”:
Далее выходим на оснастку:
Жмём правой кнопкой и через “Дополнительно” запускаем от имени администратора:
Система запросит авторизацию. Вводим доменного администратора.
После чего проделываем те же шаги для включения доменного пользователя “itmaster@brn.mrstudio22.ru” в ЛОКАЛЬНУЮ группу “Админстраторы” компьютера “WKS-BRN01.brn.mrstudio22.ru”. Перезагрузим компьютер. Теперь у нас есть права администратора, но только в рамках этой рабочей станции. Теперь мы можем устанавливать программы и выполнять команды в PowerShell от имени администратора.
Давайте запустим PowerShell от имени администратора:
Далее установим на нашу рабочую станцию RSAT компоненты. Вбиваем вот эту команду:
Get-WindowsCapability -Online | ? {$.Name -match “Rsat”} | % {Add-WindowsCapability -Online -Name $.Name}
Тем самым мы установим все необходимые оснастки для управления сервером со своей рабочей станции.
Теперь, когда мы пройдём в пуске в раздел “Средства администрирования” мы увидим дополнительные средства управления:
Запускаем “Пользователи и компьютеры Active Directory” от имени доменного администратора. Жмём правой кнопкой по значку и выходим на “Перейти к расположению файла” :
Либо просто в проводнике вбиваем этот путь “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools”. Затем копируем нужный ярлык оснастки на рабочий стол.
Далее зажимая shift жмём правой кнопкой по ярлыку “Пользователи и компьютеры Active Directory” - и выбираем “Запуск от имени другого пользователя”:
Авторизируемся под доменным администратором “itmaster-adm@brn.mrstudio22.ru”. После чего оснастка откроется со всеми возможностями, которые нужны для работы с доменными учётками.
GPO. Удалённое подключение к рабочим станциям.
Продолжаем поднимать инфраструктуру на нашем воображаемом предприятии. В этой статье мы посмотрим как мы будем подключаться удаленно к рабочим станциям. Потому что в Windows изначально не включен удаленный рабочий стол, а ещё надо нашу учётку доменного пользователя “itmaster” включить в группу локальных администраторов чтобы через неё мы могли подключаться по RDP, также как и нужно включить входящее правило на порт 3389 в брандмауэре. Всё это нужно сделать на всех рабочих станциях - и если у нас и 500 штук мы же будем ходить физически по всем машинам. Мы воспользуемся групповыми политиками. Они же Group Policy или GPO. Кстати не забывайте обновлять сервера:
У нас теперь есть вторая рабочая станция “WKS-BRN02” причём с Windows 7. Для разнообразия будем смотреть как ведёт себя семёрка в разных ситуациях. Работать за этой машиной будет Лазарева Светлана. Наша задача, будучи у себя в кабинете за своей админской машиной, включить на удалённой машине WKS-BRN02 сначала функционал RDP, затем включить в брандмауэре правило на разрешение входящих соединений на порт 3389, и добавить свою учётку в группу локальных администраторов на этой рабочей станции. Чтобы это сделать мы создадим объект групповой политики и прилинкуем его к подразделению “Barnaul”. Почему не к “Users” - потому что групповые политики могут применяться также и к компьютерам а не только к пользователям. Мы можем сделать это как и самой рабочей станции админа запуская ярлык оснастки:
Либо подключиться к удалённому рабочему столу сервера (RDP) и делать всё там. Я буду подключаться к серверу просто потому что там английский интерфейс у оснасток. Вы же можете всё делать и не подключаясь к серверу через запуск оснасток от имени доменного администратора.
И так запускаем оснастку “Group Policy Management”:
Раскрываем список леса, затем домена и выходим контейнер “Group Policy Objects” - тут все наши объекты групповых политик. Есть даже уже два дефолтных объекта - их трогать не надо.
Мы будем создавать свои. Жмём правой кнопкой по контейнеру “Group Policy Objects” - кликаем на “New”:
Пишем имя объекта групповой политики. Я назвал RDP_Enable:
Наш объект добавлен в список:
Теперь давайте пристегнём действие этого объекта групповой политики к нужному нам организационному подразделению “Barnaul”. Для этого в этой же оснастке жмём правой кнопкой по OU “Barnaul” и выбираем “Link an Existing GPO” что означает прилинковать существующую GPO:
И конечно же выбираем наш созданный ранее GPO объект “RDP_Enable”:
Обратите внимание у подразделения “Barnaul” появился ярлык объекта групповой политики. А это значит что эта групповая политика будет действовать на все подразделения которые лежат внутри подразделения “Barnaul” - а это по подразделение “Computers” и “Users”.
Мы создали GPO объект, пристегнули его на нужное OU, теперь самое время этот объект настроить. Жмём правой кнопкой по “RDP_Enable”, можно по самому объекту и можно и по ярлыку. И в открывшемся окне идём в Computer Configuration - Policies - Administrative Templates - Windows Components - Remote Desktop Services - Remote Desktop Session Host - Connections - Allow users to connect remotely by using Remote Desktop Services:
И внутри параметра просто включаем его - жмём “Enabled”:
Далее в этом же объекте групповой политики сделаем исключение для брандмауэра. Для этого идём по похожей схеме - Computer Configuration - Policies - Administrative Templates - Network - Network Connections - Windows Defender Firewall - Domain Profile - Allow inbound Remote Desktop exceptions
А также включим сразу возможность пинговать рабочие станции в пункте “Allow ICMP exceptions”:
Ну вот мы всё правильно сделали. Но для того чтобы политики применялись на рабочих станциях есть три варианта. Вариант один - просто дождаться когда они применяются по расписанию. Вариант второй - перезагрузка или перелогин на рабочей станции. Третий вариант - в командной строке рабочей станции написать “gpupdate /force”. Давайте воспользуемся вторым вариантом на рабочей станции с Windows 7. Перезагружаем компьютер Лазаревой Светланы WKS-BRN02.
Для проверки мы со своей машины пробуем подключиться по RDP к машине WKS-BRN02 с помощью пользователя itmaster-adm:
И мы подключились:
Это конечно хорошо. Но у нас задача подключаться НЕ с помощью доменного администратора “itmaster-adm” а с помощью нашей повседневной учётки доменного пользователя “itmaster”. Для этого нужно добавить сущность** itmaster@brn.mrstudio22.ru **он же BRN\itmaster в группу локальных администраторов данной рабочей станции, да и впрочем всех рабочих станций. Тут нужно понимать что эта политика не будет влиять на сервера, так как они находяться в другом подразделении. И поэтому не нужно переживать что наш обычный доменный пользователь станет локальным администратором на контроллерах домена.
Но сделать себя локальным админом именно на рабочих станциях было бы неплохо, давайте сделаем это. Прежде всего нужно понимать что в Windows как и в Linux не зря придумали группы пользователей. То есть права мы даём не пользователям конкретным а конкретным группам и потом мы можем сколько угодно пользователей включать и исключать из этой группы. Так просто рационально и удобно. Ведь если у вас будет помощник, которого тоже нужно будет сделать локальным администратором на рабочих станциях, вы просто добавите его учётку в группу, а не будете менять объект групповой политики добавляя каждый раз очередную учётку. Давайте сначала сделаем группу. Открываем оснастку “Active Directory Users and Computers” и создаем группу “LocalAdminBrn” в подразделении “Groups”:
Включим в эту группу учётку “itmaster”:
Ну а теперь добавим настройки в нашу GPO “RDP_Enable”:
Идём в - Computer Configuration - Preferences - Control Panel Settings - Local Users and Groups - Затем справа в поле жмём правой кнопкой и добавляем локальную группу “LocalAdminBrn”.
Сделали, теперь перезагрузим рабочую станцию и смотрим на состав локальной группы “Администраторы”. Так как политика применяется именно к компьютеру а не к пользователю то перелогин пользователя не поможет. Хотя можно просто выполнить команду “gpupdate /force”.
Смотрим на локальную группу. Давайте освежим в памяти как это сделать если мы в сеансе пользователя у которого на это нет прав на Windows 7. Идём - Пуск - Стандартные - Служебные - Жмём правой кнопкой по Компьютер - и выбираем “Управление”:
Вводим данные доменного администратора.
Либо локального администратора:
И видим что политика отработала правильно:
На нашей админской рабочей станции на Windows 10 всё сработало:
Для нашей админской машины это в принципе не нужно так как мы уже добавляли учётку “itmaster” в локальные администраторы, но каких-либо конфликтов в связи с этим не будет. Что мы добились тем что наш доменный пользователь стал локальным администратором на рабочих станциях - а то что теперь мы можем без проблем подключаться к ним по RDP, не задействуя доменного администратора. На этом всё, и переходите в следующий раздел.
DFS. Общий каталог.
Мы уже много чего достигли, у нас поднята основная инфраструктура на предприятии. Пользователи сели за работу. Мы можем к ним подключаться удаленно со своего рабочего места. Сервера настроены на отказоустойчивость. Но нам ещё нужно много чего сделать и много чего настроить. Задумываясь о высоком мы вдруг слышим телефонный звонок от пользователя. Пользователь просит сделать какой-нибудь каталог, с помощью которого он бы мог обменяться информацией с коллегами, то есть какой-то сетевой ресурс. Он же “Шара”, он же “Public”, он же “Обменник” и так далее. А ещё, говорит пользователь - “Хочу личный каталог на сервере чтобы туда резервировать важные документы”. Мало ли словлю шифровальщика, а у меня всё останется на сервере. Задача принята - ответили мы.
И так обговорим то что нам предстоит сделать. Нам нужно создать каталог - назовём его “Public”, в котором будем два каталога - первый это “Personal”, где будут личные каталоги пользователей, второй соответственно “Obmen”, это каталог для обмена файлами. И мы конечно понимаем что “Obmen” в конечном итоге превратиться в ту ещё файлопомойку, где пользователи будут именно хранить информацию а не размещать на время пока её не заберёт получатель. Зная это, мы понимаем что под это всё нам нужно немалое дисковое пространство. И у нас оно есть конечно, ведь заказывая сервера мы об этом заранее подумали и у нас теперь есть определённый RAID массив как на первом нашем железном сервере так и на втором. И он логически, конечно не в том же разделе где операционная система “диск C:\” а допустим на “диск D:\”. Не обращайте внимание на размеры разделов на скриншоте, у меня это тестовый стенд для написания статьи. У вас будет всё так как вы решили заранее для ваших продакшн серверов.
Начнём с того создадим каталог “Public”. Нам нужно создать его как на первом сервере “dc01” на диске “D”, так и на втором нашем железном сервере “dc02” тоже на диске “D”. А также внутри каталога Public - два каталога “Personal” и “Obmen”. Но давайте до создания подкаталогов установим роли DFS:
А теперь установим две роли - DFS Namespaces и DFS Replication. Причём сделать это нужно на обоих серверах.
Отлично, роли установились. Теперь давайте запустим оснастку “DFS Management”:
Создаём новое пространство имён - Жмём правой кнопкой по пункту “Namespaces” - и выбираем “New Namespace…”
Указываем наш первый железный сервер dc01, на котором мы собственно сейчас и работаем:
Вписываем предложенное в примере название “Public” и жмём “Edit Settings…”
В настройках пространства имен можно оставить всё как есть:
Далее мастер спросит тип пространства имён - мы конечно оставляем выбор на доменном а не на самостоятельном:
Остается сверить параметры и нажать “Create”:
Пространство имён успешно создано:
Теперь вернёмся к каталогу Public на диске D сервера DC01. Внутри создаём каталог “Obmen” и даём права на сетевой доступ для всех на запись:
Даём доступ всем на чтение и запись:
Жмём кнопку Share и затем Done. Теперь создаём каталог “Personal” и тут мы для всех делаем доступ только чтение:
То есть тут нужно понять - очень важно заранее сделать сетевые права заранее на каталоги. Obmen у нас должен быть доступен на запись всем так как это обменник. Personal - нужно чтобы все могли только зайти и увидеть свои подкаталоги. Но права на запись будут уже разруливаться исходя из подкаталогов и конечно исходя из того кто зашёл.
И очень важный момент - нужно проделать те же действия на сервере DC02. То есть подготовить каталоги на обоих серверах прежде чем добавлять их в пространство имён.
Теперь добавим каталог в наше пространство имён. Выделяем наше пространтсво “\brn.mrstudio22.ru\Public” и жмём спарва на пункт “New Folder” либо просто правой кнопкой по пространству и “New Folder”:
Жмём кнопку Add - Выходим на сервер DC01, выделяем заранее сделанную шару “Obmen” И просто жмём OK:
Не забудьте вписать имя каталога:
Мы создали каталог пространства имён “Obmen”, у которого есть сетевой путь “\DC01\Obmen”:
Но нам ничего не мешает добавить ещё одно расположение этого каталога. Или как по терминологии DFS - “Folder target”. Да это магия DFS - у одного каталога может быть несколько сетевых расположений! И как вы можете догадаться нам нужно указать расположение на нашем втором железном сервере DC02.
Выделив нужный каталог в пространстве имён жмём справа в действиях “Add Folder Target”:
Выходим на сервер DC02 и добавляям такую же сетевую шару “Obmen”:
Тут мастер, увидев два разных сетевых расположения у одного каталога пространства имён, логично нас спрашивает - а не хотим ли мы настроить репликацию, и мы конечно соглашаемся:
Откроется мастер создания группы репликации для каталога “Obmen”:
Первый диалог спросит название группы и имя каталога. Тут всё по умолчанию:
Далее мастер покажет нам членов создаваемой группы, то есть сетевые расположения синхронизируемых каталогов:
Далее нужно указать главный сервер. Мы укажем DC01. Следствием этого будет то что в каталоге “\DC02\Public\Obmen” удалится всё чего нету на данный момент в каталоге “\DC01\Public\Obmen”. То есть это критичный момент для самой первой синхронизации. Но так как оба наших каталога пустые то бояться нам нечего.
Топологию оставляем предложенную “Full mesh”
У нас репликация будет в рамках локальной сети поэтому пропускную способность оставляем по полной “Full”:
Далее просто жмём “Create” и “Close”:
Система предупредит нас о задержке в процессе репликации:
Теперь абсолютно те же действия нужно провернуть с каталогом “Personal”:
Каталог добавили и теперь точно также добавляем ещё один сетевой путь и затем репликационную группу:
А теперь давайте сделаем так чтобы наша система не зависела только от сервера DC01. Мы добавим сервер DC02 в список серверов пространства имён. Выделив наше пространство имён мы в правой части жмём “Add Namespace Server…”:
Находим через кнопку “Browse” либо просто прописываем DC02:
В списке Namespace Servers добавилась запись второго севрера “\DC02.brn.mrstudio22.ru\Public”. Это обеспечит нам отказоустойчивость при внезапном отключении одного из серверов.
А давайте заглянем в корень пространства имён а именно в сам каталог “C:\DFSRoots\Public”. И мы видим тут ярлыки настроенных наших каталогов:
Мы только что добились того, что у нас теперь есть некий сетевой путь “\brn.mrstudio22.ru\Public” обратившись к торому пользователи смогут работать со своим личным каталогом и обменным файлохранилищем. И причём данные синхронизируются между двумя серверами. И потеря одного сервера не повлияет на работу пользователей. С обменом уже работать точно можно, а вот личные каталоги это уже интереснее.
Прежде всего запомним для себя три золотых правила организации общего доступа к каталогам:
Первое - Доступ делаем для группы а не пользователей!
Второе - Доступ делаем для группы а не пользователей, даже если в группе будет только один пользователь!
Третье - Смотри два предыдущих правила!
Итак у нас есть пользователь Лазарева Светлана - давайте создадим ей личный каталог и убедимся что другие пользователи не могут туда зайти. Я находясь на сервере DC01 в сеансе доменного администратора, захожу через проводник в каталог Public\Personal на диске “D” и создаю каталог “lazareva.svetlana” для Светланы Лазаревой исходя из названия учётной записи:
Теперь перехожу в оснастку “Active Directory Users and Computers” и создаю группу “lazareva_svetlana”.
И конечно же включим в эту группу учётную запись Светланы:
Теперь возвращаемся к каталогу “lazareva.svetlana” - жмём правой кнопкой и выходим на свойства каталога. Далее вкладка “Sharing” и затем кнопка “Share”:
В выпадающем списке выбираем “Find people”
В списке находим группу “lazareva_svetlana” и даём ей доступ на запись “Read/Write”. А также доступ для всех “Everyone” - убираем:
Я зашел на второй сервер DC02 и в свойствах каталога увидел что данные доступа незамедлительно отреплецировались:
Проведём эксперимент - заходим на рабочую станцию под пользователем “lazareva.svetlana” - проходим на сетевой путь “\brn.mrstudio22.ru\Public” заходим в каталог Personal\lazareva.svetlana - создаём каталог или файл. Всё успешно. А теперь заходим на рабочую станцию под другим пользователем Елисеевой Анной - и мы даже не видим каталог Светланы. Это то чего мы и добивались.
Не забудьте самое важное в такой настройке DFS - нужно сначала просто в проводнике создать каталоги, затем дать им нужные права - а затем при добавлении каталогов в пространстве имён просто выбрать их из списка. НЕ СОЗДАВАТЬ их в процессе добавления каталога в пространство имён а именного выбрать уже настроенные шары. Иначе вы просто не сможете разграничивать права в подкаталогах.
Мы уже много достигли, но для того чтобы пользователям было проще обращаться к общим каталогам давайте подключим сетевой диск на все рабочие станции при помощи GPO.
Создаём объект групповой политики с названием “Map_drive_N”:
Пристыкуем наш объект групповой политики к главному подразделению “Barnaul” чтобы действовало на весь филиал:
Теперь настроим политику:
User Configuration - Preferences - Windows Settings - Drive Maps - далее справа New - Mapped Drive:
На вкладке General - Action оставляем “Update”. Location - тут выставляем путь нашего пространства имён “\brn.mrstudio22.ru\Public”. Ставим галку Reconnect. И букву диска меняем на “N”.
На вкладке Common - галочку на “Run in logged-on user’s security context”.
Ждём когда политика применится и проверяем
Способы влияния на рабочие станции.
Продолжаем поднимать инфраструктуру на нашем воображаемом предприятии. В этой статье мы посмотрим как мы можем воздействовать на рабочие станции помимо RDP. Находясь у себя в уютном кабинете, за нашей админской машиной “WKS-BRN01.brn.mrstudio22.ru”, в сеансе своей повседневной учетной записи “itmaster”. Которая, напомню из предыдущих статей, является локальным администратором на всех рабочих станциях, благодаря групповой политике, которая в свою очередь сделала так чтобы доменная группа “LocalAdminBrn” была в составе локальной группы “Администраторы” на рабочих станциях. И конечно же наша доменная учётная запись “itmaster” входит в состав этой самой доменной группы “LocalAdminBrn”. Это, так сказать, краткое содержание предыдущих серий. Мы посмотрим на некоторые возможности влияния на рабочие станции.
Начнём с того что нужно сделать исключение в брандмауэре по 445 порту TCP для того чтобы можно было дополнительно управлять рабочими станциями. Для этого внесём изменения в наш ранее созданный объект групповой политики “RDP_Enable”. В настройках политики мы идём в Computer Configuration - Policies - Administrative Templates - Network - Network Connections - Windows Defender Firewall - Domain Profile. Справа выбираем Windows Defender Firewall: Define inbound port exceptions.
И прописываем разрешение на исключение 445 го порта (445:tcp:*:Enabled:Admin_Shares):
После чего поставим курсор на следующую строку и можем жать “OK”.
Конечно вы уже поняли что речь идёт о легендарных “админских шарах” или легендарного доступа через доллар. Если мы в проводнике наберём сетевой адрес рабочей станции и далее через слэш пишем букву диска с долларом то попадаем таки на этот диск. И так на мы можем нырнуть на диск “C:\” любой рабочей станции, до тех пор пока мы там локальный администратор. Набираем в проводнике “\WKS-BRN02\C$” - И увидим содержимое диска “C:\” этой рабочей станции.
Это может пригодится, например, для копирования на рабочие станции каких то файлов установщиков. Или вам нужно наоборот что-то удалить из дисков. Можно получить список доступных административных шар на удаленном компьютере с помощью PowerShell команды: “net view \computername /all”
Если в проводнике набрать “\WKS-BRN02\Admin$” то мы попадём прямиком в каталог Windows он же “%SystemRoot%”.
Дальше интереснее! Мы можем нырнуть в оснастку “Управление компьютером” на любой рабочей станции. Запускаем у себя оснастку “Управление компьютером”.
Либо в поисковой строке набираем “compmgmt” и затем просто жмём “Enter” на клавиатуре:
Или нажать сочетание клавши “Win+R” - появиться диалог выполнения команд - набрать compmgmt.msc:
В появившейся оснастке жмём по верхнему пункту “Управление компьютером (локальным)” - и выбираем “Подключиться к другому компьютеру”:
И вот мы управляем удаленной рабочей станцией:
Теперь мы можем например поменять пароль у локальных учётных записей, в том числе из группы “Администраторы”. Или включить / отключить учётки.
На этом пока всё.