As a developer, one of the most frustrating things to contend with is the case where you spend countless hours building the perfect solution, debugging and testing and fixing until there’s not a single issue left (ha!), and then finally deploying to a production server just to see your baby crash and burn!  This is particularly common when deploying web applications, and it doesn’t make it any easier when server admins guard their machines so fanatically that us developers aren’t allowed to see so much as a stack trace.

One of the best ways to avoid this scenario is to minimize the amount of configuration that must be performed on the server to install your application.  Traditionally, this was pretty tough to do, but with the introduction of IIS 7, a pretty amazing array of settings can be controlled through web.config files.  This includes, of course, directory security.

Let’s say you’ve built a nice little web site for a new client that has a bit of ASP.NET through in.  There are some XML files in a ‘data’ directory that your code needs but shouldn’t be available through the browser.  You’ve also written a back-end to be used by your client that shouldn’t be exposed to the general public.  This is a pretty typical scenario.  Traditionally, you’d deploy the web site, add the back-end files to a sub-directory called ‘admin’, and then use IIS’s directory security to deny anonymous access to the sub-directory.  Finally, you’d deny all access to the ‘data’ directory. This works.  But let’s look at the problems:

1. Manual server configuration is required.  Is there someone around able and willing to do this?  Often, there isn’t.  In shared hosting environments, this can be particularly troublesome.
2. Deployment considerations change depending on your platform.  This sucks.
3. Permissions suck.  Between file permissions, share permissions, IIS permissions, user accounts, and more, it’s pretty common for things to go mysteriously wrong.
4. What if somebody forgets?  What if a server is rebuilt, and the guy doing the rebuilding doesn’t know about locking down your special folders?  These are not scenarios you want to consider.
5. It’s just not pretty.

Luckily, IIS 7 and ASP.NET bring us a better way.  Open your web.config file, find the <system.web> section, and add this to it:

<deny users="?" />

Now try browsing the site.  You should find that IIS now asks you to log in (or will automatically do so through Windows Authentication).  What’s happening here?  Well, it’s quite simple, really.  You just told ASP.NET to deny access to anonymous users.  Of course, this is great for controlling access site-wide, but what if you want to lock down just one directory?

Many people don’t realize this, but ASP.NET actually checks each directory for web.config files, not just the root.  Any settings specified in a directory’s web.config file apply only to that directory (and it’s children).  Some settings can only be set in the root, but many can be set anywhere.  Security is one of these.  So, let’s say you want to lock down your ‘admin’ directory.  Just add this to a new web.config file and place it in your ‘admin’ folder:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>
</configuration>

Want to secure your data directory, too?  Here’s how to prevent all access to a folder:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="*" />
 </authorization>
 </system.web>
</configuration>

Simple as that!  Now, your site permissions will be included in the site’s files themselves.  Just e-mail your friendly server admin a zip file and enjoy your weekend.

But Wait…!

There’s a catch.  There’s always a catch.

This works perfectly under Visual Studio’s development server.  This will also work just fine under IIS, so long as your site only includes .ASPX and other ASP.NET files.  But, if you happen to use any other file (such as, oh, a JPG image, CSS file, or ZIP file), IIS will ignore your carefully-authored security settings and just hand out everything to everyone.  What the hell?

Don’t blame ASP.NET.  ASP.NET has nothing to do with it.  In fact, that’s exactly the problem.  For static file types, IIS just hands them out without invoking .NET (and hence without consulting your .NET-based security settings).  This makes sense… why slow things down by running a bunch of managed code when you don’t have to?  We’re just serving static files, right?

To fix this problem, you need to configure IIS to run all requests through .NET.  Open web.config (the one in your site’s root) and look for the <system.webServer> section.  Add this to it:

<modules runAllManagedModulesForAllRequests="true">

Note that if this section already exists (which is pretty likely), all you need to do is change <modules> to <modules runAllManagedModulesForAllRequests="true">.

Finally, you might want to retest your site.  You’ll now be getting requests for all file types, regardless of whether the file exists, which might expose bugs you didn’t catch before.

There’s More!

One final bit of help you might appreciate… the ASP.NET Configuration tool built into Visual Studio (check the Project menu) is actually built to help manage site security in exactly this way.  This gives you a nice web-based UI you can use to configure things rather than hand-edit XML yourself.  Just go to Security and look for Access Rules.

Enjoy!

Whelp, here I again find myself having to apologize for the lack of updates on the site recently. Unfortunately, last week I actually broke my ankle and really broke it good. Generally, one should try and stay out of the path of deer jumping onto the road when riding a motorcycle, but I unfortunately decided to occupy the same space in time and place as Bambi  and am now hobbling around on crutches. Anyway, I am fine now and ready to start knocking some updates out for everyone!

With Windows Vista, Windows Server 2008, and now Windows 7 we have seen the introduction of User Access Control (UAC). While this may be the source of a lot of disdain, causing some people to even go so far as outright shutting it off, its importance in the new Windows security regime and architecture cannot be understated. Frankly, shutting it off is silly and will greatly reduce the ability off the OS to fend off malware, spyware,  viruses and worms.  

The whole concept, however, has been muddled by misinformation and is widely misunderstood leaving users completely bewildered when programs mysteriously refuse to work and produce cryptic error messages. For administrators of the `New`OSes (hereinafter referred to collectively as Server 2008,) a thorough understanding of this system is absolutely crucial to keep everything up and running.

In legacy versions of windows, all security functions were encompassed by the user groups themselves and access levels were determined by membership in these groups. Should a person want to slightly reduce administrative authority, the Power Users group was often chosen for this purpose.  In Server 2008, the use of this group is completely unnecessary and it is only kept around for maintaining legacy application compatibility.

Server 2008 is a very different animal. Now, at least in Server 2008 compliant applications, the application manifest itself will define the applications access privileges as RunAsInvoker, RunAsHighest, and RunAsAdmin.

RunAsInvoker: This level results in the application running with the same privileges as the user.  In fact, any user can run the application, but no matter what group they belong to, even if they are in the Administrators group, the program will only run with a standard access token. This concept becomes really important when you get into the windows integrity levels as this fact can cause a program not to function as intended even if run by an administrator. In fact, the only way to get programs that are of the RunAsInvoker type to run as an administrator is to get the parent process running the program to have and administrator access token. This generally means opening up a right clicking on and opening a command prompt window as an administrator. I have heard many people proclaim, when they are told this little fact, that they are “already an administrator” and have watched them click and run a program endlessly without success until they actually run it in an elevated command prompt at which point it magically works.

RunAsHighest: As the name suggests, this runs the application with the highest privileges of the user. Boith standard users and administrators alike, may run the program, but certain program features may not be available based on access privileges. For example, members of the Backup Operators group will be granted fewer rights that an Administrator. Obviously, those who are part of the administrators group will run the program with a full access token.

RunAsAdmin: Only administrators can run programs that have been defined in their manifest as RunAsAdmin type. However, if users can provide Administrator credentials to allow the program to be elevated, or if the program is started from a previously elevated process such as the command prompt it will still run.  This type of program will always run with and Administrator access token.

As well as these run levels, Windows Server 2008 also protects application processes by using integrity levels. All processes in the OS are assigned an integrity level and process with a lower integrity are not allowed to modify those of higher integrity. Internet Explorer, for example, is assigned a fairly low integrity level making it a lot more difficult for it to compromise the OS. As well, the OS will identify the publisher of any program that tried to RunAsAdmin and the OS will flag the potential risk using Red and Yellow colour codes.  Red indicates that the program is from a blocked publisher and there is very likely danger associated with the install.  Yellow signifies “unknown” and Blue/Green are for administrative elevation for server maintenance.

A lot of people ask me how UAC stops malware from entering a system. They seem to feel that malware can easily circumvent this feature. While it is entirely possible that there are ways around it, all of the newer OSes that have UAC are much more difficult to penetrate.  The elevation prompt itself cannot be spoofed and Windows has some very sophisticated algorithms in place to detect any kind of software install in process, which would then trip the UAC elevation prompt. Only Windows Core services is able to bring the elevation prompt up -which, as I have stated, makes it extremely difficult to get around.  UAC is a good thing and I hope that after reading this you will agree.

For all of you developers out there, here is a good little power point on UAC from Microsoft and it outlines some of the design considerations in making a nice UAC compliant app. Give it a whirl, it is obviously in much greater detail than what I have here and an interesting read.

User Account Control- How to Make a Good UAC Application

Next post, I will go over some easy ways of controlling the run levels for all of you server admins out there, and little tricks that can make your life easier.  I hope that all of you are now migrating back into your OS and re-enabling UAC now……

Cheers……

If you try to get Windows Authentication working in IIS for a WCF service (including the one I showed you earlier), you may get the following error:

Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service.

The problem here is that IIS and WCF are fighting over security. You’ve told IIS to prevent Anonymous access and use Windows Authentication instead. WCF, however, knows nothing about this. The answer is simple. Change your web.config file like so:

<?xml version="1.0"?> 
<configuration> 
 
 <system.serviceModel> 
 <services> 
 <service behaviorConfiguration="basicBehavior" name="WCFTest.Test"> 
 <endpoint address="" binding="basicHttpBinding" contract="WCFTest.Test" bindingConfiguration="basicBinding" /> 
 <endpoint address="mex" binding="basicHttpBinding" contract="IMetadataExchange" bindingConfiguration="basicBinding" /> 
 </service> 
 </services> 
 <behaviors> 
 <serviceBehaviors> 
 <behavior name="basicBehavior"> 
 <serviceMetadata httpGetEnabled="true" /> 
 </behavior> 
 </serviceBehaviors> 
 </behaviors> 
 <bindings> 
 <basicHttpBinding> 
 <binding name="basicBinding"> 
 <security mode="TransportCredentialOnly"> 
 <transport clientCredentialType="Windows"/> 
 </security> 
 </binding> 
 </basicHttpBinding> 
 </bindings> 
 </system.serviceModel> 

The key change here is a new binding configuration called basicBinding. Have a look at the <security> and <transport> nodes. These tell WCF that security will be handled by the transport layer, that only credentials will be confirmed, and that it should quit worrying and get back to work.

On newer versions of Windows, you’ll see a message in IE’s Information Bar (the yellow thing at the top that pops down) talking about Intranet Settings.  Most people just click ‘Don’t Show Me this Again’ as they try to get rid of the endless pop-ups and questions IE presents upon its first few runs.  But what does this do, and what happens if you choose the wrong option?

Internet Explorer manages security through Zones.  Most pages you visit will be in the ‘Internet’ zone.  Other zones include Trusted Sites and Restricted Sites, and IE will adjust security settings accordingly.  Finally, there’s the Intranet zone.  This zone enables a few features that wouldn’t be used on the Internet, but are often used inside corporate networks and by software developers and network administrators.  Perhaps most importantly, Windows Authentication is enabled in the Intranet zone.  If you don’t need these features for anything, you’re better off leaving them disabled.  This is the default configuration, and this is how things are left if you choose ‘Don’t Show Me this Again’ from the Information Bar.

Without Intranet settings, though, you’ll find some things might not work properly.  ActiveX controls are handled differently, pages can be rendered differently, and Windows Authentication won’t work.  This means that if you browse to a web server that you should have access to through Windows Security or Active Directory, you’ll be denied access (or prompted for a password).  This will even happen if you’re running as an Administrator trying to access a web server running on your own machine.

To fix this, you need to enable Intranet settings.  If you’re running IE for the first time, you can just click ‘Enable Internet Settings’ from the pop-up.  If you’ve already chosen ‘Don’t Show Me this Again’, you’ll have to go elsewhere to make this change.  Go to Tools, Options, Security.  Select Local Intranet, and then click Sites:

[画像:image]

Clear the ‘Automatically detect intranet network’ checkbox – you read that right, you want the box unchecked to enable Intranet settings – and review the other settings on that window:

[画像:image]

You may have to restart IE for your changes to take effect.

At any time, you can check the zone of the site you’re browsing by looking at the status bar.  If it says ‘Internet’, you’re either on a site that’s not on your Intranet or you have Intranet settings disabled.  If it says ‘Local intranet’, Windows Authentication should work.

So, today I just want to bring to attention a fairly obscure, but, interesting problem that I ran into recently.

I had a client that had several desktop and laptops joined to a Windows Server 2003 domain. All of the computers were running Windows XP Sp2 and for the most part things were fairly smooth. However, one user, started experiencing intermittent failures where his mapped drives were not being setup. Needless to say, he was becoming quite frustrated.

All of the usual troubleshooting of the login scripts was performed, and at one point, some of my colleagues even re-wrote the login scripts from scratch. All of these could be manually executed under our credentials and the drives were successfully mapped, but would mostly fail when ran under the user's own login credentials. It was really odd.

The key point above, however, is that the script would "mostly fail" when run under that users credentials. Soon, it became apparent that anything that was supposed to be mapped from drives located on one particular server wouldn't work and would error out with "System 53" messages etc. Really odd indeed.

We started suspect larger issues were at play and that the domain controllers were not properly replicating. But this begged the question "Why only this one particular user?" Slow link problems might be stopping the login script from running then, we mused...but, on a gigabit connection? Nope, this doesn't make sense. The culprit?...something very obscure and virtually unthought of when dealing with computers in a domain.

What had happened was that the user had cached a blank password for a valid domain user account on his local laptop. The difference between this password and the valid password on the domain controller was causing "Kerebros errors" to appear in the event viewer but yet, would still allow him to log on and use the computer as normal. However, with this wrong password stored, the computer was essentially unable to connect to the domain controller until a valid password was supplied which, of course, would happen long after any login scripts (located on the domain controller he couldn't connect to) would have run and also explained why drives on other servers could be successfully mapped when the login script was manually run on the local machine.

So, where are these passwords stored? On a windows XP machine simply go to the control panel and click on user accounts, then click on advanced, and click on manage passwords. It is in this box where you can cache passwords for logging on to IT resources. Obviously, this feature might be really handy for home computer systems, but can wreak havoc on a machine joined to the domain.

I was thrilled that I had solved the problem and now I am equally excited to share this unusual scenario with my readers. If I can save any of you even 5 minutes in troubleshooting a strange issue like this - I am satisfied.

Cheers!