Identifying permissions on shares

If the image were mounted you could use Server Share Check from the W2K3 Server Resource Kit. This is a command line utility that will list all non-hidden shares on a computer (it also works on Windows XP and Windows 2000). It also enumerates the Access Control List (ACL) for each share.

If you are looking at the registry
SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
enumerates shares, including any permissions assigned to those shares.

The settings for File Server functionality are stored in HKEY_LOCAL_MACHINE\Services\Smbserver

Subkey UseAuthentication REG_DWORD shows if authentication is enabled.

FAT does not have any permissions.

If the image were mounted you could use Server Share Check from the W2K3 Server Resource Kit.

Bithead,
I had already tried srvcheck and it had miserably even on a live system with shares. It dint show me the perms I add added. I tried

I tried shareenum and accesschk from sysinternals as well and finally it was accesschk.exe which showed me the sid of the user in AD to whom I had denied all the perms… This ona live system …Now If I have an image and I need to do this, I was just wondering if the extract the file onto my disk, wont it affect the permissions on the folder Coz I ve seen in a small expt that the share perms are lost as soon as you copy the shared folder to another location (even on the same NTFS drive..)
The question still remains
"How do I see the perms on a shared folder in the image"

If you are looking at the registry
SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
enumerates shares, including any permissions assigned to those shares.

I dint find any entry which tals abt the perms on shares within this key

The settings for File Server functionality are stored in HKEY_LOCAL_MACHINE\Services\Smbserver

Funnily, I could nt locate this entry… Am i getting too old?
Thanks for your suggestions though, Bithead….
Cinux

I had already tried srvcheck and it had miserably even on a live system with shares. It dint show me the perms I add added. I tried

You tested this on unhidden shares on a Windows machine and got nothing? Odd. What was your syntax?
Here's an example of what you should see

C\>srvcheck \\w2k3

\\w2k3\tsclient
Everyone Read

\\w2k3\HelpDesk
Everyone Read

\\w2k3\webdev
W2K3\user1 Full Control
Everyone Read

I was just wondering if the extract the file onto my disk, wont it affect the permissions on the folder

If you extract them they will just show the pointer to the SID on the machine they were created on. Share permissions do not travel from one machine to another without REG changes. That is why I suggested mounting the image.

I dint find any entry which tals abt the perms on shares within this key

Is this not a W2k, XP, or W2K3 machine?
Petri IT Knowledgebase

I had already tried srvcheck and it had miserably even on a live system with shares. It dint show me the perms I add added. I tried

You tested this on unhidden shares on a Windows machine and got nothing? Odd. What was your syntax?
Here's an example of what you should see

C\>srvcheck \\w2k3

\\w2k3\tsclient
Everyone Read

\\w2k3\HelpDesk
Everyone Read

\\w2k3\webdev
W2K3\user1 Full Control
Everyone Read

I was just wondering if the extract the file onto my disk, wont it affect the permissions on the folder

If you extract them they will just show the pointer to the SID on the machine they were created on. Share permissions do not travel from one machine to another without REG changes. That is why I suggested mounting the image.

I dint find any entry which tals abt the perms on shares within this key

Is this not a W2k, XP, or W2K3 machine?
Petri IT Knowledgebase

Bithead,
My syntax was right. I got the same kinda result as you got. The only problem is it shows the permissions of "everyone" but not of the users' whom I had given/revoked perms exclusively.
It is an XP machine.
Nevertheless, I got my answer with Encase and accesschk. Strange, the first time I loaded encase, it did not show me the extra perms I had added to the shares… this time it did…. strange… has anyone else experienced such behaviour from Encase.

Bithead, thanks a ton for your suggestions!

Cinux