This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 19%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERP%3C/text%3E%3C/svg%3E)
Hi,
We are developing the windows executable and need to limit the executable’s access to folders on a shared drive.
We use the CreateRestrictedToken function (SidsToDisable parameter) to deny access to folders for specific groups.
Seems that the deny flag only works on local folders, but does not work on a shared folder.
Here is an example:
The shared folder vm62share has share permissions set to Everyone, full control and security permissions to active directory
group Team-b, full control. This effectively limits access to Users in group Team-b only.
We need to prevent access to a shared folder (vm62share) for the process who’s user is member of group Team-b.
We start the process with a restricted token by using the CreateRestrictedToken function. The
restricted token has a deny flag set on group Team-b. We check the process’s flags using the
Process Explorer:
If we create a local folder and limit access to group Team-b only, then
the deny flag works as expected (the process with the deny flag is not
able to read/write files in the folder).
Looks as if the deny flag does not have any effect on shared folders.
Can you please explain.
Hi @Ro Po
This is expected behaviour, the restricted token is only used in the context of the resources that are accessed locally by the process. As soon as you access a resource on a network share, kerberos authentication will be used, and a complete\unrestricted token will be used.
I haven't try this but might be worth a trying, try accessing the share using the IP address rather than the name, kerberos won't be used and it will default to NTLM and it might pass the current process token instead.
You might need to look at a different solution, but I not sure why you want to restrict the access of the exe, when the user will have access to the contents of the share anyway. If you could provide a bit more background I'm might be able to suggest an alternative approach.
Gary.
Gary, thank you for the reply.
Can you please recommend a document describing the topic.
The background is as follows:
The executable is an agent performing different actions on behalf of other users.
For example:
Let's assume we have active directory groups Team-a and Team-b.
User Agent is member of both Team-a and Team-b
User Alice is member of Team-a only.
User Alice requests execution of a windows batch script which requires access to files
on a shared drive.
A shared drive only allows access to members of Team-b.
The agent executable starts a new restricted process under user Agent to run the batch.
The restricted process is started using the CreateRestrictedToken where the token
is restricted so that a deny flag is set for all groups Alice is not a member of.
In this case the deny flag is set for group Team-b.
The end result is that the restricted process executing the batch is running under
user Agent, but has the same permissions as user Alice.
The method works well on local resources, since the
executing batch script will be denied access.
As you pointed out, does not work for network shares.
What is a good alternative ?
Don't let Alice request that script in the first place. If it's an in-house developed program, query AD for Alice's group membership, and disable the "Run script A" button for users who are not members of Team-A.
Or in the main program thread, test access to \server\Team-B-Only before you create the new restricted process. That will fail for Alice who is only a member of Team-A.
The CreateRestrictedToken API is part of the UAC functionality, have a look at user-account-control-and-remote-restriction which explains how network resources are restricted, the default process to deny access only applies to the administrators group members, so you deny against a normal group is not honoured.
The best solution would be to use constrain delegation, so the script runs in the context of the user, that way the process\script will only be able to access the resources that Alice has access to. However, this we require a front-end service which Alice has to sign-in and you can then use one of the Impersonate function to create a user context to execute the script, but this would also mean the script is executed in real time in the backend.
Another method, is to have a number of service accounts that have the group membership based on the user types that are using the service. The agent will need to have the credentials for each of these service accounts and will start a new process in the context of the account. This does present a few security issues around shared passwords and password management and the number of different user scenarios might mean a complicate user to service accounts matching.
Another method is to update the scripts so they are targeted based on the use cases for each user type so the script controls which shares, folder, or files that are accessed.
Gary.
The contents of the script are not under our control.
This is the reason we have to limit access for the process executing the script.
You would not have to touch the scripts. You would modify the program that that launches the scripts.
Your current solution appears to be: all users can launch all scripts and the ones that the users are not authorized to execute, will just fail due to the deny settings when the process tries to access a file share.
What I am saying is that when your program launches, it should query AD or test the file shares and display a selection menu of only scripts that the user is authorized to run. Don't rely on the script failing, don't let it run in the first place
Hello RoPo-7834,
Thank you for your question.
Are these SIDs from the local (target) domain or the source domain? If it is from the source domain, you will need to perform security translation using ADMT to update the SIDs.
See the article below that deals precisely with a problem similar to yours, I believe it can be useful for you:
https://social.technet.microsoft.com/Forums/windows/en-US/74ea4e62-5907-45ad-a8b6-7de7d2b92b66/share-permission-got-only-sid-and-not-user-friendly-name? forum=winserverDS
You can also check out the article below that talks about "Some SIDs don't turn into friendly names":
----------------------------------------------------------------------------------------------------------------------
If the answer is helpful, please vote positively and accept as an answer.