Security Delegation
In the typical Windows network, when a user makes a request from a service, if the service needs to connects to a different computer to fulfill the request, it connects using its own account (or application pool identity if it is a web service).
Examples are:
-
Meridian Enterprise and PowerWeb running on separate servers
-
Meridian Enterprise, Accruent Publisher, and Meridian Explorer running on separate servers
This has ramifications for Meridian Enterprise security. For example, the requesting service account must have all of the permissions granted to it that would be needed by any combination of potential users, document types, and areas of the vault. This makes enforcing very specific or granular security difficult if not impossible. It may also have ramifications on the metadata. For example, document properties that are modified by the request will show the service account name in the Modified By property or in the document log. This can make security auditing problematic.
To overcome these problems, the environment can be configured to allow security delegation, in which the service impersonates the requesting user by connecting to the other computer using the user’s account to fulfill the request. The user’s account credentials are delegated to the service. At first glance, delegation may seem to be the perfect solution. However, impersonation creates what is known as the double hop problem, which requires additional configuration.
By default, Meridian Enterprise Server assumes that security delegation has been configured. Delegation and impersonation can be disabled in Meridian Enterprise Server by adding the following setting to the file C:\ProgramData\BlueCieloECM\Hyperion\WebConfigDto.dat.
"DisableImpersonationForBCM":true,
-
This setting affects changes initiated from feedback type property pages and VBScript events. Examples are users adding comments to documents from Meridian Explorer and viewing print previews when watermarks are configured to be shown. In both examples, Meridian Enterprise Server needs to connect to the Meridian Enterprise server to read or save data that can be protected by security privileges that the application pool identity might not have been granted.
-
Also see the registry value SameIISEDMAccount in HKEY_LOCAL_MACHINE\Software\Cyco\AutoManager Meridian\CurrentVersion\WebLink.
-
In Meridian Enterprise Server 2012 SP5, the name of this setting is FeedbackNoImpersonation.
Following are some guidelines to help you determine if you need to configure security delegation.
-
If the system works as expected and access errors do not occur or if the services run on the same computer, delegation is not necessary and you do not need to disable impersonation.
-
If the lack of security delegation is causing problems, you have two options:
-
If it's acceptable to your organization that for all Meridian Explorer users, feedback to the Meridian Enterprise vault (redlines, comments, property updates, VBScript procedures) are performed under the service account, then disabling the impersonation is an easy way to avoid the delegation issue.
-
You must resolve the double hop problem by configuring security delegation.
-
Following are links to resources that explain this requirement in more detail and provide configuration assistance:
-
How to Configure the Server to be Trusted for Delegation on the Microsoft TechNet website
-
How to configure an ASP.NET application for a delegation scenario on the Microsoft Support website
-
Understanding Kerberos Double Hop on the Microsoft TechNet website