Блог Виталия Лещенко
Виталий Лещенко

Windows Server для самых маленьких. Часть 15: Управляем серверами с рабочей станции

Все части серии «Windows Server для самых маленьких»

Серверы в этой серии — Server Core, и на них нет ничего, кроме консоли. Многое из того, что мы делали в прошлых частях, выполнялось с рабочей станции ws1: модуль ActiveDirectory, Get-DnsServerZone, Install-WindowsFeature -ComputerName, Invoke-Command. В прошлой части мы разобрали WinRM — транспорт для части этих команд. Теперь соберём рабочее место целиком: откуда на рабочей станции берутся модули ролей, по каким протоколам каждый из них ходит на сервер, что делать, когда модуля нет, и как не превратить рабочую станцию администратора в самое слабое место домена.

RSAT

Remote Server Administration Tools — те же инструменты управления, что ставятся на сервер вместе с ролью (-IncludeManagementTools), но для Windows 10 и 11: модули PowerShell, оснастки MMC и утилиты командной строки. С Windows 10 1809 это не отдельный установщик, а компоненты по требованию (Features on Demand): пакеты, которые Windows скачивает с Windows Update, когда их просят. Список и установка требуют консоли администратора — без повышенных прав Get-WindowsCapability отвечает «The requested operation requires elevation.». Так выглядит список на Windows 11 24H2 до установки:

PS C:\> Get-WindowsCapability -Online -Name 'Rsat.*' | Select-Object Name, State

Name                                                          State
----                                                          -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0             NotPresent
Rsat.AzureStack.HCI.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0                 NotPresent
Rsat.CertificateServices.Tools~~~~0.0.1.0                NotPresent
Rsat.DHCP.Tools~~~~0.0.1.0                               NotPresent
Rsat.Dns.Tools~~~~0.0.1.0                                NotPresent
Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0         NotPresent
Rsat.FileServices.Tools~~~~0.0.1.0                       NotPresent
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0             NotPresent
Rsat.IPAM.Client.Tools~~~~0.0.1.0                        NotPresent
Rsat.NetworkController.Tools~~~~0.0.1.0                  NotPresent
Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0               NotPresent
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0            NotPresent
Rsat.ServerManager.Tools~~~~0.0.1.0                      NotPresent
Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 NotPresent
Rsat.StorageReplica.Tools~~~~0.0.1.0                     NotPresent
Rsat.SystemInsights.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.VolumeActivation.Tools~~~~0.0.1.0                   NotPresent
Rsat.WSUS.Tools~~~~0.0.1.0                               NotPresent

PS C:\> Get-WindowsCapability -Online -Name 'Rsat.*' | Where-Object State -eq NotPresent | Add-WindowsCapability -Online

Состав списка зависит от версии Windows: в документации есть ещё Rsat.LLDP.Tools, Rsat.RemoteDesktop.Services.Tools и Rsat.Shielded.VM.Tools, которых в 24H2 нет. Последняя строка ставит всё; для этой серии достаточно шести: ActiveDirectory.DS-LDS, Dns, DHCP, GroupPolicy.Management, позже CertificateServices и ServerManager (его AD-инструменты всё равно притянут как зависимость). Одна ловушка: в сети с WSUS компоненты по требованию по умолчанию ищутся на WSUS, где их нет, и установка падает с 0x800f0954. Лечится политикой «Specify settings for optional component installation and component repair» (Computer Configuration → Administrative Templates → System) с флажком «Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS)».

Что приносят компоненты: модули PowerShell (ActiveDirectory, DnsServer, DhcpServer, GroupPolicy), оснастки (dsa.msc, dssite.msc, domain.msc, adsiedit.msc, dnsmgmt.msc, dhcpmgmt.msc, gpmc.msc, а от CertificateServices — certsrv.msc, certtmpl.msc и pkiview.msc, модуля PowerShell у него нет) и утилиты (repadmin, dcdiag, ntdsutil, dsacls, netdom, ldp, dnscmd). Проверить, что появилось, в PowerShell 7 — с одной оговоркой:

PS C:\> Get-Module -ListAvailable ActiveDirectory, DnsServer, DhcpServer, GroupPolicy | Select-Object Name, Version

Name            Version
----            -------
ActiveDirectory 1.0.1.0
DnsServer       2.0.0.0

PS C:\> Get-Module -ListAvailable DhcpServer, GroupPolicy -SkipEditionCheck | Select-Object Name, Version, CompatiblePSEditions

Name        Version CompatiblePSEditions
----        ------- --------------------
DhcpServer  2.0.0.0 {}
GroupPolicy 1.0.0.0 {}

Модули лежат в каталоге Windows PowerShell 5.1, и PowerShell 7 показывает оттуда только те, что объявили совместимость с ним (CompatiblePSEditions с Core). DhcpServer и GroupPolicy этого не объявили, поэтому Import-Module DhcpServer загружает модуль не в PowerShell 7, а через слой совместимости — об этом в разделе про неявный remoting. Если модуль на деле работает и в PowerShell 7, его можно загрузить напрямую: Import-Module DhcpServer -SkipEditionCheck; с DhcpServer и GroupPolicy это работает.

Версия RSAT должна соответствовать версии управляемых серверов, и номер версии модуля тут не помогает: DnsServer и в Windows Server 2019, и в 2025 — 2.0.0.0, но в 2025 в нём на две команды больше (Get- и Set-DnsServerEncryptionProtocol, DNS поверх HTTPS). Модуль из старой Windows не знает команд и параметров новой, а новая команда, отправленная на старый сервер, упирается в его провайдер:

PS C:\> Get-DnsServerEncryptionProtocol -CimSession dns2019     # сервер DNS на Windows Server 2019
Get-DnsServerEncryptionProtocol: The WS-Management service cannot process the request. The class PS_DnsServerEncryptionProtocol does not exist in the root/microsoft/windows/dns namespace.

Если рабочая станция — Windows Server, то же самое ставится как компоненты: Install-WindowsFeature RSAT-AD-Tools, RSAT-DNS-Server, RSAT-DHCP, GPMC.

Транспорты

У модулей RSAT несколько разных способов добраться до сервера, и знать их нужно, чтобы понимать, какой порт открыть и почему одна команда работает, а соседняя нет.

Собственный протокол. Модуль ActiveDirectory ходит на ADWS, порт 9389 (часть 13). Модуль GroupPolicy — по LDAP на контроллер и по SMB в SYSVOL, с параметром -Server или -Domain. Это модули, которые знают, с чем работают, и транспорт у них зашит.

CIM через WinRM. Модули DnsServer, DhcpServer, Storage, NetTCPIP, NetAdapter, NetSecurity, SmbShare, ScheduledTasks, PrintManagement, Defender и ещё несколько десятков устроены одинаково: их команды — это функции, сгенерированные из CDXML (cmdlet definition XML), обёртки над классами WMI. Параметр -CimSession у всех общий: он принимает готовый сеанс CIM или имя компьютера, и тогда сеанс создаётся на один вызов; транспорт до удалённого сервера — WinRM с операциями WS-Management над CIM:

PS C:\> Get-Command Get-DnsServerZone | Select-Object CommandType, Source, Version

CommandType Source    Version
----------- ------    -------
   Function DnsServer 2.0.0.0

PS C:\> Get-ChildItem C:\Windows\System32\WindowsPowerShell\v1.0\Modules\DnsServer\*.cdxml | Select-Object -First 3 Name

Name
----
PS_DnsServer_v1.0.0.cdxml
PS_DnsServerCache_v1.0.0.cdxml
PS_DnsServerClientSubnet_v1.0.0.cdxml

PS C:\> Get-CimClass -Namespace root/Microsoft/Windows/DNS -ClassName PS_DnsServerZone -ComputerName dc1 | Select-Object -ExpandProperty CimClassMethods | Select-Object -First 4 Name

Name
----
Export
Get
Remove
Resume

В модуле DnsServer 51 файл CDXML и 133 функции. Get-DnsServerZone -CimSession dc1 — это вызов статического метода Get класса PS_DnsServerZone в пространстве имён root/Microsoft/Windows/DNS на dc1 через WinRM; всего у класса шесть методов (ещё Suspend и Sync), и каждой функции соответствует свой: Suspend-DnsServerZone — Suspend, Remove-DnsServerZone — Remove. Создание зоны — уже другой класс, PS_DnsServerPrimaryZone. Один сеанс на несколько команд и серверов экономит время на установку соединения:

PS C:\> Import-Module DhcpServer -SkipEditionCheck
PS C:\> $cim = New-CimSession -ComputerName dc1, dc2
PS C:\> Get-DnsServerZone -CimSession $cim | Where-Object IsDsIntegrated | Format-Table ZoneName, PSComputerName

ZoneName                PSComputerName
--------                --------------
_msdcs.corp.example.com dc1
1.168.192.in-addr.arpa  dc1
corp.example.com        dc1
_msdcs.corp.example.com dc2
1.168.192.in-addr.arpa  dc2
corp.example.com        dc2

PS C:\> Get-DhcpServerv4ScopeStatistics -CimSession $cim | Format-Table ScopeId, InUse, Free, PSComputerName

ScopeId     InUse Free PSComputerName
-------     ----- ---- --------------
192.168.1.0    29  152 dc1
192.168.1.0    27  154 dc2

PS C:\> Get-CimInstance Win32_OperatingSystem -CimSession $cim | Format-Table CSName, LastBootUpTime, FreePhysicalMemory

CSName LastBootUpTime      FreePhysicalMemory
------ --------------      ------------------
DC1    26.10.2026 13:40:44            1539176
DC2    25.10.2026 11:47:59            2626256

PS C:\> Remove-CimSession $cim

Одна и та же область на обоих серверах — пара отказоустойчивости из части 8. Import-Module ... -SkipEditionCheck в первой строке не случаен: без него DhcpServer загрузится через слой совместимости, и сеанс CIM из PowerShell 7 туда не передать — команда ответит «Cannot convert the "CimSession: dc1" value of type "Deserialized.Microsoft.Management.Infrastructure.CimSession" to type "Microsoft.Management.Infrastructure.CimSession"». Get-CimInstance — то же самое для любого класса WMI, и это замена Get-WmiObject из Windows PowerShell 5.1, который ходил по DCOM и которого в PowerShell 7 нет. Для серверов без WinRM у New-CimSession есть -SessionOption (New-CimSessionOption -Protocol Dcom), но это уже RPC со всеми его портами.

-ComputerName у DnsServer и DhcpServer — не WinRM. У команд этих двух модулей есть и -ComputerName, и по названию кажется, что это тот же сеанс на один вызов. Но это обычный параметр метода, который передаётся провайдеру: команда вызывает локальный класс PS_DnsServerZone, а его провайдер, поставленный вместе с RSAT, сам обращается к службе DNS на dc1 по RPC — по протоколу MS-DNSP, тому же, что и оснастка DNS Manager; у DhcpServer так же работает MS-DHCPM. Разницу видно по PSComputerName:

PS C:\> Get-CimClass -Namespace root/Microsoft/Windows/DNS -ClassName PS_DnsServerZone | Select-Object CimClassName, @{n='Provider'; e={$_.CimClassQualifiers['provider'].Value}}

CimClassName     Provider
------------     --------
PS_DnsServerZone DnsServerPSProvider

PS C:\> Get-DnsServerZone -ComputerName dc1 -Name corp.example.com | Select-Object ZoneName, ZoneType, IsDsIntegrated, PSComputerName

ZoneName         ZoneType IsDsIntegrated PSComputerName
--------         -------- -------------- --------------
corp.example.com Primary            True

PS C:\> Get-DnsServerZone -CimSession dc1 -Name corp.example.com | Select-Object ZoneName, ZoneType, IsDsIntegrated, PSComputerName

ZoneName         ZoneType IsDsIntegrated PSComputerName
--------         -------- -------------- --------------
corp.example.com Primary            True dc1

Результат одинаковый, а путь разный: с -ComputerName команда выполнилась на рабочей станции, в процессе WmiPrvSE.exe, и соединения с dc1 открыл он — к порту 135 и к динамическому порту службы DNS (это видно в «Смотрим руками» ниже). Поэтому -ComputerName работает без WinRM на сервере, но требует правил файрвола «DNS Service» и «DHCP Server Management», которые роль включает при установке.

RPC и DCOM. Командлеты Windows PowerShell 5.1 с -ComputerName — Get-Service, Get-Process, Get-EventLog — в PowerShell 7 этого параметра не имеют («A parameter cannot be found that matches parameter name 'ComputerName'.»). Из оставшихся по RPC ходят Get-WinEvent -ComputerName, сеансы CIM по DCOM, -ComputerName модулей DNS и DHCP и большинство оснасток MMC: Endpoint Mapper на 135 и динамический порт из части 3. На файрволе сервера для них нужны группы правил, большинство которых по умолчанию выключено, и без них ответ один:

PS C:\> Get-WinEvent -ComputerName dc1 -LogName System -MaxEvents 1
Get-WinEvent: The RPC server is unavailable.

PS C:\> Invoke-Command dc1, dc2 { Enable-NetFirewallRule -DisplayGroup 'Remote Event Log Management', 'Remote Service Management', 'Remote Scheduled Tasks Management', 'Windows Management Instrumentation (WMI)', 'Remote Volume Management' }

На контроллерах домена группа «Windows Management Instrumentation (WMI)» уже включена, на рядовых серверах — нет; остальные четыре выключены везде. Какая оснастка по чему ходит:

Оснастка Транспорт Правило файрвола на сервере
Active Directory Users and Computers, Sites and Services, ADSI Edit LDAP 389/3268, для части операций RPC (SAMR) открыты на контроллере всегда
DNS Manager RPC к службе DNS (MS-DNSP: 135 и динамический порт) «DNS Service» — включено при установке роли
DHCP Manager RPC к службе DHCP (MS-DHCPM) «DHCP Server Management» — включено при установке роли
Group Policy Management LDAP и SMB (445) открыты на контроллере
Event Viewer, Services, Task Scheduler, Computer Management RPC к каждой службе отдельно группы «Remote … Management» — выключены
Disk Management RPC к службе Virtual Disk «Remote Volume Management» — выключено, и включать его нужно и на сервере, и на рабочей станции
Server Manager WinRM «Windows Remote Management» — включено

Поэтому Enter-PSSession dc1 работает на свежем сервере, а Event Viewer с подключением к dc1 — нет: разные протоколы, разные правила. В сети с файрволом между сегментом администраторов и серверами динамические порты RPC становятся отдельной задачей, которую WinRM на 5985 снимает целиком, — и это главный практический аргумент в пользу PowerShell с -CimSession и Invoke-Command перед оснастками.

Неявный remoting

Модуля нет на рабочей станции, или он старее серверного, или рабочая станция вообще не Windows. В части 14 был Invoke-Command, но писать каждую команду внутри блока неудобно. Неявный remoting импортирует команды из сеанса как локальные:

PS C:\> $s = New-PSSession -ComputerName dc1
PS C:\> Import-Module -PSSession $s -Name DhcpServer -Prefix DC1
PS C:\> Get-DC1DhcpServerv4Scope | Format-Table ScopeId, Name, State

ScopeId     Name   State
-------     ----   -----
192.168.1.0 Office Active

PS C:\> Get-Command Get-DC1DhcpServerv4Scope | Select-Object CommandType, Source

CommandType Source
----------- ------
   Function DhcpServer

PS C:\> (Get-Module DhcpServer).Path
C:\Users\alice.admin\AppData\Local\Temp\remoteIpMoProxy_DhcpServer_2.0.0.0_dc1_6f0c…\remoteIpMoProxy_DhcpServer_2.0.0.0_dc1_6f0c….psm1

На рабочей станции появился модуль-заместитель с тем же именем, сгенерированный во временной папке, а в нём — функции с префиксом DC1: вызов Get-DC1DhcpServerv4Scope выполняет Get-DhcpServerv4Scope в сеансе на dc1 и возвращает результат. Автодополнение и справка работают, объекты приходят сериализованными (экземпляры CIM PowerShell восстанавливает как CIM, остальное — как Deserialized.* без методов). Без -Prefix функции получат родные имена и перекроют локальные, если они есть. Старшая форма того же — Import-PSSession -Session $s -Module DhcpServer, она называет модуль-заместитель tmp_<случайное имя>. Export-PSSession сохраняет заместителей на диск как обычный модуль, который при первом вызове сам откроет сеанс к dc1:

PS C:\> Export-PSSession -Session $s -Module DhcpServer -OutputModule DhcpFromDc1
PS C:\> Remove-PSSession $s

# в новом окне
PS C:\> Import-Module DhcpFromDc1 -Prefix DC1
PS C:\> Get-DC1DhcpServerv4Scope | Format-Table ScopeId, Name, State, PSComputerName
Creating a new session for implicit remoting of "Get-DhcpServerv4Scope" command...

ScopeId     Name   State  PSComputerName
-------     ----   -----  --------------
192.168.1.0 Office Active dc1

Это же решает проблему версий: модуль DhcpServer с контроллера на Windows Server 2025 через неявный remoting знает все команды и параметры 2025, какой бы RSAT ни стоял на рабочей станции. И это же способ управлять Windows-серверами с Linux или macOS из PowerShell 7 — через сеанс по SSH из следующей части.

Тем же механизмом PowerShell 7 загружает модули, которые не объявили совместимость с ним. Import-Module DhcpServer без -SkipEditionCheck поднимает локальный процесс Windows PowerShell 5.1 — сеанс WinPSCompatSession к localhost — и импортирует модуль оттуда:

PS C:\> Import-Module DhcpServer
WARNING: Module DhcpServer is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.

PS C:\> Get-PSSession | Format-Table Id, Name, ComputerName, State

Id Name               ComputerName  State
-- ----               ------------  -----
 2 WinPSCompatSession localhost    Opened

PS C:\> Get-DhcpServerv4ScopeStatistics -ComputerName dc1 | Format-Table ScopeId, InUse, Free, PSComputerName

ScopeId     InUse Free PSComputerName
-------     ----- ---- --------------
192.168.1.0    29  152 localhost

PSComputerName здесь — localhost: объект пришёл из процесса 5.1 на той же машине, а уже тот обратился к dc1. Так же загружается GroupPolicy, и так же PowerShell 7 находит Get-WmiObject, если его вызвать: команда работает, но через тот же слой и с теми же десериализованными объектами.

Windows Admin Center

Windows Admin Center (WAC) — веб-интерфейс к серверам: страница в браузере, за ней шлюз, который ходит на серверы по WinRM — PowerShell Remoting и WMI поверх WinRM. Ставится на сервер управления (wac.corp.example.com) или на рабочую станцию; на Windows Server слушает 443, на клиентской Windows — 6600 и только локально. Пользователей шлюза он проверяет через Windows (Active Directory или локальные группы) или через Microsoft Entra ID, облачный каталог Microsoft из последних частей серии, и показывает для каждого сервера: обзор с нагрузкой, события, службы, процессы, обновления, файрвол, роли, хранилище, сеть, сертификаты, планировщик, реестр, PowerShell-консоль в браузере; расширения — Active Directory, DNS, DHCP, Hyper-V, кластеры, Azure. Текущая версия ставится не MSI, а EXE-установщиком:

PS C:\> Start-BitsTransfer -Source https://aka.ms/WACdownload -Destination C:\Temp\WindowsAdminCenter.exe
PS C:\> Start-Process -FilePath C:\Temp\WindowsAdminCenter.exe -ArgumentList '/VERYSILENT' -Wait

Без своего сертификата (/CertificateThumbprint= с отпечатком из LocalMachine\My) установщик выпускает самоподписанный на 60 дней — для проверки, не для работы. У шлюза на сервере есть знакомая из части 14 особенность: он подключается к серверам от имени пользователя, то есть делает второй прыжок, и для единого входа без повторного ввода пароля каждому управляемому серверу нужно разрешить делегирование на основе ресурса для учётной записи компьютера шлюза — так предписывает документация WAC; делегирование здесь выполняет сам шлюз, а не сеанс PowerShell на промежуточном сервере, как в части 14:

PS C:\> Set-ADComputer -Identity (Get-ADComputer srv1) -PrincipalsAllowedToDelegateToAccount (Get-ADComputer wac)

Для этой серии он ценен одной кнопкой: в каждом инструменте WAC на панели есть значок PowerShell, который показывает скрипты, стоящие за действиями на этой странице. Так из любого действия в UI можно получить команду для скрипта. Мы будем на него ссылаться, но не опираться: всё, что он делает, делается командами, которые он же и показывает.

Рабочая станция администратора

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

Отдельная учётная запись. alice читает почту и ходит в браузер; alice.admin из части 4 не делает ни того, ни другого. На рабочей станции она используется только для запуска инструментов:

PS C:\> runas /user:CORP\alice.admin pwsh
PS C:\> Start-Process pwsh -Credential (Get-Credential CORP\alice.admin)
PS C:\> runas /netonly /user:CORP\alice.admin "mmc dsa.msc"     # /netonly: локально под текущим, к сети — под alice.admin

Программа с аргументами берётся в кавычки целиком, иначе runas примет dsa.msc за лишний параметр.

Куда попадает пароль. Каждый интерактивный вход — RDP, runas без /netonly — оставляет в памяти lsass целевой машины учётные данные, которые можно извлечь. Правило: административные учётные данные вводятся только на машинах того же уровня доверия. Контроллер доверен — на него можно входить по RDP; сервер с веб-приложением, который ломают через уязвимость в этом приложении, — нет. Для RDP на такие серверы есть Remote Credential Guard (mstsc /remoteGuard /v:srv1): учётные данные остаются на рабочей станции, запросы Kerberos сервер пересылает обратно на неё по мере надобности, и в его памяти ни пароля, ни ключей нет; работает только по Kerberos, без отката на NTLM. Более ранний вариант — Restricted Admin (mstsc /restrictedAdmin /v:srv1): вход без передачи учётных данных вовсе, только для членов локальной группы Administrators на сервере, и с сервера дальше по сети идёт уже его учётная запись компьютера, а не ваша — тот же второй прыжок. Оба режима сервер должен разрешить: политика «Remote host allows delegation of nonexportable credentials» (параметр DisableRestrictedAdmin = 0 в HKLM\SYSTEM\CurrentControlSet\Control\Lsa).

Protected Users. Встроенная группа домена, членам которой контроллеры запрещают всё, что делает учётные данные уязвимыми: NTLM, DES и RC4 в Kerberos, делегирование любого вида, TGT дольше четырёх часов, а рабочие станции не кешируют их пароль и NT-хеш и не дают войти без сети. Административные учётные записи кладут в неё, предварительно проверив по событиям 4776 и 4769 из части 6, что они не пользуются NTLM и RC4 (и что у них есть ключи AES — пароль менялся после перехода домена на 2008); учётные записи служб и компьютеров туда не кладут:

PS C:\> Add-ADGroupMember -Identity 'Protected Users' -Members alice.admin

Разделение уровней. В модели, которую Microsoft называла tiering, а теперь — enterprise access model, учётные записи и машины делятся на уровни: 0 — контроллеры, PKI, системы управления идентичностью и те, кто ими управляет; 1 — серверы и приложения; 2 — рабочие станции и пользователи. Учётная запись уровня 0 не входит на машины уровней 1 и 2, и наоборот. Рабочая станция администратора уровня 0 (PAW, privileged access workstation) — отдельная машина или отдельная виртуальная машина с минимумом софта, без почты и браузера, которой владеет только администратор. Для домена из трёх контроллеров это звучит избыточно; для домена, который взломали через ноутбук администратора, — единственное, что помогло бы.

LAPS. Локальный администратор на каждом сервере и рабочей станции с одинаковым паролем — вторая по частоте причина распространения атаки по сети. Windows LAPS (встроен в Windows с обновлений апреля 2023 года) меняет пароль локального администратора на каждой машине на случайный и хранит его в атрибуте учётной записи компьютера в каталоге — msLAPS-Password или, зашифрованным, msLAPS-EncryptedPassword; оба в списке атрибутов, которые RODC из части 11 не получает. Включается расширением схемы (Update-LapsADSchema), правом компьютеров писать свой атрибут (Set-LapsADComputerSelfPermission) и групповой политикой, а читается Get-LapsADPassword ws1 -AsPlainText тем, кому делегировано право.

Смотрим руками

Все транспорты сразу. Четыре команды с рабочей станции, а затем список установленных соединений с dc1 и процессов, которым они принадлежат:

PS C:\> $dc1 = (Resolve-DnsName dc1.corp.example.com).IPAddress
PS C:\> Get-ADUser alice -Server dc1 | Out-Null                    # ADWS
PS C:\> Get-DnsServerZone -CimSession dc1 | Out-Null               # CIM через WinRM
PS C:\> Get-DnsServerZone -ComputerName dc1 | Out-Null             # RPC из локального провайдера
PS C:\> $dcom = New-CimSession dc1 -SessionOption (New-CimSessionOption -Protocol Dcom)
PS C:\> Get-CimInstance Win32_Service -Filter "Name='DNS'" -CimSession $dcom | Out-Null    # DCOM
PS C:\> Get-NetTCPConnection -RemoteAddress $dc1 -State Established | Sort-Object RemotePort | Format-Table RemotePort, OwningProcess, @{n='Process'; e={(Get-Process -Id $_.OwningProcess).Name}}

RemotePort OwningProcess Process
---------- ------------- -------
       135          1236 svchost
       135          1236 svchost
       135          3412 WmiPrvSE
      9389          5124 pwsh
      9389          5124 pwsh
     49671          3412 WmiPrvSE
     49673          5124 pwsh

-RemoteAddress берёт все адреса dc1: в сети с IPv6 соединения идут по 2001:db8:1::10, и фильтр по одному 192.168.1.10 ничего бы не нашёл. Читаем по строкам:

  • два соединения pwsh с 9389 — ADWS; модуль ActiveDirectory держит их открытыми для следующих команд;
  • соединения с 5985 уже нет: -CimSession dc1 с именем вместо сеанса создал сеанс CIM на один вызов и закрыл его;
  • WmiPrvSE с 135 и с 49671 — это Get-DnsServerZone -ComputerName: локальный провайдер спросил у Endpoint Mapper порт службы DNS и подключился к нему (на сервере Get-NetTCPConnection -LocalPort 49671 -State Listen покажет процесс dns);
  • pwsh с 49673 — DCOM к службе Winmgmt на dc1, а два соединения svchost с 135 — это локальная служба RpcSs, через которую DCOM находит объект на сервере.

Кто хочет увидеть то же на уровне пакетов — pktmon start --capture, команды, pktmon stop и pktmon etl2pcap для Wireshark (захват требует прав администратора на рабочей станции). Оснастка ведёт себя как третья строка: dnsmgmt.msc с подключением к dc1 — те же 135 и динамический порт службы DNS, внутри — вызовы MS-DNSP вроде R_DnssrvQuery2. Если на файрволе между рабочей станцией и сервером открыт только 5985, оснастка и Get-DnsServerZone -ComputerName dc1 не подключатся, а Get-DnsServerZone -CimSession dc1 будет работать.

И проверка, что рабочая станция не держит того, чего не должна. В окне, открытом runas /netonly, whoami показывает corp\alice — локально процесс работает под ней, а klist после первого обращения к серверу — билеты alice.admin: у такого сеанса входа тип 9, NewCredentials, и его учётные данные используются только для сети. Кто в группе:

PS C:\> Get-ADGroupMember 'Protected Users' | Select-Object Name

Name
----
Alice Admin

На сервере, куда alice.admin подключалась через Invoke-Command, её учётных данных нет — WinRM с Kerberos их туда не передаёт (часть 14).

Источники

С рабочей станции Windows к серверам Windows дорога построена. Но у серверов есть ещё одна дверь, которой уже двадцать лет пользуются администраторы Linux, и с 2018 года она есть и в Windows Server — вместе с возможностью сделать PowerShell тем, что открывается за ней.

Дальше — часть 16: SSH на Windows Server. OpenSSH Server как компонент, sshd_config и отличия от Linux, ключи и файл administrators_authorized_keys, PowerShell как оболочка по умолчанию, вход по Kerberos через GSSAPI, PowerShell Remoting поверх SSH вместо WinRM — в том числе с Linux и macOS, и почему встроенный клиент Windows и клиент из Git for Windows ведут себя по-разному.

Оставить комментарий могут только зарегистрированные пользователи.

Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.

© 2006-2026 Виталий Лещенко