Thursday, December 27, 2007

WebDAV is a way to publish files to your server. I've been a fan since I first saw it and have been teaching people about it for years. When you have everything setup correctly, you can open a web folder in Network Places (or neighborhood or whatever), or on your desktop, and when you drag and drop files into the folder, it publishes over the network using http to the server. Unfortunately, the story about DAV from Microsoft's end has been rather mottled. The specifics of what is possible using DAV, how it appears and behaves depends on the precise combination of which server you're using (DAV was supported on IIS 5 as well), the client (XP, 2000, Vista), and what application you use to do the DAV connection (Explorer, IE, Office, FrontPage).

However, in IIS 7, there is some very good news. Robert McMurray on the IIS team is the same guy that manages the FTP 7 project. He has improved, the DAV story for IIS 7 in many ways. I've had the chance to chat with him on numerous occasions about his vision and hopes for DAV and other publishing protocols and can tell you that he's the right guy for the job.

One of the biggest improvements is that DAV can be enabled per URL. In IIS 6, and 5, DAV was either functional for all sites or not. Now, you can use it just where you need it. The IIS 7 DAV provider integrates with the IIS 7 UI and leverages IIS 7 URL Authorization. URL Auth lets you allow or deny access to content using web.config files instead of ACLS.

This version of DAV is the SERVER side component. The client side will use one of the various providers mentioned earlier - but should work by simply creating a network connection to a dav enabled URL. One way to do this is in IE, using File, Open and selecting the checkbox "open as a web folder".

Once you setup DAV and get used to using it, you'll wonder how you managed without it.

http://blogs.iis.net/robert_mcmurray/archive/2007/12/22/webdav-module-for-windows-server-2008-golive-beta-is-released.aspx

 

-brett

IIS | IIS 7 | ITPro | Microsoft  | publishing | Security | Vista
Thursday, December 27, 2007 6:34:00 PM (GMT Standard Time, UTC+00:00)  #    Comments [2]  |  kick it on DotNetKicks.com
Saturday, October 13, 2007

By special request, here's an outline of the users and groups used by IIS and what they do.

IIS 5 and 6

- IUSR_<servermame> - this is the default anon user for IIS 4, 5, and 6. It is a local account with a large, random password. The account does not exist until IIS is installed. IIS is installed by default on Windows 2000 but not 2003. If you disable this account, anon authentication will fail unless you create assign a new one. This user is a member of Everyone, Users, Authenicated Users, Guests, and the Network built in account (by default).

- IWAM_<servername> - this guy is found on IIS 5 and on IIS 6. I don't recall if it's in IIS 4 as I haven't laid eyes in an IIS 4 server in about 5 years. In IIS 6, it is only used when you run your server in IIS 5 mode, called IIS 5 worker process isolation mode or some such overly long phrase. In this case, sites  and application that are set to run in medium or high isolation run in dllhost.exe as the IWAM_<servername> user.

- ASPNET - this is a local account used to launch the aspnet_wp.exe on IIS 5 and in IIS 6 when it runs in IIS 5 mode.See http://msdn2.microsoft.com/en-us/library/bakfs900(VS.80).aspx for details on how to control the identity of asp_net.exe. It is not typically used in IIS 6 and is not supported on IIS 7.

- IIS_WPG - This is a local group on Windows Server 2003 that is used for one purpose. The IIS _WPG has rights to register application pools with http.sys. What this means is that that if you assign an application pool a unique idenity, you must also add them to this group. By default, this group has the System, Local Service and Network Service accounts in it. By default, application pools on IIS 6 use the Network Service account. If you don't assign custom application pool idenities, you don't need to mess with the membership of this group. Do not delete this group, espcially on a domain controller.

IIS 7

Doesn't have any of the above accounts. Instead you'll find:

- IUSR - built in account for Windows Server 2008 and Vista. Created when IIS 7 is instaled. The IUSR account has the same SID on all Windows Server 2008 systems and Vista. A built in account is different than a local account. Built in accounts cannot be used to log in locally to the server so they don't have a password.

- IUSRS - This is the updated version of the IIS_WPG for IIS 7. The new coolness is that has autmatically maintained membership.

-------

What runs as who when?

For anonymous access, the request will be the run as the assinged anonymous user (preusming that anon authentication is enabled and the anon user has the required access rights). If the request is for ASP.net, subsequent page requests and background operations will access the file system as the process identity (this is the default behavior). Most of the time this is the Network Service account on IIS 6 or the ASPNET user on IIS 5. If not using ASP.net, file access for will be as the anonymous user unless the application your a running reverts to the process identity to do something on the server that the user does not have rights to do. There are quite a few more complications of course, but this typically how things go.

To do research about this, your best friend is Filemon.exe. I learned most of the limited knowledge I have about this by messing around with Filemon and permissions. When you set Deny Full Control, Everyone on a file and then access the file in the web application while Filemon is running, the Access Denied in Filemon will also show you the user that was denied access. Another fun tool to play with is w3ho.dll, a resource kit utility.

Hopefully this is useful.

Let me know

-brett

 

 

IIS | ITPro | Security
Saturday, October 13, 2007 10:43:50 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]  |  kick it on DotNetKicks.com
Tuesday, May 08, 2007

I'm going on a roadtrip to Europe for two weeks to present a 1 day class on IIS 7! There are actually two teams of two and I'm on the 2nd team leaving in two weeks for two weeks. (see http://blogs.iis.net/rickjames/archive/2007/05/06/iis-7-talks-reykjavik-and-london.aspx). This is going to be fun! Or course, getting the content together is part of the gig and that's a challenge as I am really hard nosed about getting it right. My style is a lot more informational and less marketing focused than some would like, but my belief is that if have a good product, you don't need a lot of hype. And IIS 7 is a good product.

As I study some of the demos we're doing and talk to the IIS program mangers, I learn more about some of the stuff under the covers that isn't getting a lot of press. Security is one of those topics and as luck would have it, is my particular most interested topic. Imagine that.

Did you know that IIS 7 has built in a new feature called URL Authorization that allows you to restrict access to content without using file permissions? You can simply entire a rule in the UI or directly in the .config file that says deny user="Bob" and Bob will be denied access. The cool part of this is that if you copy the content to another server (and this feature is delegeated), then your security rules move with the content. Think about that for bit. No more managing NTFS permissions on a per sever basis. You could just assign permissions for the worker process identity to have access to the content (and maybe the IUSR account <maybe? Yes maybe. You can tell IIS 7 to use the worker process identity for anon access!).

This is huge and it works with any content, not just .NET.

Just one of the many new security features built into IIS7 we'll be showing on the roadshow. I'm so psyched about the new security improvements that I'll be posting some screencasts on channel 9. But hey, you don't need to wait. It's not a special builld or anything. URLAuthorizatin is in Beta 3 Just download beta3 and check it out for yourself!

http://www.iis.net/articles/view.aspx/Managing-IIS7/Configuring-Security/URL-Authorization/Understanding-IIS7-URL-Authorization?tabid=1

http://www.microsoft.com/windowsserver/longhorn/audsel.mspx

I'll be posting pictures, quotes and details from the trip so stay tuned.

Tuesday, May 08, 2007 7:32:00 AM (GMT Standard Time, UTC+00:00)  #    Comments [0]  |  kick it on DotNetKicks.com
Wednesday, August 16, 2006

The IIS team is meeting this week over lunch where they have someone present to the extended team details about what's going on with IIS 7. It's cool cause you get to see everyone at once that you don't normally see in the same place and because it's a chance to review what's going on with each of the major section areas. Today the topic was security and Thomas Deml discusses some of the new features. Some of these details haven't been highlighted much so I'd thought it would be good to go over them.

#1 Best security feature and top ranking improvement of all time for IT Pros: the IUSR account is now a built in account. In other words, it's not a local account anymore like it is on IIS 4-6. You can finally copy your content from one IIS 7 to another and permissions you've set like "Deny IUSR Execute" will be good on the target system. That's a big help for replication and recovery.

#2 The IIS_WPG group goes away. You will no longer need to assign application pool identities to the IIS_WPG. Any application pool identity is automatically assigned to a built in group that has the right memberships to host the w3wp.exe process.

#3 Request Filtering: This is a manged module that lets you control what kinds of request will and won't be allowed to access the server, site, or application. Sort of like URLScan but lets you have different rules for different places.

#4 .NET Role/Membership Providers: You can use any .NET role or membership provider as the store for users and groups. This works with Forms auth of course so you can implement forms authentication for any content, like static files, .asp, .cfm or whatever you like - and store your users in just about any store you like - ADAM, XML, Oracle, MySQL, Access, SQLExpress2005, whatever you like.

#5 Hidden Namespaces: This is actually part of request processing but deserves to be called out separately. You can declare a namespace as hidden so a folder like "Secrets" cannot be accessed. This protects folders like AppData and AppCode for example.

#6 Skinny Install: When you install IIS 7, you do NOT get equivalent functionality to IIS 6. Since IIS 7 is more modular, it is possible to install less and still deliver some content. So, in keeping with the mantra "install only what you need", Microsoft isn't making assumptions about what you need except that since you said you wanted IIS 7 installed, there's decent chance you want the web server installed. However, if you want ASP.net, or CGI capability, or even Windows Authentication, you'll have to ask for it.  See http://brettblog.com/PermaLink,guid,d4f6c28c-83c5-4166-a805-61cb968172e6.aspx for details.

#7 Reduced Footprint: By removing modules you don't need from the server, you have reduced security exposure. This is not quite the same thing as #6. Skinny install is my own slang for the new reduced install feature set. That translates to fewer modules, but you could potentially take things down even further. The point here is that the feature set of IIS 7 is tweakable to host only those you require, thereby reducing the footprint and attack surface.

If you (or I) think of any more, I'll add them.

-brett

Wednesday, August 16, 2006 6:37:32 AM (GMT Standard Time, UTC+00:00)  #    Comments [0]  |  kick it on DotNetKicks.com

Theme design by Jelle Druyts