locked
The WinRM service failed to create the following SPNs RRS feed

  • 質問

  • Just promoted a 2008 R2 to a DC in a 2003 Forest. and I am getting the following error - does anyone have a fix ? - I have searched about but results are mixed and dont actually tell me how to resolve the error.
    I have not yet enabled remote management on the 2008 DC.


    Log Name:      System
    Source:        Microsoft-Windows-WinRM
    Date:          23/10/2009 18:50:18
    Event ID:      10154
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:      dc01.mydomain.com
    Description:
    The WinRM service failed to create the following SPNs: WSMAN/dc01.mydomain.com; WSMAN/dc01.

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

     User Action
     The SPNs can be created by an administrator using setspn.exe utility.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-WinRM" Guid="{A7975C8F-AC13-49F1-87DA-5A984A4AB417}" EventSourceName="WinRM" />
        <EventID Qualifiers="7">10154</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2009-10-23T17:50:18.000000000Z" />
        <EventRecordID>4082</EventRecordID>
        <Correlation />
        <Execution ProcessID="0" ThreadID="0" />
        <Channel>System</Channel>
        <Computer>dc01.mydomain.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="spn1">WSMAN/dc01.mydomain.com</Data>
        <Data Name="spn2">WSMAN/dc01</Data>
        <Data Name="error">8344</Data>
      </EventData>
    </Event>

    2009年10月23日 20:44

回答

  • Not exactly.  As I see it, the problem is that NETWORK SERVICE has no Validated write to Service Principal Name permission on the server AD object in the Domain Controllers OU.  You can add an ACE with this permission on the server AD object, and then restart the WinRM service - you will see Event 10149, but not Event 10154, and the problem will be solved, for awhile.  However, the next time the SDPROP process runs, which is every 60m by default, it will apply the AdminSDHolder ACL to the server object and undo what you did.  Event 10154 will start recurring.  Adding the ACE to the AdminSDHolder will prevent this from happening.
    • 回答としてマーク David Shen 2009年11月11日 10:56
    2009年10月24日 23:08

すべての返信

  • I found this thread, which refers to the fact that exchange2010 has not been installed, and might be responsible for the error.

    http://social.technet.microsoft.com/Forums/en-CA/windowsserver2008r2management/thread/b24a86f3-1531-4fa5-a543-8edf5e43c050


    2009年10月23日 20:57
  • I started the thread you referenced.  In Exchange 2010 RC, the problem I reported in that thread has been fixed.  However, Event 10154 is still associated with adding the AD DS (Domain Controller) role. 

    The problem is that the AdminSDHolder AD object by default has no ACE for Validated write to Service Principal Name for NETWORK SERVICE, the account that the WinRM service runs under.  When the SDPROP process runs, it applies the AdminSDHOlder ACEs to the computer object in the Domain Controller OU, which means the NETWORK SERVICE can't add the SPNs mentioned in Event 10154. 

    The solution that works for me is to add a Validated write permission for NETWORK Service to the AdminSDHolder AD object (this object only - no inheritance to descendant objects (subobjects).

    dsacls "CN=AdminSDHolder,CN=System,DC=yourdomainname,DC=tld" /G "S-1-5-20:WS;Validated write to service principal name"

    The SDPROP process will propate this ACE to the computer object in the Domain Controller OU, and Event 10154 will stop recurring.
    2009年10月24日 1:55
  • just to confirm
    Im not running exchange 2010 (but plan to maybe in Q2 2010) Im still on exchange 2007, the particular problem is due to   AdminSDHolder AD not having the correct permissions to create the SPN.
    2009年10月24日 18:28
  • Not exactly.  As I see it, the problem is that NETWORK SERVICE has no Validated write to Service Principal Name permission on the server AD object in the Domain Controllers OU.  You can add an ACE with this permission on the server AD object, and then restart the WinRM service - you will see Event 10149, but not Event 10154, and the problem will be solved, for awhile.  However, the next time the SDPROP process runs, which is every 60m by default, it will apply the AdminSDHolder ACL to the server object and undo what you did.  Event 10154 will start recurring.  Adding the ACE to the AdminSDHolder will prevent this from happening.
    • 回答としてマーク David Shen 2009年11月11日 10:56
    2009年10月24日 23:08
  • Sorry if I missed something here but I'm running Server 2008 R2 as a domain controller and it is showing these Event 10154 messages every time I reboot it.  I've tried all the fixes you guys mention and no matter what I do the Event ID still pops up every time the WinRM Service starts.  I'm not running Exchange in this particular environment or on this server at all.  It is just a DC.  Anyones help would be greatly appreciated because I can't figure out how to get rid of these messages.  Thanks!
    2009年12月19日 18:03
  • lol. I'm in the same boat (DC only.  No exchange).  And guess what, when you have a unique scenario/question, the forum threat stops. ;)

    Good luck!

    2010年5月28日 20:49
  • Sory, I hadn't checked this thread in a long time.  Try running the following command, as described in my from 2009-10-24  Then wait an hour or so for the SDPROP process to run, and then restart the WinRM service or restart the server.  Event 10154 should not recur.

    dsacls "CN=AdminSDHolder,CN=System,DC=yourdomainname,DC=tld" /G "S-1-5-20:WS;Validated write to service principal name"

    If your domain name was microsoft.com, the command would be

    dsacls "CN=AdminSDHolder,CN=System,DC=microsoft,DC=com" /G "S-1-5-20:WS;Validated write to service principal name"

    2010年5月30日 3:03
  • Make sure the the Local Service context has the following rights:

    SeAssignPrimaryTokenPrivilege       Replace a process-level token
    SeAuditPrivilege                            Generate security audits
    SeChangeNotifyPrivilege                 Bypass traverse checking
    SeCreateGlobalPrivilege                 Create global objects
    SeImpersonatePrivilege                 Impersonate a Client After Authentication

    And make sure that the Network Access Protection service is configured to start automatically and started.     It's normally configured to Manual.    WinRM has a hook to see if there are NAP policies enforced, but can't validate the configuration so it fails.

    The permissions on AdminSDHolder made no difference for me with three different customers.

     

    2010年6月21日 14:16
  • In my case, Network Access Protection is not used, which could explain why my method of addressing this symptom worked.
    2010年6月23日 0:56
  • For the record: Dom Vila's tip did fix this issue here.
    Armando Lacerda
    2010年6月23日 3:31
  • Hi,

    I have this issue also but try all the above still the same so add the NETWORK SERVICE Write Permission using ADSI Edit.

    http://srvcore.wordpress.com/2010/01/02/domain-controllers-warning-event-id-10154/

    Follow the above still cannot. After add the Write Permission the warning go away.

    Is it OK to add NETWORK SERVICE Write Permission to the Domain Controller Object ???


    Hope you find the info useful
    2010年6月23日 15:46
  • dsacls "CN=AdminSDHolder,CN=System,DC=microsoft,DC=com" /G "S-1-5-20:WS;Validated write to service principal name"

     

    This worked perfectly! :) 


    Should you do a restart of the server at this point and is this required on each W2K8R2 DC that is experiencing this issue? 

    • 編集済み TechAndy 2010年6月29日 18:04 typo
    2010年6月29日 18:03
  • As I remember, it is not necessary to restart the server, and the added ACE on AdminSDHolder object will be applied to all DCs. You just have to wait for the SDPROP process to run.  You can check if the problem is resolved by restarting the WinRM service.

    2010年6月29日 18:58
  • Hi Customers,

     

    We wanted to make everyone aware that if you are experiencing this event on your domain controllers, you do NOT need to modify the ACL of the AdminSDHolder object in order to make the warning stop occurring.  The AdminSDHolder object is used as a template to restamp the ACLs of protected user accounts, such as members of the domain administrators group.  Domain Controller computer accounts are not protected user accounts.  You can tell this by looking at the value of the AdminCount attribute on the Domain Controller computer object in ADSIEdit or in the Attribute Editor tab in the properties for the account within Active Directory Users and Computers.  If the account is protected, AdminCount will be set to a value of 1.  If the account is not protected, the AdminCount attribute will display a value of <not set>.  By default, computer accounts, including domain controller computer accounts, are not protected by AdminSDHolder, so the AdminCount attribute should not be defined.

     

    So, to alleviate the WinRM error messages, you only need to add the “Validated Write to Service Principal Name” permission for the Network Service account directly to each domain controller computer account in Active Directory.  You do not need to modify the AdminSDHolder object.

     

    If you’d like to see more information about AdminSDHolder and how it works, check out these articles:

     

    Description and Update of the Active Directory AdminSDHolder Object - http://support.microsoft.com/default.aspx?scid=kb;en-us;232199

     

    AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts - http://support.microsoft.com/default.aspx?scid=kb;en-us;306398

     

    How Security Principals Work - http://technet.microsoft.com/en-us/library/cc779144.aspx


    Laura Zhang - MSFT
    2011年12月1日 1:27
    モデレータ