0

These administrative file shares seem to contain some magic which is either poorly documented or very hard to get to. There is a lot of information of various aspects but nothing seem to apply exactly to the situation.

This is in a domain environment.

My test-account is a domain user, with NO domain or administrative privileges.

The problem: The user account can access \localhost\C$ from an interactive command prompt, but not when running as a service or from task scheduler. Why?

The share is there:

C:\Windows\system32>net share c$

Share name        C$
Path              C:\
Remark            Default share
Maximum users     No limit
Users             
Caching           Manual caching of documents
Permission        Everyone, FULL

The command completed successfully.

I use run-as to start a command prompt under my test account and can access the share:

C:\Windows>whoami
domain\my-test-account

C:\Windows>whoami /groups

GROUP INFORMATION
-----------------

Group Name                             Type             
====================================== ================ 
Everyone                               Well-known group
BUILTIN\Users                          Alias           
NT AUTHORITY\INTERACTIVE               Well-known group
NT AUTHORITY\Authenticated Users       Well-known group
NT AUTHORITY\This Organization         Well-known group
LOCAL                                  Well-known group
Mandatory Label\Medium Mandatory Level Label           

C:\Windows>dir \\localhost\c$
 Volume in drive \\localhost\c$ has no label.
 Volume Serial Number is XXXXXXX

 Directory of \\localhost\c$

2017-09-12  15:57    <DIR>          Users
2017-09-11  22:35    <DIR>          Windows
[shortened]
              45 File(s)     23 375 593 bytes
               9 Dir(s)   3 332 526 080 bytes free

Then I try to access the file listing using a task scheduler set to execute under the same account. It also occurs if I try as windows service. In the task scheduler I have added these two commands:

cmd /c whoami /groups > C:\Users\my-test-account\groups.txt
cmd /c dir \\localhost\C$ > C:\Users\my-test-account\files.txt

After executing, the groups when running as a batch job are (from the groups.txt file created above):

Group Name                             Type             
====================================== ================
Everyone                               Well-known group
BUILTIN\Users                          Alias           
NT AUTHORITY\BATCH                     Well-known group
CONSOLE LOGON                          Well-known group
NT AUTHORITY\Authenticated Users       Well-known group
NT AUTHORITY\This Organization         Well-known group
LOCAL                                  Well-known group
Mandatory Label\Medium Mandatory Level Label           

However, the file list output (files.txt) is empty, and the test schedule event history seem to indicate the file listing command ended with some error.

So there are some differences in the list of active groups, particularly it's of course not considered INTERACTIVE when run as a batch job, but I haven't been able do find any documentation about INTERACTIVE users being treated specially in this context.

Oskar Berggren
  • 121
  • 1
  • 5
  • 2
    What is the point of trying to access `\\localhost\C$` ? – Ryan Ries Sep 12 '17 at 20:46
  • @RyanRies The utility in question was originally targetting a different machine. I was hoping to adjust it with minimal changes by just giving localhost as the server name. Then when I noticed this I became curious to find out exactly what black magic is preventing it. – Oskar Berggren Sep 15 '17 at 18:12

0 Answers0