The Problem:

I cannot access a Domain Computers-accesible network share by a process running on Windows XP as a SYSTEM account.

I've got a 2008R2 domain, a 2003R2 file server and a set of clients.

On the file server, I've made a share accessible by the Domain Computers group. The share is supposed to hold a read-only repository of files (Wpkg) to be accessed from domain workstations by a system service (Wpkg-GP) run by SYSTEM user.

Now the problem is that, while it works perfectly on Windows 7, it completely fails on Windows XP. It seems, that for some reason the SYSTEM account on Windows XP cannot authenticate as a computer. See more in details.

The Question:

What do I do wrong?

Is it perhaps a natural behaviour of Windows XP system? If so, can it be changed or fixed? Or is there any other way to achieve a scenario, in which a network share would be visible to the SYSTEM user on computers, without being accessible by the users?

The Details:

  • The Domain Computers group has received permissions both for the files and for the share
  • I have checked higher permissions, all the way from Read to Full Controll
  • I have tested the issue with fresh, out-of-the-box operating systems installed on VBox

Since the problem was reported by application, I first began to verify actual SYSTEM user rights. On both Windows versions (7 and XP) I have opened an elevated cmd session impersonating SYSTEM account (using PsExec -s -i cmd.exe) and attempted to manually mount the network share :

net use x: \\myfs.mydomain.com\Wpkg

On Windows 7, the drive has been mounted without demur. But on Windows XP the command responded with information about incorrect password and a prompt for new one:

[Windows XP]
Password for \\myfs.mydomain.com\Wpkg is incorrect.

Please enter password for "myfs.mydomain.com": _

(please note that this is only a translation, an official english locale may sound differently)

  • ist there a reason why you don't want to use the wpkg-gp feature to use a different account than SYSTEM to access the network shares? – chewbakka Apr 5 '13 at 10:26
  • Most important reason is that I would have to deploy these credentials openly via GPO, which wouldn't be entirely secure. – Michał Sacharewicz Apr 5 '13 at 17:24
  • Also, the current setup works well with Windows 7 and I hope there is nothing against it working in older system. And another important thing - I've attempted to try to push these credentials to XP selectively (via Wpkg-GP GPO adm pack), yet - suprisingly - it did not change anything on the XP systems. I'm not exactly sure if this feature works correctly. – Michał Sacharewicz Apr 5 '13 at 17:26

In a normal, vanilla environment, what your doing will work. I can't replicate what you're seeing. I created a share (\\server\share), granted Domain Computers Read access, and removed all other ACE's. Running under psexec -s -i -d cmd, I'm able to access the share from both the XP and Win7 computers.

How certain are you that the XP computer is a member of Domain Computers? By default, all new computer accounts are members of Domain Computers not via the member (or memberOf) attribute, but instead as the object's Primary Group. The Domain Computers group's well-known RID is 515. That RID value is stamped on the computer object's primaryGroupID attribute.

Can you take a look at the computer object's primaryGroupID and memberOf attributes and let me know what, if anything, is present? For that matter, if you're comfortable you could post the full output for an XP and Win7 computer? Either way, an easy way to get the info is with the following command: dsquery * -filter "name=COMPUTER_NAME_GOES_HERE" -attr *.

Something else to try would be changing the ACL on the share/NTFS, one at a time, to allow Everyone, Authenticated Users, Domain Users, and the computer's name itself. Try each and see which, if any, work.

  • Both computers have primaryGroupID=515. I have compared a complete list of computer attributes and the only thing that is significantly different between Windows XP and Windows 7 is that the XP lacks servicePrincipalName: RestrictedKrbHost/COMPUTER and servicePrincipalName: RestrictedKrbHost/COMPUTER.domain.mydomain.com entries. – Michał Sacharewicz Apr 6 '13 at 14:08
  • In the meanwhile, I found some more, err... interesting stuff about my domain: – Michał Sacharewicz Apr 6 '13 at 14:08
  • It is worth to point, that my DNS structure contains a mydomain.com (with linux DNS servers, out of my jurisdiction) and domain.mydomain.com (managed by two DCs). Funny thing is that workstations get mydomain.com NS adresses from DHCP and it even works, eg. they find the correct, domain NS and are able to write their SPNs correctly to the domain.mydomain.com zone... – Michał Sacharewicz Apr 6 '13 at 14:13
  • ...yet the fileserver, which has static IP & DNS configuration, points directly to DC DNS. And... this fileserver is actually not listed in DC DNS. This server has an A record configured in mydomain.com (let's say fs.mydomain.com) and that one works, yet fs.domain.mydomain.com fails to resolve. – Michał Sacharewicz Apr 6 '13 at 14:16
  • I have made an additional test - I used another domain-connected server (HyperV host) to make a share. This server, 2008R2, shows properly in DC DNS and... Windows XP SYSTEM user mounts it properly :) – Michał Sacharewicz Apr 6 '13 at 14:18


The source of the problem was the fileserver not registering itself into DC DNS. It seems it was apparently done by someone on purpose - the corresponding network interface option has been manually unchecked:

(network interface) 
  -> Properties 
    -> TCP/IP Protocol 
      -> Advanced 
        -> DNS 
          -> [ ] Register this connection's address in DNS

After checking the above option and issuing ipconfig /registerdns:

  • fileserver registered properly in DC DNS records
  • Windows XP SYSTEM user began to properly mount the problematic share without being asked for credentials

The different behaviour of Windows XP and Windows 7 must be due to some difference in internal implementation; I'd guess Kerberos, though my knowledge of Kerberos is yet superficial.

I find it interesting enough to add, that a quite similar thing happens when I try to add a CNAME record from ie. wpkg.domain.mydomain.com to filesystem.domain.mydomain.com:

In Windows XP only the final host name works:

C:\WINDOWS\system32>dir \\wpkg[.domain.mydomain.com]\wpkg
Access denied.

C:\WINDOWS\system32>dir \\fileserver[.domain.mydomain.com]\wpkg
[...result OK... ]

...while on Windows 7 there is nothing against using CNAME:

C:\WINDOWS\system32>dir \\wpkg[.domain.mydomain.com]\wpkg
[...result OK... ]

C:\WINDOWS\system32>dir \\fileserver[.domain.mydomain.com]\wpkg
[...result OK... ]

Note that here I got an Access denied error, not a password prompt.

  • Great that you figured it out! Regarding the CNAME not working, I know by default Windows will only allow SMB connections using the server's name or IP. If you manage to route an SMB request with a different name (like a CNAME), Windows will reject the request. You can use the DisableStrictNameChecking setting to disable this behavior to allow CNAME's. Keep in mind though that Kerberos will never be used in this configuration. – charleswj81 Apr 6 '13 at 22:00
  • So it seems that the Win7 machine is falling back to NTLM but the XP won't? Seems odd. And if so, it almost seems that maybe that same person already set DisableStrictNameChecking? Or used one of the methods here: marc-lognoul.me/itblog-en/post/2010/09/08/…? If you troubleshoot this any further I'd be interested to see what you find. Good luck! – charleswj81 Apr 6 '13 at 22:05
  • Worth remembering: It seems that the Register this connection's address in DNS setting is unchecked by default if you assign a static (non-DHCP) IP address to the server. – Michał Sacharewicz Apr 7 '13 at 9:55
  • I'll by trying with proper CNAME registering as soon as I get a final, production machine for my fileserver :) – Michał Sacharewicz Apr 7 '13 at 9:57
  • Hmm, I don't think that's a default behavior. Looking at my VM's (XP, Win7, 2003 R2, 2008 R2, 2012), all have retained the option as checked even though they are configured statically. Could this be caused by the method of how they were set statically? Maybe via an OS deployment? I know you mentioned this is an inherited environment, who knows what other surprises you're going to discover! – charleswj81 Apr 7 '13 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.