I recently encountered an issue involving the failure of a new Network Name resource to come online. Doing some investigation I found a number of instances where this has been encountered, with different resolutions provided. Since no root cause was defined, fellow Directory Services Engineer Robert Williams and I set out to determine the cause.
You’ll know you’ve encountered this issue if you create a new Network Name resource and it fails to online with the following errors:
In the System Event log you will see a Failover Cluster event 1194:
Log Name: System
Source: Microsoft-Windows-FailoverClustering
Date: 3/27/2013 1:19:07 PM
Event ID: 1194
Task Category: Network Name Resource
Level: Error
Keywords:
User: SYSTEM
Computer: ComputerName
Description:
Cluster network name resource 'ComputerName' failed to create its associated computer object in domain 'DomainName' for the following reason: Unable to obtain access to Computer Object in DS.
The text for the associated error code is: Access is denied.
Please work with your domain administrator to ensure that:
- The cluster identity 'CNO' can create computer objects. By default all computer objects are created in the 'Computers' container; consult the domain administrator if this location has been changed.
- The quota for computer objects has not been reached.
- If there is an existing computer object, verify the Cluster Identity 'CNO' has 'Full Control' permission to that computer object using the Active Directory Users and Computers tool.
In the Cluster log you will see the following entries:
00000ea4.000012b0::2013/03/25-16:55:04.113 ERR [RES] Network Name < NetworkName>: Failed to obtain access to computer account < AccountName>, status 80070005
00000ea4.000012b0::2013/03/25-16:55:04.128 ERR [RHS] Online for resource <NetworkName> failed.
Note: To generate a Cluster log, run the following command from an administrators command prompt. The Cluster.log file will be generated in the c:\windows\cluster\reports directory. The entry will be in the Cluster log on the Node where the online attempt failed.
Cluster log /gen
We determined that the root cause of the issue is due to the removal of NT AUTHORITY\Authenticated Users from the local Users group. Note below that it is present by default:
![clip_image002[7]](http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-59-75-metablogapi/3716.clip_5F00_image0027_5F00_thumb_5F00_33F0FB02.jpg "clip_image002[7]")
The best solution is to add back NT AUTHORITY\Authenticated to the local Users Group. This will require a reboot for the change to take effect. If your security team is unwilling to do this, you can disable the following two Security policies and refresh the policy by running gpupdate /force:
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares
![clip_image004[7]](http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-59-75-metablogapi/4670.clip_5F00_image0047_5F00_thumb_5F00_38F338B1.jpg "clip_image004[7]")
You will have to determine which of these two options best fits the security requirements for your environment. It may be a good option to create a separate Organizational Unit (OU) for your Cluster servers. This will allow you to affect the preferred change to the limited subset of servers.
Steven Andress
Senior Support Escalation Engineer
Microsoft Customer Support & Services