Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

The customer was using a custom-medium trust security policy which is common across all applications hosted. Therefore we needed to work out which permissions the client's application required on the system. This was achieved in the following way:

1. Copied over the BIN directory with custom assemblies to a windows 2008 R2 server.

2. Downloaded the .NET framework 2.0 SDK from here: https://www.microsoft.com/en-us/download/details.aspx?id=19988

3. Ran the SDK command prompt and ran permcalc.exe with the following command: permcalc – show <assembly> <assembly> etc (you can add more assemblies with a space)

4. This generates an xml file with the required permissions the assemblies require.

The following is sample output from this command.

<?xml version="1.0" ?>

<Assembly>

<Namespace Name="ClassLibrary1">

<Type Name="Class1">

<Method Sig="instance void test()" />

<Method Sig="instance void .ctor()">

<Demand>

<PermissionSet version="1"

class="System.Security.PermissionSet">

<IPermission version="1"

class="System.Security.Permissions.RegistryPermission,
mscorlib,

Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

Read="true" />

<IPermission version="1" class="System.Security.Permissions.FileIOPermission,
mscorlib,

Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

Unrestricted="true" />

</PermissionSet>

</Demand>

<Sandbox>

<PermissionSet version="1"
class="System.Security.PermissionSet">

<IPermission version="1"
class="System.Security.Permissions.RegistryPermission, mscorlib,

Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

Read="true" />

<IPermission version="1"
class="System.Security.Permissions.FileIOPermission, mscorlib,

Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

Unrestricted="true" />

</PermissionSet>

</Sandbox>

</Method>

</Type>

</Namespace>

</Assembly>

Examine the permissions listed in the <Demand> element. These represent the permissions that the assembly needs. In this case, the assembly needs RegistryPermission and FileIOPermission.

<IPermission version="1"
class="System.Security.Permissions.RegistryPermission, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Read="true"
/>

<IPermission version="1"

class="System.Security.Permissions.FileIOPermission,
mscorlib,

Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

Unrestricted="true" />

 5. Add the missing permissions into the policy file and the exception should go away :)

Hope that helps.

Rez

For a case recently I was required to provide a quick sample script to display the logged in user security principal which I have attached to this post. I hope you will also find it useful.

My colleagues from the French team has also posted a similar post on this: https://blogs.msdn.com/b/friis/archive/2013/01/08/asp-net-authentication-test-page.aspx

Thanks,

Rez

UserID.zip

It is now easier than ever to have your own custom error pages that can be reported back to all users or just clients and here are some simple steps on how you can achieve this.

Note: Our focus is on enabling custom error pages at the site level only. You can use this concept to apply the error pages to all sites if you wish.

1. Open the IIS MMC > In the Features view select Error pages 

2. Click on the Edit Feature settings in the right pane 

As you can see there are three choices here for error responses. "Custom error pages" - specifies that all requests (local or remote) are sent custom error pages. "Detailed errors" - specifies that all requests receive the default HTTP error pages. "Detailed errors for local requests and custom error pages for remote requests" - specifies that local requests are sent detailed error pages and remote requests are sent the custom error pages.

3. For the purposes of this walkthrough, I will select the last option as we want requests made on the server to receive detailed pages explaining the exact issue for troubleshooting. Leave the rest as default. > OK

4. In the right pane select Add and type in a custom status code. Remember that you cannot overwrite an existing one so you must delete it and then create a new one. We will create two, HTTP 401.1 - user access denied and HTTP 401.2 - denied by server configuration.

5. You can place the error pages within a physical directory located in your web content directory. In this example I have created a folder called custerr located in c:\inetpub\wwwroot with two custom error pages 401.1 and 401.2. The file path field takes a relative path as its value.

The "Execute a URL on this site" option allows you to specify a URL instead of a file path to your error page. This way the error page is displayed physically in the URL with the appropriate name in the address bar.

The "Respond with a 302 redirect" options redirects users to an absolute URL.

6. You should now see your custom error pages in the features view. Note: you can determine if the error page is specified at the root level or at the site/virtual dir level simply by viewing the "entry type" column. If its set to local then its set at the site/virtual dir level only otherwise it will be an inherited type.

7. Now open a browser window and browse to a site with Windows Integrated Authentication enabled. Enter a bad username/password combination and you should then see your detailed error page display on the server. Now test from a remote machine and you should see your custom error page.

See simple!

So where is this information stored?

Its all in the web.config file. So here you can manually edit and remove as and when necessary. One thing to note, if you remove the default HTTP error page references from the config file, you can simple start again by removing these custom HTTP error references to restore it back to the default.

So to summarise:

1. Opened IIS MMC and navigated to the website.

2. Clicked Error pages and selected the edit feature.

3. Selected display custom error pages and detailed pages.

4. Specified a relative path to the custom error pages which
were located in the root of the website content.

5. Browsed the site and made sure we get a prompt for
credentials, we did and we saw our custom error page when the correct
credentials were not entered.

Hope that helps.

We have found an internal article that mentions that the reason for the 250KB limit is to reduce the chances of an attacker uploading a large web.config file. This is not just for migration of websites but also when deploying such large web.config files into existing website builds.

The upper value of this limit can be changed by modifying the following registry key:

Note If you configure IIS 7.0 and IIS 7.5 to run in 32-bit mode on Windows Server 2008 x64 or on Windows Server 2008 R2 x 64, the registry key is instead the following:

The alternative to changing the default value is to split up the web.config files in to separate files. The benefits of this are, reduced chances of denial of service attacks, by specifying authorization rules to determine who can edit it whilst still keeping the default 250KB value. Also it allows better manageability of the files and reduces the impact of human error.

More information on how to do this can be found here:

https://www.iis.net/learn/get-started/planning-your-iis-architecture/getting-started-with-configuration-in-iis-7-and-above

https://netrsc.blogspot.co.uk/2006/05/how-to-split-webconfig-sections-into.html

https://www.davidturvey.com/blog/index.php/2009/10/how-to-split-the-web-config-into-mutliple-files/

Note: Make sure you use .config as the extension of your files so they cannot be served to the browser.

https://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource.aspx

 HTH

Rezwan Rahman

It is not an uncommon scenario to have a web farm of servers sitting behind a load balancer. In fact that is the only way you can achieve high availability so it is recommended.One issue that arises when this setup is used is when the user session needs to be persisted across all the servers.  For example, a request comes in through the load balancer to MachineA. IIS runs the site, a session is created, information is stored in it and the site is appearing functional. Now imagine if something happened to MachineA to take it offline, the load balancer would take it out of rotation and the next request would go to a different machine, which has no knowledge of the previous session and so it would appear to the user as if the site had reset itself or something had gone wrong.

There are many well documented ways to setup shared session state, either using a session state server or a SQL server, but there is one situation where you can run into issues with the session being unreadable by all machines. This can occur when your server farm consists of a mix of IIS6 and IIS7/7.5 machines.

Consider the architecture in the diagram. A request could come in, be served by the first IIS6 box which would create the session and store onto the state server. The next request from the same user could be routed to an IIS7 box, and in this case there is a chance that IIS7 cannot decrypt the session, and you would end up with an error presented to the user.
This is down to the encryption key, decryption key and the encryption method that is set on each server in the machine.config. These need to be the same in order for every server to be read the session.

Also, if you web farm is hosting multiple sites in IIS, there is one more setting that you need to be aware of. In most cases, if you have one website, it will have an application ID of 1 inside IIS, but as you add more sites, the application ID will be mismatched across servers.

The session ID that is used in the session state server is actually a hash of the application id and the user session ID, so if your applications do not have the same application ID inside your IIS instances on all servers, when another server looks up the session, it will fail as it is looking for a session but created with a different ApplicationID.

Setting ApplicationID in IIS7+

To set this in IIS7+, it is very easy. Simply open IIS Manger, and then drill down into your site, and the in the Action Pane, open the “Advanced Settings”. Inside there, there is an ID field. Set this to the same on every server for each site.

Setting ApplicationID in IIS6

The simplest way of doing this is to use the admin scripts:

1. Open an elevated command line
2. Navigate to your AdminScripts directory (be default in c:\Inetpub\AdminScripts).
3. And run this script:

                   cscript adsutil.vbs move w3svc/999 w3svc/2

            (Where the first is the old Site ID and the second is the new one)

The other manual way is to edit the MetaBase.xml, and update the IDs. If you don’t get them all right, the IIS server won’t start, so take care when doing this.

Once all the site ID's and the machine keys are the same, then all your sessions should be available to all systems, irrelevant of OS, IIS version or State Management system.

Hope it helps!

Alex Olivier

2011-11-07T15:16:28.8528558+00:00 Error Primary & Farm Server1 Failed to run operation ‘RunRemote’.  Failed to run method ‘Microsoft.Web.Farm.GetInstalledProductsRemoteMethod’ on server ‘Server1′.  Exception in response stream.  InternetOpenUrl returned 0x80072EFD: Unknown error 12029.  Exception in response stream.  InternetOpenUrl returned 0x80072EFD: Unknown error 12029. Microsoft.Web.Farm.WebFarmException: Failed to run method ‘Microsoft.Web.Farm.GetInstalledProductsRemoteMethod’ on server ‘Server1′.  Exception in response stream.  InternetOpenUrl returned 0x80072EFD: Unknown error 12029. —> Microsoft.Web.Farm.WebFarmException: Exception in response stream —> System.Net.WebException: InternetOpenUrl returned 0x80072EFD: Unknown error 12029.

In WFF 2.2, you can set a proxy server that all your servers will use in your applicationHost.config. This setting will be passed to all your servers for their calls out to the Web Products Feed xml file used by Web Platform Installer. You can set this using the following appcmd:

appcmd.exe set config -section:webFarms /[name='Primary'].defaultProxy.enabled:"True" /[name='Primary'].defaultProxy.proxyaddress:"proxyservername:80" /[name='Primary'].defaultProxy.userName:"testuser" /[name='Primary'].defaultProxy.password:"Password1" /commit:apphost

You will need to replace the name of your webfarm where it says ‘Primary’ and put your proxy details where it says “proxyservername:80″. If you proxy requires authentication, replace “testuser” and “Password1″ with the username and password respectively.

The same settings in the applicationHost.config XML format is as follows and needs to be inside the WebFarm node: 

<defaultProxy enabled="true" proxyaddress="proxyservername:80" userName="testuser" password="Password1" />

Web Farm Framework is a very powerful system for managing your content servers, and using it behind a proxy is a very common scenario, so hopefully this will help you when configuring and troubleshooting internet connectivity issues.

Hope it helps!

Alex Olivier

Creating a brand new FTP site

1.       Open the IIS Manager > Right click the Websites root > Add ftp site

2.       In the “Add FTP site” dialog box enter the FTP Site name and the physical path of the directory. In this example we will call the site “FTP” and the physical path will point to C:\Inetpub\Ftproot (not very creative J) > Next

3.       In the next screen assign a static IP address, port number and a Virtual host name depending on preference.  In this case we will leave the default settings and select “Allow SSL”. Note: For production use you will need to request an authentication type certificate from the certification authority.

4.       Select Anonymous authentication and set the Authorization to all “All users” access to this ftp directory. Set both read/write properties. 

5.       Test access to your newly created ftp site using MS FTP using the command line or any third party FTP software. In our example we will be using FileZilla.

Create an IIS managed user and ftp user isolation

6.       Create two directories as follows:

• C:\inetpub\ftproot\LocalUser\rez (name of the user that will have access to their folder.

• C:\inetpub\adminfiles (this is for administrative access)

7.       In the IIS manager, select the webserver > click on “management service” under the “management” subheading (if it’s missing, add it in via a role service).

8.       Under the connections sub group select an SSL certificate, in my case I am using a self-signed certificate called FTPS. Note: in production obtain a valid certificate from a certificate authority. Under the identity sub group select “Windows credentials or IIS Manager credentials” radio button. Specify any restrictions if you like under the IPv4 address restrictions to reject requests from certain machines. We will leave this out for now. 

9.       Start the management service from the actions pane and you should see the following:

10.   Select the server name in IIS again and double click IIS manager users under the management sub group > add user from the actions pane and create a new user. In this example we will create a user named “rez”. Make sure this user is enabled.

11.   Click on the ftp site and select authentication > from there click custom providers from the actions pane and add the “IISAuthMan Custom provider”. Make sure it’s enabled and disable all other authentication protocols.

12.   Click on the IIS Manager permissions under the ftp site and make sure your user is allowed. In my example “rez” has been set to the “allow user”. You can also specify this user access to the ftp site under the FTP authorisation.

13.   Now create a new virtual directory under your ftp site pointing to C:\inetpub\adminfiles

14.   Click on “FTP User Isolation” and select “User name directory (disable global virtual directories)”. This will restrict user’s access to their own directories only. They will not be able to view any newly created virtual directories at the ftproot level. The result will be the following:

As you can see Rest.txt is within this “rez” directory.

So to summarise we:

1. created a brand new test ftp site

2. created a folder structure to allow administrative access as well as specific directory access to an ftp user

3. created a new IIS managed user account

4. tested user ftp isolation

Hope that helps.

Rezwan Rahman

Strong names guarantee name uniqueness by relying on unique key
pairs. No one can generate the same assembly name that you can, because an
assembly generated with one private key has a different name than an assembly
generated with another private key.

Strong names protect the version lineage of an assembly. A strong
name can ensure that no one can produce a subsequent version of your assembly.
Users can be sure that a version of the assembly they are loading comes from
the same publisher that created the version the application was built with.

Strong names provide a strong integrity check. Passing the .NET
Framework security checks guarantees that the contents of the assembly have not
been changed since it was built. Note, however, that strong names in and of themselves do not imply a
level of trust like that provided, for example, by a digital signature and supporting certificate.

https://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

Creating a self-signed certificate using Makecert.exe

Create a self-signed certificate using Makecert.exe.

Open an elevated command prompt and navigate to C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin>

Then run the following command to create a self-signed certificate. 

C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin>makecert –r –pe –n “CN=<cert name>” –b <beginning date> -e <end date> -sky <subject key type> -ss <cert store>

I have used an x.500 certificate name of “RezSign” but you can choose to use any name you like. (If you would like to know what each of the switches mean,
please view this article: https://msdn.microsoft.com/en-US/library/bfsktky3(v=VS.80).aspx)

Press enter and you should see a “succeeded” message as in figure 1.

Figure 1

Check if the new self-signed certificate exists in the certificate store

Run “mmc” from a run command and add the certificates snap in.

In the certificates window, select the Personal Store > Certificates and view the list of certificates in the “My User Account” store.

Find the newly created certificate via the CN name specified earlier and double click it to view the certificate details.

You should see something similar to the screenshot in Figure 2. Make sure the message “You have a private key that corresponds to this certificate.” exists as shown.

Figure 2

Click on the details tab and select “edit properties”.

You will notice in the general tab that you have a selection of certificate purposes. By default all certificate purposes will be selected but you can narrow down the scope as desired.

Note: we are only interested in the “code signing” purpose. So when requesting a certificate from a CA make sure you mention this. See figure 3 for more information.

Figure 3

Exporting the certificate

Right click this certificate > All Tasks > Export.

In the certificate export wizard, click next and select “Yes, export the private key” > Next

In the export file format screen, select “Personal Information Exchange –PKCS #12(.pfx) and check the “include all certificates in the certification path if possible” and “Export all extended properties” checkboxes > Next

Provide a password for the file in the next screen and give your file to export a name. Use the same naming format as used earlier > next > finish.

You should now see the exported .pfx file in the location you saved it in.

Importing the certificate with keyspec 2 (AT_SIGNATURE)

Note: we could have saved doing this stage if we ran the “–sky signature” during the self-signed certificate creation process.
However this is intended to be a guide to cover a scenario where you receive a certificate from a certificate authority that has specified the “-sky exchange” keyspec.

Backup your existing certificate in the certificate manager.

Open an elevated command prompt and import the pfx file we exported earlier using this command line:

certutil -importPFX -user <pfxfilename> AT_SIGNATURE

This will reimport the certificate we exported previously but will switch it from using KeySpec 1(AT_KEYEXCHANGE) to KeySpec 2(AT_SIGNATURE)

Enter the password for your certificate when prompted. You should then see the output as shown in figure 4. 

 
Figure 4

Refresh the personal certificates store in the certificates console and make sure the newly imported certificate exists.

Now re-export this new certificate as you did earlier so we can use it to sign our assemblies.

Importing the certificate into your project

Open your solution in visual studio and right click the root > properties

Click on the signing selection and check the “Sign the assembly” box.

Choose your exported “.pfx” file under the “Choose a strong name key file” dropdown box. Enter the password for it when prompted.

Sign the assemblies with the certificate

Build the solution to generate a dll in your bin directory.

Right click the dll > properties and make a note of the tabs that display. You will notice there isn’t one listed for “digital signatures”.

Now open an elevated command prompt and run the following command:

C:\Program Files (x86)\Windows Kits\8.0\bin\x86>signtool sign /f “<location of pfx file>” /p “<password>” /v “<location of the dll to sign>”

You should see the following in Figure 5, if executed successfully:

Figure 5

Now go back to the dll you signed and select properties. Notice that there is a “Digital Signatures” tab now.  As shown in Figure 6.

Figure 6

Note: When you obtain a certificate from a reputable certification authority they will have a timestamp server which you can use to populate the “signing time” field with.

Congratulations you now have a digitally signed assembly.

Summary

We created a self-signed certificate using makecert.exe.

We learnt how to change the key exchange property for the certificate using certutil.exe.

We checked the purpose of the certificate to determine if it’s eligible for code signing use.

We digitally signed our assembly using the signtool.exe.

HTH

Rezwan Rahman

To reproduce this issue, we can add a REG DWORD  "DeleteFlag"  with a  value 00000001 at[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSFtpsvc] on a Win 2003 server which has FTP installed and restart the server. The service will be deleted on restart.

For Win2k8 R2, IIS 7.5, the location is [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ftpsvc] but the key is same, a DWORD "DeleteFlag" set to 00000001.

This might have happened due to third party software or a bad uninstallation accompanied with some permission issues due to which the MSFTPSvc/ftpsvc key could not be deleted. The solution is to delete/rename the "DeleteFlag" key from the respective locations.

We had a .net 3.5 web service hosted on IIS 7.0. We have configured it to accept a client certificate with a 1-to-1 mapping to a domain account. When presented with the cert the service appears to run as the account ok but it seems it cannot use delegation when connecting to SQL Server and fails with following error message:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'”

We confirmed that client certificate mapping and kerberos settings required to make this work were in place.

Also the similar setup works fine on IIS 6.0. So the issue happens only with IIS 7.0 when using client certificate for delegation.

First is to understand the different logon types that Windows supports and what their capabilities are. I have listed only ones that we have come across here in this issue.

2 - Interactive - Intended for users who will be interactively using the machine, such as a user being logged on by a terminal server, remote shell, or similar process.

3 - Network - Intended for high performance servers to authenticate clear text passwords. LogonUser does not cache credentials for this logon type.

8 - NetworkCleartext - Windows 2000; Windows XP and Windows Server 2003 family: Preserves the name and password in the authentication packages, allowing the server to make connections to other network servers while impersonating the client. This allows a server to accept clear text credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers.

In IIS 6.0 & 7.0 when calling the LogonMethodEx API, the default type that is used is type 8 (Network Clear Text). This allows an NTLM connection between the IIS server and a backend server for anything that uses
type 8. This includes Basic authentication, anonymous authentication (for IIS 6.0 only), and IIS certificate mapping authentication (but not AD certificate mapped authentication). The IIS client certificate mapping type is what applies to your situation.

In the IIS_schema.xml there is an enumeration under iisClientCertificateMappingAuthentication called "logonMethod" that has the following information:

<enum name="Interactive" value="0" />

<enum name="Batch" value="1" />

<enum name="Network" value="2" />

<enum name="ClearText" value="3" />

These enumeration names/values are what are exposed to an administrator to help control how IIS logs on a user mapped to a client certificate. The default setting is "ClearText" which is equivalent to NetworkClearText.

When a user is logged on using IIS client certificate mapping, the logic used returns a value of “3” instead of “8”. So the user is logged on with a “Network” token instead of the expected type “NetworkClearText”. Network tokens cannot be passed to a backend service so this configuration results in "NT AUTHORITY\ANONYMOUS" being passed to SQL which fails.

WORK AROUND:

We can change the values of the above enumeration to the following:

<enum name="Interactive" value="2" />

<enum name="Batch" value="4" />

<enum name="Network" value="3" />

<enum name="ClearText" value="8" />

To enable saving of the IIS_schema.xml file we need to:

1. Give "ownership" of the "C:\Windows\System32\inetsrv\config\schema" folder to Administrators under the "Advanced" button of the "Security" tab of the schema folder properties.

2. Give "Full Control" to Administrators on the Permissions tab.

3. Remove the "Read Only" attribute from IIS_schema.xml.

Update: This issue is already fixed in IIS 7.5 (Windows 2008 R2). No schema changes are required.

References:

https://blogs.msdn.com/b/saurabh_singh/archive/2008/12/25/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx

https://msdn.microsoft.com/en-us/library/aa291350(VS.71).aspx

Cross posted from my blog: https://blogs.msdn.com/b/amol/archive/2011/09/23/issues-when-using-asp-net-delegation-with-client-certificate-mapping-on-iis-7-x.aspx