RESOLUTION 1When the Federated Authentication endpoint sends an authorization request with a user name via SAML, IIS on the Active Roles Web Interface host can generate a Windows token by impersonation. However, this token can only be used to access remote resources only if the account running the ARWebAppPool IIS Application Pool has the privilege to
Act as part of the operating system (SeTcbPrivilege)If only one remote Active Roles Web Interface host is needed, the ARWebAppPool can be run as the LocalSystem account, which has
SeTcbPrivilege by default. If more than one remote Active Roles Web Interface host is needed, then Kerberos SPN requirements mean that the ARWebAppPool must be run as an Active Directory service account that has the
SeTcbPrivilege explicitly granted.
- Select Control Panel | Administrative Tools | Local Security Settings
- In the left panel, select Security Settings | Local Policies | User Rights Assignment
- Open Act as part of operating system
- In the Act as part of the operating system properties dialog box, click Add User or Group
- In the Add User or Group dialog box, enter the desired Active Directory service account and click OK.
- Click OK to close the properties dialog box
NOTE: If the
Add button is greyed out, then there is a Group Policy which is preventing local changes. Instead, add the desired Active Directory service account into the Group Policy for this privilege on the Active Roles Web Interface host(s).
RESOLUTION 2
- As an Active Roles Admin, delete the problem site in the Active Roles Configuration Center
- With Local Administration privileges, navigate to %WinDir%\System32\Inetsrv\Config on the Active Roles Web Interface host
- Create a copy of the applicationHost.config file in a safe location
- Edit this file and remove any references to the problem site
NOTE: Be sure to remove the entire section that contains the reference. For example, if the reference is in a <location> tag, remove the open location tag, the closing location tag, and everything in between.
For example, if the file looks like this and the "BadSite" reference should be removed:
<location path="Default Web Site/GoodSite">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="true" />
<anonymousAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
<location path="Default Web Site/BadSite">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="true" />
<anonymousAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
<location path="Default Web Site/GoodSite2">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="true" />
<anonymousAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
After modification, this section of the file should look like this:
<location path="Default Web Site/GoodSite">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="true" />
<anonymousAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
<location path="Default Web Site/GoodSite2">
<system.webServer>
<security>
<authentication>
<digestAuthentication enabled="false" />
<basicAuthentication enabled="true" />
<anonymousAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
- Save the applicationHost.config file
- In an elevated command prompt, run IISRESET
- As an Active Roles Admin, recreate the site in the Active Roles Configuration Center and apply the desired Active Roles Web Interface configuration