Цель работы: научиться вводить компьютер пользователя в домен.
¶ Краткие теоретические и учебно-методические материалы по теме лабораторной работы:
На этой практической работе мы рассмотрим основные требования и подготовительные шаги, которые нужно выполнить на рабочей станции для подключения его к домену Active Directory:
Например, в домен можно добавить только следующие редакции Windows 10/11: Pro, Education, Pro for Workstations и Enterprise. Редакции Home не поддерживают работу в домене Active Directory; Windows Server.
Компьютер должен иметь доступ к сети, из которой доступен хотя бы один контроллер домена AD. Предположим, что на вашем компьютере уже настроен IP адрес из локальной подсети, а в настройках DNS северов указаны IP адреса ближайших котроллеров домена (вы можете настроить параметры сетевого адаптера вручную или получить от DHCP сервера);
Время на компьютере не должно сильно расходится со временем на контроллере домена (плюс-минус пять минут). Корректное время нужно, например для выполнения Kerberos аутентификации;
Необходимо задать корректное и понятное имя вашего компьютера (hostname), под которым он будет добавлен в домен. По умолчанию Windows генерирует имя компьютера при установке, но лучше изменить его на что-то более осмысленное.
Давайте удобно структурируем эту информацию.
¶ Требования для работы/ввода в домен AD
- Редакция Windows выше чем Home;
- Необходимо задать корректное и понятное имя вашего компьютера (hostname);
- Компьютер находится в одной сети с контроллером домена (DC), либо имеет маршрут до сети где находится DC;
- В настройках DNS-сервера на компьютере указан DC (это нужно чтобы компьютер смог обнаружить домен и его служебные записи);
- Время на компьютере не должно сильно расходится со временем на контроллере домена (плюс-минус пять минут).
¶ Задания для практической работы:
Для начала давайте проверим соответствует ли наша рабочая станция Windows 10 для ввода в домен AD.
¶ Проверка требований
Начнем по порядку
Проверим hostname (он у нас по схеме должен быть WCLI) и редакцию Windows.
Чтобы их проверить перейдите в Параметры → Система → О Программе:
Дальше мы должны проверить сетевую связность с DC и его указание в качестве DNS-сервера.
Для этого открываем CMD или Powershell и выполняем команду:
ipconfig /all
Теперь смотрим:
И тут мы видим что пункт В настройках DNS-сервера на компьютере указан DC выполнен, а вот с нахождением в одной и той же сети с DC имеется проблема (у вас ее может не быть).
На интерфейсе установлен адрес 169.254.161.175, который принадлежит пулу 169.254.0.1 — 169.254.255.254. Это говорит нам о том что сработал APIPA (Automatic Private IP Addressing).
Этот механизм реализован с помощью протокола ARP (Address Resolution Protocol) и работает следующим образом:
- Если устройство, например компьютер или маршрутизатор, не может получить IP-адрес через DHCP после нескольких попыток, оно автоматически настраивает свой IP-адрес в диапазоне 169.254.0.1 — 169.254.255.254.
- Устройство также устанавливает свою подсеть как 255.255.0.0, что позволяет ему общаться с другими устройствами, имеющими адреса в этом диапазоне, без необходимости настройки внешнего DHCP-сервера.
Такой подход позволяет устройствам в локальной сети обмениваться данными даже в отсутствие централизованного управления IP-адресами и может быть полезен для диагностики и устранения неполадок в сетях.
Скорее всего возникла неполадка с DHCP-сервером, давайте на него вглянем:
Значок стал обозначающий работоспособность сервера стал красным, это говорит нам о том, что DHCP-сервер не авторизован.
До того как DHCP-сервер сможет назначать IP-адреса, он должен быть авторизован в службе каталогов Active Directory.
Авторизация выполняется в целях безопасности, чтобы в сети работали только авторизованные DHCP-серверы.
Эта проблема возникла из-за того, что мы сначала настроили DHCP, а уже потом установили домен, который и запретил нашему DHCP-серверу работать без авторизации.
Чтобы исправить это недоразумение кликните ПКМ на название нашего сервера и выберите Авторизовать:
Обновите это меню (с помощью специальной кнопки или опции), чтобы убедится что сервер заработал.
Затем проверьте WCLI, скорее всего он уже получил адрес с DHCP-сервера (если этого не произошло выключите и включите сетевой интерфейс на WCLI):
Осталось сравнить время на WCLI и DC, но с этим я думаю вы и сами справитесь (скриншоты приложите в отчете)
Если у вас будет сильно отличаться время, настройте их на использование NTP-сервера (тык)
Теперь когда мы проверили, что все верно, самое время приступить к вводу клиента в домен
¶ Ввод в домен
На WCLI откройте Проводник → Этот компьютер и нажмите ПКМ на пустое пространство → Свойства
Затем нажмите на пункт Изменить параметры → Изменить и укажите имя домена в который будете вводить WCLI, в нашем случае это ssa.local
После этого шага наш Компьютер обратится к DNS-серверу и там будет искать служебные записи указывающие на домен и DC, как только он их найдет будут запрошены данные для авторизации на DC (нужно ввести данные пользователя, имеющего права администратора)
После успешного введения в домен компьютер нужно перезагрузить.
¶ Проверка рабочей станции и работа с подразделениями
Для начала зайдите на WCLI под учетной запись ukrtb, которую мы создали на прошлой практической работе, если у вас получилось, то вы все сделали правильно.
На DC откройте Active Directory Пользователи и компьютеры, как видим WCLI появился в подразделении Computers, куда попадают все клиентские устройства введённые в домен
Давайте создадим для него отдельное подразделение, к примеру, SSA → BUH (бухгалтерия) и в нем еще одно - Computers, это в будущем поможет проще накладывать политики на узлы. После чего перетащите мышкой WCLI в подразделение SSA → BUH → Computers.
И на последок, создайте в подразделение SSA → BUH → users, а в нем пользователя Bokumenko.A с паролем P@ssw0rd, это будет наш бухгалтер
После чего авторизуйте под этим пользователем на WCLI и приложите скриншот в отчет.
¶ Контрольные вопросы
- Что-нибудь спрошу
- Что-нибудь спрошу
- Что-нибудь спрошу
- Что-нибудь спрошу
- Что-нибудь спрошу