Suppose you have a web application which authenticates clients through a smartcard certificate and everything is working fine, then you decide to move your web application to Windows Server 2008 (which is a good decision in many ways ?) but your users are suddenly complaining about slow performance, pages are loading slower than they used to do and you cannot find any explanation on the network infrastructure, everything seems to be properly configured on the client and on the server… what is happening? Well, as you can imagine this is what happened to a customer I worked with recently. A closer look at the client showed that every time a new object in the page was loaded (images, script files, css…) the smartcard was checked for the certificate, resulting in a major performance loss. To make the story short, the behavior is controlled by client certificate negotiation, specifically by SSLAlwaysNegoClientCert which in IIS 7 has been moved to http.sys (see http://learn.iis.net/page.aspx/110/changes-between-iis-60-and-iis-7-security/); you can configure the <access> element as described or using netsh with a command such as the following: netsh http add sslcert ipport=0.0.0.0:$port certstorename=MY certhash=$Certhash appid=$Appnr sslctlidentifier=$CTLlijst sslctlstorename=CA clientcertnegotiation=enable Carlo Quote of the day: Human beings are perhaps never…
-
-
When Vista denies you access to “your” files…
For my work I have two desktops and a laptop I always bring with me, and despite all the online synchronization tools out there (SkyDrive, FolderShare, Groove, Mesh etc…) I’m used to SyncToy to keep my important files and folders updated across the three machines; The same is true for my backup .pst files: the laptop is my main machine, I usually make my changes and archives there and then copy the pst on the other two machines. But since Vista (and now also with Windows 2008) when I copy the new file and then try to load the data file in Outlook, I always get an access denied error: Clearly a permission issue and running Outlook with elevated privileges resolves the problem; but explicitly granting Full Control to my account (by the way, I’m member of the Administrators group), taking ownership of the file etc… is not enough, I was still unable to open the file (and I don’t want to run Outlook as Administrator). After many attempts as a last resource I tried to create through Outlook a new empty pst file with the same name of my archive one, and then I overridden it the file I…
-
Remember to undo your impersonation
A couple of weeks ago I got an interesting query from a customer, whom had a problem impersonating a service user account by code; the design was a bit more complicated, though: Impersonation not set in web.config By code they needed to impersonate the account logged on the client issuing the HTTP request (this worked fine) By code they needed to impersonate a service account they used to access a backend database (here they were getting an access denied error) Switch back to the previous user, the one logged on the client (again this was working fine) This was quite clearly an impersonation problem, and after some debugging we found the “Access Denied” was being thrown when executing the line highlighted in red in the following snippet, way before even trying to access the network to read the backend database: 1: If CType(LogonUser(username, domain, password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, token), Boolean) Then 2: If DuplicateToken(token, 2, tokenDuplicate) Then 3: Dim identity As New WindowsIdentity(tokenDuplicate) 4: If System.Web.HttpContext.Current Is Nothing Then 5: Dim mImpersonatedContext As WindowsImpersonationContext = identity.Impersonate 6: Else 7: System.Web.HttpContext.Current.Items("ImpersonationContext") = identity.Impersonate 8: End If 9: End If 10: [...] In the screenshot below you can see the “Access Denied” message…
-
Security bug in Vista recovery console? Well… not quite…
My colleague Feliciano Intini (Chief Security Advisor here at Microsoft Italy) just pointed me to his post were he comments about a news which is (re)spreading across the web about a security hole in the recovery console in Windows Vista: if you can read Italian here is the post, otherwise go on an ready my translation. Third episode of my anti-FUD column. True story (unfortunately): a few days ago someone has stolen the motorbike of a colleague of mine whom was working at a customer’s site.How was the bike protected? With that special padlock which locks the front wheel, without any sort of chain to fasten to a physical stand. How did they stole the bike? They arrived with a truck, a few guys got off it and they loaded the bike by sheer force in less than 5 minutes! What do I want to say? Here is a fundamental concept in security field: physical security is the basis for all security. False fact: I’m reading in various posts which quote an article by Finnish Kimmo Rousku, which Windows Vista apparently has a security hole which “allows to gain unlimited access to anyone who has physical access to the pc, even if…
-
Code Access Security hosting control in IE
PROBLEM You have a Windows Forms component hosted in Internet Explorer, and you want to catch events raised by this control from client side scripting; to avoid security errors at runtime, the control must have “Allow calls to unmanaged assemblies” permission. if you do this, you’ll notice that this works only if you give this permission to the whole Zone or Site, but does not work if you give it just to the Assembly or the URL. REASON The reasoning behind the security exception is AppDomains. Before IE can load your assembly, it must create an AppDomain to load the assembly into. When it creates this AppDomain, it assigns all the evidence it knows without loading your assembly, the Site and Zone that it is loading from. Since the AppDomain itself does not get any evidence about the signature that your assembly has (it can’t since the assembly is not loaded yet), it will not match the code group that you created giving extra trust. Now when a security demand occurs, a stack walk begins. When your assembly is checked for correct permissions, it passes, and the stack walk continues until it gets to the AppDomain. Since the AppDomain doesn’t…