Share Acess in SMB
Hello i have a strange problem with a share folder.
I have a share folder call "Special1"
in the Shared permission i have these group
-Special1
-domainadministrator
-administrator
I am in domain administrator group but i still dont have access to the shared folder.
I read some where that UAC strip of admin right to the folder for security reason, but if this is the case any got some links so i can read up on this?
If i add myself to Special1 group then there is no problem accessing the folder.
I can live with the work around because the problem is so little. But it would be fun to understand the actual problems :D
Thansk Experts
I have a share folder call "Special1"
in the Shared permission i have these group
-Special1
-domainadministrator
-administrator
I am in domain administrator group but i still dont have access to the shared folder.
I read some where that UAC strip of admin right to the folder for security reason, but if this is the case any got some links so i can read up on this?
If i add myself to Special1 group then there is no problem accessing the folder.
I can live with the work around because the problem is so little. But it would be fun to understand the actual problems :D
Thansk Experts
ASKER
OK, i will try that.
I took ownership as the users should i redo and take ownership as domain administrator group instead?
I took ownership as the users should i redo and take ownership as domain administrator group instead?
Try running AccessChk to know what kind of accesses specific users or groups have to resource. You can specify a user or group name and path, AccessChk will report the effective permissions for that account; e.g. The command reports the accesses that the Power Users account has to files and directories in \Windows\System32: accesschk "power users" c:\windows\system32
Some note on Share folder vs NTFS permission
- Share permissions apply to users who connect to a shared folder over the network.
- Share permissions do not affect users who log on locally, or log on using Remote Desktop. So to set permissions for users who log on locally or using Remote Desktop, set NTFS file permissions using the options on the Security tab instead of the Share Permissions tab.
It may seems to be a local user vs a domain user access permission. If both share permissions and file system permissions are set for a shared folder, the more restrictive permissions apply when connecting to the shared folder.
Some note on Share folder vs NTFS permission
- Share permissions apply to users who connect to a shared folder over the network.
- Share permissions do not affect users who log on locally, or log on using Remote Desktop. So to set permissions for users who log on locally or using Remote Desktop, set NTFS file permissions using the options on the Security tab instead of the Share Permissions tab.
It may seems to be a local user vs a domain user access permission. If both share permissions and file system permissions are set for a shared folder, the more restrictive permissions apply when connecting to the shared folder.
For example, to give Read access on a shared folder to users in your domain, on the Share Permissions tab, set permissions for the Everyone group to Full Control. On the Security tab, specify more restrictive access by setting the file permissions for the Domain Users group to Read access. The result is that a user who is a member of the Domain Users group has read-only access to the shared folder whether the user is connected through a network share, through Remote Desktop, or is logged on locally.In addition to shared folder permissions, users must have NTFS permissions for the files and subfolders that shared folders contain to gain access to those files and subfolders.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry for the delay in answer, have been on vacation :D
Thanks for all the answer i will check these and get back
Thanks for all the answer i will check these and get back
I would say AccessChk would help too see UAC need for elevated rights despite being a domain admin.
For example, AccessChk may run an exe and show the the elevated state:
.\accesschk.exe -p powershell.exe -e
ran elevated, shows:
[3256] powershell.exe
Medium Mandatory Level [No-Write-Up, No-Read-Up]
RW superUserPC2\testuser
RW NT AUTHORITY\SYSTEM
[3660] powershell.exe
High Mandatory Level [No-Write-Up, No-Read-Up]
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
In the second PowerShell (3660) it is running elevated because it has the High Mandatory Level.
For consideration, pl.
For example, AccessChk may run an exe and show the the elevated state:
.\accesschk.exe -p powershell.exe -e
ran elevated, shows:
[3256] powershell.exe
Medium Mandatory Level [No-Write-Up, No-Read-Up]
RW superUserPC2\testuser
RW NT AUTHORITY\SYSTEM
[3660] powershell.exe
High Mandatory Level [No-Write-Up, No-Read-Up]
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
In the second PowerShell (3660) it is running elevated because it has the High Mandatory Level.
For consideration, pl.
Accesscheck does not offer additional value. It is a command line tool for mass-checking permissions.
Here, the case is very clearly UAC related as this is an evergreen problem, you see this question over and over for as long as UAC has been around. The permissions were listed by the author and accesschk will not reveal anything new.The elevation state of explorer is unelevated - it cannot run elevated without the registry modification that I linked.
Now you can close the question btan.
Here, the case is very clearly UAC related as this is an evergreen problem, you see this question over and over for as long as UAC has been around. The permissions were listed by the author and accesschk will not reveal anything new.The elevation state of explorer is unelevated - it cannot run elevated without the registry modification that I linked.
Now you can close the question btan.
The tool is just to state whether the folder is required for elevated rights and permission. I understand where you are coming from. I do not have rights to close this discussion. thks for sharing
You misunderstand accesschk.
You run it against powershell, a process that you have started once elevated and once non-elevated. This makes a difference, yes. But running it against his folder or share will show no difference, because integrity levels are not used on folders by default. You can use those, yes, but it won't be the case here, since he does not seem to know these technical specialties.
You run it against powershell, a process that you have started once elevated and once non-elevated. This makes a difference, yes. But running it against his folder or share will show no difference, because integrity levels are not used on folders by default. You can use those, yes, but it won't be the case here, since he does not seem to know these technical specialties.
noted thanks for the clarification.
Then suggest go with McKnife's comment #a41941968
Just assign for your account full permissions to this folder, remove domain admins, close all and reopen folder properties / permission and add domain admins again and assign All permissions again.
You can also take ownership for this group and make domain admins to be owner.