Windows remote management 10154

Долгое время на подконтрольных контроллерах доменов я наблюдал ошибку с номером 10154, эта статья лекарство для неё.

Полный пример текста ошибки:

The WinRM service failed to create the following SPNs: WSMAN/SRV-DC1.dp.internal; WSMAN/SRV-DC1.

Additional Data
The error received was 1355: %%1355.

User Action
The SPNs can be created by an administrator using setspn.exe utility.
Microsoft-Windows-WinRM
EventID 10154

Картинка с сайта: www.ashpak.ru

В моём случае известно, что подобные предупреждения появляются на любых контроллерах домена, до их исправления. Причина их появления – отсутствие прав у указанного сервиса для изменения информации о параметрах. Почему права урезаны изначально — стоит спросить у Microsoft, имхо это просто их ошибка.

Решение:

1. Открыть adsiedit.msc
2. Подсоединиться к требуемому домену.
3. Найти запись требуемого доменного контроллера.

Картинка с сайта: www.ashpak.ru

4. Открыть свойства требуемого домен контроллера.
5. Открыть закладку Безопасность.
6. Добавить Network Service
7. Добавленному Network Service разрешитm Validated write to service principal name (В русской локализации «Удостоверенная запись на узел с именем участника службы»)

Картинка с сайта: www.ashpak.ru

Более подобных сообщений не будет.

Кстати, пока искал русскую локализацию параметра наткнулся на абсолютно правильную ремарку на форуме микрософта.

Способ 2, для ленивых:
Запустите ADUC с активированным «view: advanced features», далее выберите OU «Domain Controllers» или где там у Вас объекты компьютеров контроллеров домена расположены, вызовите свойства объекта контроллера и на закладке «Security» дайте право «NT Authority\Network Serice» на «Validated Write Service Principal Name». Дождитесь репликации, предупреждение от WinRM должно Вам больше не беспокоить.

Источник

Содержание страницы

  • Первоначальная настройка
  • Удаление настроек
  • Исправление ошибок
    • Код события:10154 Источник: Microsoft-Windows-WinRM

Первоначальная настройка

Для включения и первоначальной настроики службы WinRM в Windows, есть несколько вариантов

  • CMD
winrm quickconfig
winrm e winrm/config/listener
  • PowerShell
Enable-PSRemoting –Force
Enable-WSManCredSSP -Role server –Force

Удаление настроек

Disable-PSRemoting -Force

Исправление ошибок

Код события:10154 Источник: Microsoft-Windows-WinRM

Event ID: 10154, Source: Microsoft-Windows-WinRM, Type: Warning

Службе WinRM не удалось создать следующие имена участников-служб: WSMAN/dc1.notdev.local, WSMAN/dc1
Дополнительные данные
Была получена ошибка “8344”: %%8344.

Проблема чаще всего возникает с серверами Hyper-V и AD DC, проблема существует очень давно и до сих пор не решена, либо MS не желает объяснять почему эту процедуру нужно выполнять самостоятельно либо просто игнорируют данную ошибку, которая редко когда мешает работе служб.

Исправить данную ошибку проще всего используя командную строку

dsacls "CN=DC1,OU=Domain Controllers,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"
dsacls "CN=DC2,OU=Domain Controllers,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"
dsacls "CN=HVS1,OU=Hyper-V,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"
dsacls "CN=HVS2,OU=Hyper-V,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"
dsacls "CN=HVS3,OU=Hyper-V,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"
dsacls "CN=HVS4,OU=Hyper-V,DC=notdev,DC=local" /G "S-1-5-20:WS;Validated write to service principal name"

CN=DC1,OU=Domain Controllers,DC=notdev,DC=local – путь до указанного сервера

S-1-5-20 – это учетная запись Сетевая служба /  NETWORK SERVICE

Validated write to service principal name /в русской локализации Удостоверенная запись на узел с именем участника службы или Удостоверенная запись на узел с именем субъекта-службы

Решение через графический интерфейс

Вариант через оснастку Редактирование ADSI (ADSIEDIT)

  • Запустите adsiedit.msc
  • Подключитесь к домену
  • Перейдите к DC=notdev,DC=local далее  OU=Domain Controllers и выберите узел CN=DC1
  • Щелкните правой кнопкой мыши CN=DC1, нажмите Свойства
  • Перейдите на вкладку Безопасность
  • Добавьте учетную запись сетевой службы NETWORK SERVICE
    • Затем установите флажок (X), чтобы разрешить доступ Validated write to service principal name, в русской локализации Удостоверенная запись на узел с именем участника службы или Удостоверенная запись на узел с именем субъекта-службы
    • Нажмите ОК
  • Перезапустите службу Удаленное управление Windows (WS-Management)
  • Проверьте журнал событий на наличие ошибок

Вариант через оснастку Active Directory Пользователи и Компьютеры (ADUC)

  • Запустите dsa.msc
  • Подключитесь к домену
  • Включите отображение дополнительных компонентов, Вид -> Дополнительные компоненты
  • Перейдите в OU=Domain Controllers и выберите узел DC1
  • Щелкните правой кнопкой мыши DC1, нажмите Свойства
  • Перейдите на вкладку Безопасность
  • Добавьте учетную запись сетевой службы NETWORK SERVICE
    • Затем установите флажок (X), чтобы разрешить доступ Validated write to service principal name, в русской локализации Удостоверенная запись на узел с именем участника службы или Удостоверенная запись на узел с именем субъекта-службы
    • Нажмите ОК
  • Перезапустите службу Удаленное управление Windows (WS-Management)
  • Проверьте журнал событий на наличие ошибок

–

Дополнительные материалы

  • Идентификаторы безопасности

Источник

Skip to content

Sometimes when you create new DC you will get this error inside event log. It means that WINRM service can not create SPN in Active directory with its credentials. You can create SPNs manually, but WINRM service will try to create it every time you start domain controller. To solve this you need to give certain permissions to Network Service account in Active Directory.

image

Картинка с сайта: igorpuhalo.wordpress.com

For this to work you need to give Network Service next permissions on DC computer object using ADSI edit console (ADSIEDIT.msc).

image

Картинка с сайта: igorpuhalo.wordpress.com

If you list SPNs registered for DC you will see next list

C:\Windows\system32>setspn -l dc1
Registered ServicePrincipalNames for CN=DC1,OU=Domain Controllers,DC=test,DC=ba:
         TERMSRV/DC1
         TERMSRV/DC1.test.ba
         Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC1.test.ba
         ldap/DC1.test.ba/ForestDnsZones.test.ba
         ldap/DC1.test.ba/DomainDnsZones.test.ba
         DNS/DC1.test.ba
         GC/DC1.test.ba/test.ba
         RestrictedKrbHost/DC1.test.ba
         RestrictedKrbHost/DC1
         RPC/a90510ff-a822-4109-8123-de4e338205ba._msdcs.test.ba
         HOST/DC1/TEST
         HOST/DC1.test.ba/TEST
         HOST/DC1
         HOST/DC1.test.ba
         HOST/DC1.test.ba/test.ba
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/a90510ff-a822-4109-8123-de4e338205ba/test.ba
         ldap/DC1/TEST
         ldap/a90510ff-a822-4109-8123-de4e338205ba._msdcs.test.ba
         ldap/DC1.test.ba/TEST
         ldap/DC1
         ldap/DC1.test.ba
         ldap/DC1.test.ba/test.ba

After you apply permissions to Network Service WSMAN is there

C:\Windows\system32>setspn -l dc1
Registered ServicePrincipalNames for CN=DC1,OU=Domain Controllers,DC=test,DC=ba:
         WSMAN/DC1
         WSMAN/DC1.test.ba
         TERMSRV/DC1
         TERMSRV/DC1.test.ba
         Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC1.test.ba
         ldap/DC1.test.ba/ForestDnsZones.test.ba
         ldap/DC1.test.ba/DomainDnsZones.test.ba
         DNS/DC1.test.ba
         GC/DC1.test.ba/test.ba
         RestrictedKrbHost/DC1.test.ba
         RestrictedKrbHost/DC1
         RPC/a90510ff-a822-4109-8123-de4e338205ba._msdcs.test.ba
         HOST/DC1/TEST
         HOST/DC1.test.ba/TEST
         HOST/DC1
         HOST/DC1.test.ba
         HOST/DC1.test.ba/test.ba
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/a90510ff-a822-4109-8123-de4e338205ba/test.ba
         ldap/DC1/TEST
         ldap/a90510ff-a822-4109-8123-de4e338205ba._msdcs.test.ba
         ldap/DC1.test.ba/TEST
         ldap/DC1
         ldap/DC1.test.ba
         ldap/DC1.test.ba/test.ba

Источник

Fixing Event ID 10154 — The WinRM service failed to create the following SPN

The Problem

The configuration of the system when this error was encountered is as follows:

A. Windows Server 2008 R2 Redundant Domain Controllers — we will call these DC1.joshwieder.com and DC2.joshwieder.com
B. Windows Server 2003 Web Server with Windows Remote Management enabled / part of the Active directory deployment — we will call this WEB.joshwieder.com
C. For the sake of our example, let’s say I have configured an OU named «Web Servers» on those domain controllers

Whenever the Windows 2003 Web server reboots, or WinRM.exe service on the Windows 2003 Web server restarts, the following error was logged into the Event Viewer:

Event ID: 10154
Source: Microsoft-Windows-WinRM
Version: 6.1
Symbolic Name: LOG_WSMAN_SPN_CREATION
Message: The WinRM service failed to create the following SPN: %1.
Additional Data
The error received was 8344: Insufficient access rights to perform the operation.
User Action
The SPN can be created by an administrator using setspn.exe utility.

***NOTE: This issue has also been well documented as occurring while using Windows Small Business Server (SBS) 2003

The Explanation

First its important to understand what all of this means and why we should care. This error and its fix are documented in a number of websites elsewhere, however those documents lack any form of explanation to help us better understand what is occurring here. 

SPN stands for Service Provider Name. SPNs exist on the domain controller to indicate which service applications are assigned to which computers within the Active Directory forest. WSMAN means Web Services Management (notated commonly as WS-Management), which is a Microsoft protocol used to acquire information related to services and applications hosted on a remote server, and to manage those applications and services. WSMAN differs significantly from SNMP by allowing administrators to perform a more comprensive array of tasks. Whereas SNMP would simply get information, WSMAN gets information and allows an admin to remotely install and modify applications based on that information (SNMP has SetRequest, which is limited to a narrow set of predefined variables).

The WinRM service  (Windows Remote Management) is what is installed and runs on servers to listen for WSMAN commands. WinRS (Remote Shell) is the client side application of the protocol, and sends the WSMAN commands to the remote host.

Now that we understand the context of the conflict, we can return to our specific error with a greater understanding of the situation. Its important to note that I was able to verify that the WSMAN SPN does in fact exist on both of my domain controllers, so using setspn.exe to create the SPN wasn’t going to help me much. I verified this was true by logging into the domain controllers and running the following command: 

setspn -L WEB 

(remember we are assuming that my webserver is named web.joshwieder.com)

The output contained a number of items, including the two I was looking for:

WSMAN/WEB and WSMAN/WEB.JOSHWIEDER.COM

This lets me know that the SPExNs do in fact exist. Knowing that winRM.exe will try to rewrite the SPN every time it starts, and together with the Additional Data field of the error message, we now had a confirmed diagnosis and prognosis — the web server has insufficient permissions to write to the SPN, forced rewriting of the SPN at service start generates the error and while there may be no immediate server-side issues because the SPN already exists, that could change at anytime. 

The Solution

First, it is necessary to confirm that the WinRM service is properly patched and updated. For Windows 2003 servers, the subject of our discussion here, this means updating to version 2.0 provided via KB968930. 2003 does not include WinRM by default, and older 2003 servers that you have inherited may still be running the antediluvian version 1.1. Windows 2008 servers now include version 3. 

Supposing the service is fully updated, there are two ways to go about doing this. Both should accomplish the same thing, but if you have issues with one method try the other. 

The first is the easiest to perform for those more comfortable with a GUI. From your domain controller, launch ADSIEDIT.MSC. Connect to the relevant Active Directory instance (typically just the default local connection is fine), then navigate through the domain to the server we are experiencing this issue with. The order of navigation is:

DC=Domain

OU=Variable Organizational Unit

CN=Machine Name

Using our example, I would navigate to:

DC=joshwieder

OU=Web Servers

CN=WEB

Right click on CN=WEB and select Properties. Select the Security tab, click Add, «NETWORK SERVICE». (This assumes that you run the WinRM service using the default identity settings — select the account that is relevant for your configuration). Click Advanced and Effective Permissions tab, and select «Validated write to service principal name». Then Click OK to save your changes. Reboot the domain controller and restart the WinRM service.

Once completed, use setspn -L and the Event Viewer to confirm whether the change was successful. If not, you can use the command line option as an alternative: 

dsacls «CN=Web Servers,CN=WEB,DC=ai-host,DC=com» /G «S-1-5-20:WS;Validated write to service principal name»

Same end result here as with the GUI — reboot the DC and restart the WinRM service and check the logs or setspn -L. You’re accomplishing the same end result with either task — however there are a host of reasons why a GUI can be problematic. I have yet to encounter a set of circumstances where neither trick does not resolve the issue. If this does not resolve your trouble, please email or comment for me.

Extra Credit

Planning on using the WinRM IIS Extension? Launch Server Manager and select Add Features to provision the needed packages. Reboot your server and launch a command prompt, then use winrm qc to complete the configuration.

Источник

This occurs on domain controllers. WinRM runs as NETWORK SERVICE and attempts to register the WinRM SPNs on the appropriate AD domain controller object. You may manually add the NETWORK SERVICE account to the permissions on the object to enable the Validated Write to Service Principal Name, but you’ll find that the error continues to occur.

This is because the Domain Controllers security group falls under the protection of the AdminSDHolder object, which is used by Domain Controllers to protect high-privilege accounts from inadvertent modification. The SDPROP process runs on the domain’s PDC Emulator, every 60 minutes, by default (can range from 60 seconds to 7200 seconds, 2 hours) and restamps the AdminSDHolder ACL on every protected object, effectively undoing the ACL update you made.

In order to fix this, add the Validated Write to Service Principal Name for NETWORK SERVICE on the AdminSDHolder object. This will then stamp that ACL on the domain controller objects and the error should go away.

https://msdn.microsoft.com/en-us/library/dd240059.aspx

https://msdn.microsoft.com/en-us/library/dd240058.aspx

Источник

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Hp universal printing pcl 6 windows 10 x64
  • Порядок разрешения имен windows
  • Apache настройка аутентификации в windows
  • Сборка windows 10 для старого ноутбука
  • Github add ssh key windows