Security considerations

Unless configured differently, ShellBoost server applications loaded in the same desktop as the Windows Shell, like Console, WPF and Winforms applications, should be running under the same credentials as Windows Explorer. This is also true for other applications that could load implicitly the ShellBoost native proxy, through the Common File Dialogs for example.

But ShellBoost also supports Windows Services. A Windows Service is probably not going to be running under the same credentials as users working with their Windows Shell in their desktop. In this case, the ShellBoost developer can choose to impersonate the client user (run “as” the user, with the user’s credentials), or not. Impersonation is a global setting that must be set or not at application start time. By default, ShellBoost enables client impersonation.

In any cases, even with impersonation disabled, the ShellBoost developer can determine client identity and client process identifier using the ShellContext class.

Here is an extract from the Folder Service sample. The root folder services 5 items that just display diagnostic-type information, for demonstration purposes:

public class RootFolder : RootShellFolder
    public RootFolder(OverviewShellFolderServer server, ShellItemIdList idList)
        : base(idList)
        Server = server;
    public OverviewShellFolderServer Server { get; }
    public override IEnumerable<ShellItem> EnumItems(SHCONTF options)
        yield return new SimpleItem(this, "Client Principal Name: " + ShellContext.Current.ClientPrincipalName);
        yield return new SimpleItem(this, "Client Process Id: " + ShellContext.Current.ClientProcessId);
        yield return new SimpleItem(this, "Client Process: " + Process.GetProcessById(ShellContext.Current.ClientProcessId)?.ProcessName);
        // if we impersonate, this will be the same as the client principal name
        // otherwise it will be the identity that runs the service process
        yield return new SimpleItem(this, "Server Windows Identity: " + WindowsIdentity.GetCurrent()?.Name);
        yield return new SimpleItem(this, "Server Process: " + Process.GetCurrentProcess().ProcessName);

The service’s OnStart() method is coded like this:

protected override void OnStart(string[] args)
    _server = new OverviewShellFolderServer();
    var config = new ShellFolderConfiguration();
    config.ImpersonateClient = true; // true is the default
    config.NativeDllRegistration = RegistrationMode.User;

As you can see below, the service is configured to run as “Local System”.

Security considerations - Picture 31

And this is what we see in our ShellBoost namespace extension:

Security considerations - Picture 32

This information is computed from the ShellBoost.Samples.FolderService.exe, running as “Local System”. Since the user is impersonated, the Service Windows Identity name is the same as the client principal name. We can see the client process is explorer (.exe).

If we change the startup code like this (stop the service, recompile, restart the service, refresh explorer):

config.ImpersonateClient = false;

This is what we see in our ShellBoost namespace extension:

Security considerations - Picture 33

Now, the Service Windows Identity is NT AUTHORITY\SYSTEM (which is “Local Service”). We still have the correct client information available, though.

Note : custom UI is not supported from Windows Services, since they cannot interact with desktops.