User Access Verification on Windows Network Shares

Introduction

In IT, having a tight access control over critical data is the key to it's protection and safety. This requires updating and reviewing shared files and folder access lists. Often this is done by IT support staff, however the outsourcing of IT services with long communication lines, missunderstandings, time gaps and cost reductions lead to situations. It is always good for data owners to be able to identify access, knowing "who has a key to the place".

Using Windows commands on a standard laptop, it is possible for staff and normal users to identify access to local and shared folders. With access updates typically executed by IT staff on domain conntrollers, we can confirm if access update requests ifor critical files and folders have been executed as requested.

The instructions below were run on a Windows 7 laptop, using the “commandline” program for execution of operating system commands.

Prerequisites

Note 1: The ability to verify folder access by normal, non-admin staff requires the user who runs the commands to already have at least “read” access to the folder.
Note 2: With IT, there are often “special” conditions that may prevent commands from running, or output needs to be interpreted correctly. Commands can be run with the “/?” switch to get help about options and output. For further help, it is best to contact IT. In our case, extraction of folder access rights can be requested to IT support using the ticketing system.

Open a “commandline” window for typing the operating system commands: Go to Start ➞ Accessories ➞ Command Prompt

All output shown below in grey highlighted windows was executed within the command prompt environment.

Connect the network “share” using the command line

The access verification commands run on folders that are visible on the command line. For network “shared’ folders, we need to confirm if they are “connected”. To verify if a shared folder is connected and visible:

C:\Windows\system32>net use
New connections will not be remembered.

There are no entries in the list.

In the example above, no shared drives are visible. We would like to verify a folder under the shared drive mounted as “S:”. In our example, we can connect this “shared” drive as shown below:

C:\Windows\system32>net use S: \\tofsserver3\dfs\shared
The command completed successfully.

Now we have a network “share” drive connected. It is visible on the command prompt and ready to be used for verification.

Show a folders access list

The Windows operating system command icacls lists access entries for the folder. Below shows an example:

C:\Windows\system32>icacls "S:\MKS\Audit"
S:\MKS\Audit MYDOMAIN2\acl_Audit:(OI)(CI)(M)
             No mapping between account names and security IDs was done. (OI)(CI)(RX)
             MYDOMAIN2\Domain Admins:(OI)(CI)(F)
             No mapping between account names and security IDs was done. (OI)(CI)(RX)
             No mapping between account names and security IDs was done. (OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

The access rights are displayed at the end of the output:

RX = read/execute
F = full
M = modify

For detailed information about the meaning, see the Microsoft documentation on file and folder permission access rights (link).

Note 1: Three lines in our example are listed as: "No mapping between account names and security IDs was done." This means there is a record that does not link to a user or group anymore. IT removed a domain user or group in the past, and did not update the folder access list. As a result, these are “dead" remains, without any function.
Note 2: In the example, I enclosed the folder path and name entry with double quotes (“”). This is a trick to ensure proper execution on folders who carry a space in their name. Otherwise, the command would fail on those.

Identify the individual group members

In an ideal, organized IT world, shared folder access is controlled by domain groups, rather than adding individual users. In our example above, There are two groups. Our IT has a group naming convention, defining that user group names are preceded by “acl_”. This is a good practise to quickly indentify if an entry it is a user or a group. Note that there is no standard.

In this step, we will use the net group command to identify the individual user ID’s that belong to that domain group:

C:\Windows\system32>net group /Domain acl_Audit
The request will be processed at a domain controller for domain japan.corp.fm4dd.com

Group name     acl_Audit
Comment        Audit Team

Members

-------------------------------------------------------------------------------
argento                  kosenra                  megulthi
mksasg1                  mksasg2                  saphirol
The command completed successfully.

Repeat this step for all groups listed under the folders access.

Translate user ID's into real names

Windows user IDs are hard to read and to link to real users, because they are short and unique. Our IT organization has a naming convention that “builds” a user ID from 5 starting characters on the Last name, plus two characters from the first name. This process is not ideal, and naming conflicts are resolved by deviation from this standard. As a result, we need to translate the Windows user ID into the real user name.

The net user command below shows an (imaginary name) example:

C:\Windows\system32>net user /Domain kosenra
The request will be processed at a domain controller for domain japan.corp.fm4dd.com.

User name                    kosenra
Full Name                    Raphael Kosenna
Comment                      /I/A113062/MKS/Kosenna Raphael - User (Audit) A113062
User's comment
Country code                 000 (System Default)
Account active               Yes
Account expires              Never
...
The command completed successfully.

Notice the full name is being displayed on the second line for the given user ID.

Conclusion and further links

Using the above method is on way to establish access rights to Windows domain network folders and files, and to verify if access is correct. File and folder access rights are a critical piece in our computerized and networked word of shared data.

There is a magnitude of further information and details about access rights that is beyond this short how-to. As a foundation, file and folder permission options depend on the underlying “file system”. In the Windows world, we commonly use a file system called NTFS. Other file systems are possible, and the access right and permission options can be distinctively different.

There are tools and software that helps extracting the information in a automated fashion. Free and commercial, with installation and without. To name a few: Hyena, DumpSec, FileAcl, and scripts using Windows power shell exist.

The following links may help in gathering further information and knowledge:

Was it helpful? Are there any errors? - Your comments and "Thanks" goes a long way in support for this site.