Как добавить Windows 10 в домен и выдать права локального администратора через GPO

Я создал в Proxmox VE виртуальную машину с Windows 10 Enterprise LTSC, подключил её к домену на Windows Server 2016 и начал настраивать доступ. Вступление в домен прошло успешно, но при изменении системных параметров Windows попросила имя и пароль администратора.

Так я на практике разобрался с несколькими разными вещами: учётной записью компьютера в AD, его расположением в OU, локальными правами пользователя и применением групповых политик. Сначала выдал права вручную, затем настроил управление через доменную группу и GPO. Здесь собрал весь порядок действий, включая проверки, которые помогли разобраться с ошибками.

Что я настраиваю​

В моём случае Windows Server 2016 уже работает контроллером домена, роли AD DS и DNS настроены. На виртуальной машине установлена Windows 10 Enterprise LTSC. Руководство начинается с этого состояния; создание домена с нуля и установка Windows в PVE сюда не входят.

Для публикации я заменил внутренние имена на примеры. Во всех командах ниже использую одну схему:


Имена DC1 и DC2 здесь условные. При повторении я подставляю реальные имена серверов, домен, адреса DNS и имя своей машины. Команды выполняю в указанной оболочке, без приглашения вида PS C:\Windows\system32> и без добавления обратной косой черты в конце строк.

Моя задача — дать пользователю административные права на одной конкретной Windows 10. Для этого не требуется включать его в «Администраторы домена». Описанный способ также подходит для обычного сервера — члена домена. На контроллере домена обычной локальной базы пользователей нет, поэтому эту схему на DC я не применяю.

1. Готовлю сеть и Windows 10​

Сначала проверяю, что виртуальная машина имеет сетевой доступ к контроллерам домена. В PVE её сетевой адаптер должен быть подключён к подходящему мосту и, если используются VLAN, к нужной сети. Доступ к интернету сам по себе ещё не подтверждает доступность AD.

На клиенте открываю через Win + R:


Перехожу в свойства сетевого адаптера → «IP версии 4 (TCP/IPv4)» и проверяю DNS. В моём примере это 192.168.10.10 и 192.168.10.11. Если правильные адреса уже выдаёт DHCP, вручную ничего не меняю. Адрес клиента, шлюз и маску оставляю соответствующими своей сети.

Для доменного клиента использую DNS, который умеет разрешать служебные записи AD. В обычной конфигурации это DNS на контроллерах домена. Публичный DNS не добавляю как «запасной»: внешние имена разрешаются через внутреннюю DNS-инфраструктуру и её перенаправители.

На клиенте в CMD проверяю:


В ответе на второй запрос ожидаю записи контроллеров моего домена. Если их нет, сначала разбираюсь с DNS.

Также проверяю дату и время и убеждаюсь, что у меня есть рабочая локальная административная учётная запись. Windows 10 Enterprise LTSC поддерживает вступление в домен; редакция Home для этого не подходит.

2. Подготавливаю пользователя и присоединяю компьютер​

На сервере открываю «Active Directory — пользователи и компьютеры»:


Если нужного пользователя ещё нет, в предназначенной для пользователей OU выбираю «Создать → Пользователь», задаю логин testuser и начальный пароль. При необходимости включаю требование сменить пароль при следующем входе. Уже существующую учётную запись повторно не создаю.

На Windows 10 вхожу под локальным администратором и открываю:


На вкладке «Имя компьютера» нажимаю «Изменить», задаю имя VM-WIN10-01 и перезагружаю Windows. Для понятной последовательности переименование и вступление в домен я выполняю отдельно.

После перезагрузки:

1. Снова открываю sysdm.cpl → «Имя компьютера → Изменить».
2. В разделе членства выбираю «Домен» и ввожу corp.example.ru.
3. Указываю доменную учётную запись, которой разрешено присоединять компьютеры.
4. После сообщения о вступлении в домен перезагружаю Windows.
5. На экране входа выбираю «Другой пользователь» и вхожу как CORP\testuser.

Для первого входа доменного пользователя компьютер должен иметь доступ к контроллеру домена. Windows создаст отдельный профиль: прежний локальный профиль автоматически не станет доменным. Для входа под локальной учёткой использую запись вида .\localadmin, подставляя её настоящее имя.

Этот порядок соответствует инструкции Microsoft по присоединению компьютера к домену.

3. Размещаю объект компьютера в правильной OU​

Заранее создавать объект компьютера в AD необязательно: при вступлении в домен он может создаться автоматически, если у присоединяющей учётки достаточно прав. Обычно он появляется в контейнере Computers, но в домене это расположение по умолчанию могло быть изменено.

В dsa.msc нахожу VM-WIN10-01, нажимаю правой кнопкой → «Переместить» и выбираю предусмотренное для него подразделение:


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

Если я предпочитаю предварительное создание, делаю это через «Создать → Компьютер» сразу в нужной OU и указываю точное имя будущего ПК. При повторном использовании существующего объекта учитываю права и проверки владельца, описанные в KB5020276. Сброс существующей учётной записи компьютера не использую как универсальное исправление.

OU и группа безопасности выполняют разные задачи. Перемещение компьютера в OU определяет, какие связанные с ней GPO могут на него действовать. Добавление пользователя в группу управляет его доступом. Саму группу локальных администраторов дальше я храню в Access → Local_Admins,


а объект компьютера — в Workstations → WIN_GPO.

4. Проверяю результат вступления в домен​

На клиенте открываю PowerShell и выполняю:


Ожидаю:


В обычной CMD пользователя проверяю его фактическую учётную запись:


Ожидаемый результат — corp\testuser. Если есть сомнения в доверии компьютера к домену, на клиенте в PowerShell от администратора выполняю:


Для исправного защищённого канала ожидаю True. Это дополнительная проверка связи с доменом, а не проверка локальных административных прав пользователя.

5. Разбираюсь, почему появляется UAC​

После вступления в домен я столкнулся с запросом логина и пароля администратора. Здесь оказалось важно проверить, под какой учёткой выполнен вход и какие права у неё есть на этой машине.

Ввод административных данных при присоединении компьютера разрешает эту операцию. Он не означает, что любой пользователь, который затем войдёт в Windows, автоматически получит локальные административные права.

В обычной CMD текущего пользователя выполняю:


Первая команда показывает учётку. Вторая — непосредственных участников локальной группы «Администраторы»: вложенные доменные группы она не разворачивает. Третья проверяет наличие SID группы администраторов в текущем токене, то есть в наборе прав уже открытого сеанса.

Если последняя команда ничего не выводит, этот сеанс не содержит SID локальных администраторов. Если SID есть с пометкой «Только для отказа», это ожидаемо для ограниченного токена администратора при включённом UAC: для административной операции всё равно потребуется повышение.

Само окно ввода пароля ещё не доказывает, что пользователь не администратор. Доменная политика может требовать учётные данные и у администратора. Это описано в документации Microsoft об UAC.

6. Выдаю права вручную на одной машине​

Для разовой настройки на самой VM-WIN10-01 запускаю CMD от имени администратора. Если UAC просит учётные данные, использую учётку, которая уже имеет административные права на этой машине. Имя Administrator не обязательно: встроенная учётная запись может быть переименована или отключена.

Выполняю:


Проверяю:


На англоязычной Windows название группы будет Administrators. Если нужно выбрать группу независимо от языка, в 64-разрядной Windows PowerShell от администратора использую альтернативу:


После добавления полностью выхожу из пользовательского сеанса и вхожу заново. Простое закрытие RDP-окна оставляет сеанс работающим. Обновление политик тоже не пересоздаёт пользовательский токен.

Когда разовые права больше не нужны, в повышенной CMD удаляю это членство:


Учётная запись пользователя при этом остаётся. Затем снова завершаю его сеанс. Если права выдаются ещё и через доменную группу, удаление прямого членства их не отзовёт — нужно проверить все пути получения доступа.

7. Создаю доменную группу для конкретного ПК​

Для постоянного управления мне удобнее один раз добавить в локальные администраторы доменную группу, а затем управлять её участниками в AD.

В dsa.msc использую OU Access → Local_Admins. Если такой структуры нет, создаю её в принятом в организации месте через «Создать → Подразделение». Специального системного значения у названия Local_Admins нет.

Внутри создаю группу:



Открываю свойства группы → «Члены → Добавить», выбираю пользователя testuser и проверяю имя.

В эту группу включаю людей, которым нужны права, а не объект VM-WIN10-01. Само название группы пока ничего не назначает: далее я должен включить её в локальные «Администраторы» нужного компьютера.

Получается такая связь:


Для повседневной эксплуатации вместо основной учётки можно включать в группу отдельную административную учётную запись сотрудника.

8. Настраиваю GPO с привязкой к одному компьютеру​

На сервере открываю управление групповыми политиками:


Нахожу домен corp.example.ru и OU Workstations → WIN_GPO, в которой находится объект компьютера. Правой кнопкой по OU выбираю «Создать объект групповой политики в этом домене и связать его…».

Задаю имя:


Название политики служит мне подписью. Ограничение одним ПК я настраиваю отдельно.

Открываю «Изменить» и перехожу:


В разных локализациях названия разделов могут немного отличаться. В правой части выбираю «Создать → Локальная группа» и устанавливаю:

• Действие: Обновить.
• Имя группы: Администраторы — встроенная группа из выпадающего списка.
• Удалить всех пользователей — членов этой группы: выключено.
• Удалить все группы — члены этой группы: выключено.

В разделе «Члены группы» нажимаю «Добавить». Через поиск объектов AD выбираю созданную группу и проверяю, что выбрано именно доменное имя:


Для участника оставляю действие ADD. В этой конфигурации требуется добавить одного участника к существующему составу группы, поэтому использую «Обновить».

Теперь ограничиваю элемент конкретной машиной.

1. Открываю вкладку «Общие параметры».
2. Включаю «Нацеливание на уровень элемента» и нажимаю «Нацеливание».
   
   
3. Выбираю «Создать элемент → Имя компьютера».
4. Указываю VM-WIN10-01 и вариант «NetBIOS-имя».
5. Проверяю положительное условие: имя компьютера является VM-WIN10-01.
6. Подтверждаю изменения во всех открытых окнах.

Принцип нацеливания описан в справке Microsoft по Item-Level Targeting.

Нацеливание проверяется только после того, как компьютер попал в область действия GPO. Если его объект остался в Computers, условие с правильным именем не заставит политику из WIN_GPO примениться к нему.

В фильтре безопасности этой новой GPO оставляю стандартную запись «Прошедшие проверку» с правами чтения и применения. В таком варианте ограничение нужной машиной обеспечивает нацеливание элемента. Группу пользователей LocalAdmins вместо неё не подставляю: здесь обрабатываются настройки компьютера.

На вкладке общих параметров также оставляю выключенным «Применить один раз и не применять повторно». Если вся GPO содержит только настройки компьютера, её пользовательскую часть можно отключить, чтобы не обрабатывать пустой раздел. Такой подход описан среди способов оптимизации обработки GPO.

9. Проверяю, что права действительно появились​

На VM-WIN10-01 открываю CMD от имени уже действующего администратора и выполняю:


Проверяю три результата: имя машины совпадает с условием нацеливания, политика VM-WIN10-01 - Local Admins присутствует среди применённых, а в локальной группе появилась CORP\GG-VM-WIN10-01-LocalAdmins.

Если использую вход через эту группу, перед проверкой удаляю ранее выданное прямое членство CORP\testuser из локальных администраторов. Иначе ручное добавление может скрыть ошибку в новой схеме. При этом сохраняю доступ через другую рабочую административную учётку.

Затем полностью выхожу из Windows и вхожу как CORP\testuser при доступном контроллере домена. В обычной, неповышенной CMD этого пользователя выполняю:


Ожидаю нужное имя пользователя и SID локальных администраторов. Здесь я проверяю именно пользовательский сеанс: CMD, запущенная с данными другой административной учётки, покажет права той другой учётки.

UAC после выдачи прав продолжает работать. Если он требует пароль и я хочу проверить причину, смотрю действующую политику «Контроль учётных записей: поведение запроса на повышение прав для администраторов в режиме одобрения администратором». Сам факт такого запроса не считаю провалом GPO.

10. Что я проверяю, если GPO есть, а прав нет​

В моей настройке понадобилось внимательно проверить доменного участника, привязку GPO и имя целевого компьютера. Поэтому при повторении начинаю с короткой последовательности.

Компьютер находится в нужной OU?

На контроллере в PowerShell выполняю:


Для структуры из статьи ожидаю:


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

В GPO выбран нужный доменный объект?

В списке участников можно указывать и конкретного доменного пользователя, например CORP\testuser: группа не является техническим требованием. Я выбрал группу ради удобного управления доступом.

Короткое имя без домена и пустой SID — повод перепроверить выбор объекта, но сами по себе они не доказывают причину сбоя. Выбираю существующий объект через поиск AD. Членство в группе проверяю в её свойствах или на контроллере командой:


Политика действительно применяется на клиенте?

Если её нет в результатах gpresult, проверяю OU, включённую связь GPO, разрешения чтения и применения для компьютера, а также возможные фильтры. Само наличие GPO в консоли сервера не подтверждает применение на рабочей станции.

Если GPO есть среди применённых, но группы в локальных администраторах нет, проверяю сохранённое нацеливание и совпадение с hostname. При ошибке обработки открываю на клиенте eventvwr.msc → «Журналы Windows → Приложение» и ищу свежие события источника Group Policy Local Users and Groups, в частности 4098. Важны код ошибки, имя элемента и имя GPO. Справка Microsoft по событиям GPP.

Добавление не отменяет другая политика?

Если группа появляется, а позже исчезает, проверяю другие настройки локальных администраторов: элементы GPP с удалением участников и политики ограниченных групп. Не меняю порядок политик наугад — сначала смотрю, какая из них управляет составом группы.

Пользователь заново вошёл в Windows?

Если доменная группа уже добавлена локально, проверяю членство пользователя и полный выход из старого сеанса. Для проверки результата одного gpupdate недостаточно.

11. Если на DC1 и DC2 отображаются разные данные​

После перемещения компьютера или изменения описания сначала обновляю консоль клавишей F5 и проверяю, к какому контроллеру она подключена. Затем на сервере в PowerShell сравниваю объект напрямую:


Совпадающий ObjectGUID показывает, что сравнивается один объект. DistinguishedName указывает его расположение, Description — описание. Если поиск не возвращает результата, проверяю настоящее имя через hostname на клиенте; при необходимости ищу в AD по части имени.

Если данные действительно различаются, выполняю:


Ноль ошибок и успешные последние попытки — хороший признак, но не доказательство того, что нужное изменение уже видно везде. Показатель «Наибольшая дельта» отражает время с последней успешной репликации для соответствующих связей; это не время ожидания конкретного перемещения компьютера. Описание repadmin /replsummary.

Отдельно учитываю, что GPO хранит данные в AD и файлы в SYSVOL. Успешная проверка репликации AD не подтверждает синхронизацию файлов политики. Если проблема касается новой GPO, сравниваю её версии и проверяю состояние SYSVOL, а не делаю вывод только по repadmin. Устройство объекта групповой политики.

12. Как я отзываю выданные права​

Чтобы убрать доступ у одного человека, открываю в AD группу GG-VM-WIN10-01-LocalAdmins и удаляю пользователя из её членов. Сама группа остаётся в локальных администраторах компьютера для остальных разрешённых участников.

После репликации изменения пользователь должен полностью завершить сеанс и войти заново при доступном DC. Уже открытые процессы не теряют свой старый токен автоматически. Проверяю также, не выданы ли ему те же права напрямую или через другую группу.

Если требуется убрать с компьютера саму доменную группу, задаю в GPP явное удаление этого участника: у элемента локальной группы сохраняю действие «Обновить», а для нужного участника выбираю «Удалить из этой группы» — REMOVE. Прежнее ADD для того же участника заменяю. После применения проверяю локальную группу на клиенте.

Удаление строки из GPO или отключение её связи не равно отзыву уже выданных прав. Настройки предпочтений могут сохраняться после выхода из области действия политики. Поэтому я использую явное удаление участника и проверяю результат. Такое поведение объясняется в документации Group Policy Preferences.

Несколько вопросов, которые возникли по ходу настройки​

Можно ли назначить локального администратора в свойствах компьютера в AD?

Я не нашёл там отдельного поля с таким назначением, потому что состав локальных администраторов хранится на самой машине. Через AD я управляю членством доменной группы, а GPO добавляет её в локальную группу целевого ПК.

Можно ли одним именем группы ограничить доступ конкретным компьютером?

Нет. Имя GG-VM-WIN10-01-LocalAdmins помогает мне понимать назначение. Фактический доступ зависит от того, куда эта группа добавлена. Если включить её в локальные администраторы ещё одного компьютера, её участники получат права и там.

Нужно ли знать пароль пользователя для настройки?

Для изменения членства в группе и настройки GPO я использую свои административные полномочия. Пароль пользователя для этого не требуется. Когда проверяю его сеанс, пользователь входит самостоятельно.

А история паролей в AD позволяет посмотреть старый пароль?

Обычная история паролей хранит защищённые хеши для запрета повторного использования. Это не список читаемых паролей, и в ADUC нет кнопки их просмотра. LAPS — другой механизм: он может предоставлять уполномоченному администратору пароль управляемой локальной учётной записи. Как Windows хранит пароли; архитектура Windows LAPS.

После такой настройки мне достаточно управлять участниками выделенной AD-группы. К GPO возвращаюсь, когда меняется целевой компьютер или способ назначения прав. Для проверки результата смотрю состав локальных администраторов и новый сеанс пользователя — именно они показывают, что настройка сработала.