Ранее как-то я уже писал пост о проблеме c миграцией VM, с которой довелось столкнуться на свеже-установленном хосте Hyper-V на Windows Server 2012. Как я тогда предположил, корнем проблемы было поднятие роли Hyper-V до ввода в домен. Однако комментаторы меня заставили усомниться в этом предположении, более того, спустя некоторое время я заметил, что проблема регистрации SPN "всплыла" снова. То есть, даже не смотря на то, что нужные службе VMMS недостающие SPN для учетных записей проблемных хостов были прописаны в домене вручную, журнал Microsoft/Windows/Hyper-V-VMMS/Admin был переполнен регистрируемыми каждые 2 минуты десятками сотен однотипных ошибок:
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 10.01.2014 11:50:42
Event ID: 14050
Task Category: None
Level: Error
User: SYSTEM
Computer: KOM-AD01-VM08.holding.com
Description:
Failed to register the service principal name 'Hyper-V Replica Service'.
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 10.01.2014 11:50:42
Event ID: 14050
Task Category: None
Level: Error
User: SYSTEM
Computer: KOM-AD01-VM08.holding.com
Description:
Failed to register the service principal name 'Microsoft Virtual System Migration Service'.
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 10.01.2014 11:50:42
Event ID: 14050
Task Category: None
Level: Error
User: SYSTEM
Computer: KOM-AD01-VM08.holding.com
Description:
Failed to register the service principal name 'Microsoft Virtual Console Service'.
Поиски решения привели к статье KB2761899 - Hyper-V VMM service fails and Event ID 14050 is logged when dynamicportrange is changed in Windows Server 2012. Применительно к моей ситуации любопытной оказалась информация об одной из возможных причин:
This problem may also occur if the NTDS port has been restricted to a specific port on your domain controllers. If this selected NTDS port is not within the default ranges, you must add this port by running the script in the "Resolution" section on every Hyper-V host.
Тут же вспомнился тот факт, что ранее один из доменных администраторов, видимо руководствуясь статьёй KB224196 - Restricting Active Directory replication traffic and client RPC traffic to a specific port, применил ко всем контроллерам домена групповую политику в которой присутствовал скрипт изменения порта службы NTDS, в частности в параметрах реестра был добавлен статический порт:
reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v "TCP/IP Port" /t REG_DWORD /d 39100 /f
В качестве решения проблемы с регистрацией SPN службы VMMS на Windows Server 2012 (а как показывает практика и на Windows Server 2012 R2) в KB2761899 предлагается VB скрипт добавляющий разрешающее правило в механизм Windows Service Hardening.
В моём случае скрипт, который необходимо было выполнить на проблемном хосте Hyper-V, получился таким:
'This VBScript adds a port range from 9000 to 9999 for outgoing traffic
'run as cscript addportrange.vbs on the hyper-v host
option explicit
'IP protocols
const NET_FW_IP_PROTOCOL_TCP = 6
const NET_FW_IP_PROTOCOL_UDP = 17
'Action
const NET_FW_ACTION_BLOCK = 0
const NET_FW_ACTION_ALLOW = 1
'Direction
const NET_FW_RULE_DIR_IN = 1
const NET_FW_RULE_DIR_OUT = 2
'Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
'Get the Service Restriction object for the local firewall policy.
Dim ServiceRestriction
Set ServiceRestriction = fwPolicy2.ServiceRestriction
'If the service requires sending/receiving certain type of traffic, then add "allow" WSH rules as follows
'Get the collection of Windows Service Hardening networking rules
Dim wshRules
Set wshRules = ServiceRestriction.Rules
'Add outbound WSH allow rules
Dim NewOutboundRule
Set NewOutboundRule = CreateObject("HNetCfg.FWRule")
NewOutboundRule.Name = "Hyper-V - Allow outbound traffic from service to Static RPC port (TCP 39100)"
NewOutboundRule.ApplicationName = "%systemDrive%\WINDOWS\system32\vmms.exe"
NewOutboundRule.ServiceName = "vmms"
NewOutboundRule.Protocol = NET_FW_IP_PROTOCOL_TCP
NewOutboundRule.RemotePorts = "39100-39100"
NewOutboundRule.Action = NET_FW_ACTION_ALLOW
NewOutboundRule.Direction = NET_FW_RULE_DIR_OUT
NewOutboundRule.Enabled = true
wshRules.Add NewOutboundRule
'end of script
В результате успешного выполнения скрипта на хосте Hyper-V в ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System будет добавлено соответствующее разрешающее правило.
Примеры же того, как можно манипулировать правилами Windows Service Hardening с помощью PowerShell можно найти в заметке p0w3rsh3ll.wordpress.com - List the Windows Service Hardening firewall rules. Например для того чтобы получить список имеющихся правил Service Restriction можно как и в VB скрипте через PowerShell обратиться к соответствующему COM-объекту:
(New-Object -ComObject HNetCfg.FwPolicy2).ServiceRestriction.Rules
…или же через функцию Get-NetFirewallRule из PS-модуля NetSecurity:
Get-NetFirewallRule -PolicyStore ConfigurableServiceStore
Ну и соответственно, применительно к нашей проблеме, действие выполняемое в VB скрипте можно заменить на PS-конструкцию:
$Rule = @{ DisplayName = "Hyper-V - Allow outbound traffic from service to Static RPC port (TCP 39100)" Direction = "Outbound" InterfaceType = "Any" Action = "Allow" Protocol = "TCP" Service = "vmms" Program = "$($env:systemdrive)\WINDOWS\system32\vmms.exe" Enabled = "TRUE" RemotePort = "39100-39100" PolicyStore = "ConfigurableServiceStore" } New-NetFirewallRule @Rule
В результате выполнения VB или PS скрипта через пару минут генерация ошибок прекратилась и появились информационные сообщения об успешной регистрации SPN …
Таким образом, начиная манипуляции с кастомизацией дефолтных параметров AD DS будьте готовы к подобным граблям в самых неожиданных местах.
Подскажите, пожалуйста, статья применима для Windows server 2008 r2? - ошибки и поведение совпадают.
Не могу сказать, так как у меня уже давно нет в обороте хостов виртуализации на Windows Server 2008 R2. Попробуйте.
Спасибо Алексей, очень помогло.