SharePoint Managed Path and IIS ISAPI

In SharePoint 3.0 there is no more extra ISAPI extension such as the one in WSS 2.0. All requests are routed to aspnet_isapi.dll instead.

The aspnet_isapi.dll will serve a request if a physical IIS path is found as a match. For example, in IIS you can create a subfolder out of root directory of sharepoint site, and you can browse files inside the subfolder. Doing this actually blocks this subfolder name as sharepoint managed path, since IIS handle requests first.

If no physical IIS path found, Http handlers and Http Modules which are defined in the web.config will start to knick off to handle http requests. At this point, the managed path info will be used to resolve URL.

Update 04/05/2010: IIS will do authentication,and after that the request is yielded to the SharePoint14Module, which will contact file system first and then content database for appropriate page. See this blog for details.

There is an exception: if you put files (other than folders) under iis root directory of sharpoint site, those files can not be served unless they are defined as Explicit Inclusion type of managed path. This seems to be the wss 2.0 "excluded" concept.

Update: this exception only applies to MOSS and WSS 3.0, it is fixed in SharePoint 2010. great fix, no more confusing.

SharePoint Authentication and IIS

We know SharePoint relies on IIS to do authentication (unless FBA), and provides contents based on AAM configuration. When a request such as http://sp.company.com/ hits a WFE, the IIS select a site to authenticate the request. The selection process works as follows:

1. first it looks for the site listening to port 80 with header as sp.company.com. If it is found, it is selected;
2. Otherwise, it looks for the site without any header and listening to any unsigned ip address at port 80. If there is one, it will be selected for authentication;
3. If neither is found, IIS error out

Notice the URL doesn't have to point to the WFE. for example, in the case of Load Balancer, URL points to LB, not WFE.

After authentication succeed, It is up to SharePoint to serve the http request. SharePoint provides content solely based on its AAM configuration, i.e, it must have that specfic FQDN configured (in the prvious example, it is sharepoint.company.com), otherwise, it errors out.

Notice in some scenario, IIS site which does authentication can have a different FQDN than that in SharePoint AAM.

AAM reference: http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx

IIS Error Message: Either a required impersonation level was not provided, or the provided impersonation level is invalid.

If you got this error message when impersonating a logon user, you need to check your pool id and make sure it has "act as part of operating system" right.

1. Open Control Panel > Administrative Tools > Local Security Settings.
2.In the left panel, select Security Settings > Local Policies > User Rights Assignment.
3. Open Act as part of operating system.
4. In the Act as part of the operating system Properties dialog, click Add User or Group.
5. IISReset

Some documents say this is not necessary in Win2003, but it does happen when impersonating in the code.

Other right of application pool (including Network Service):

• Adjust memory quotas for a process
• Generate security audits Log on as a service
• Replace process level token
• Impersonate a client after authentication
• Allow logon locally
• Access this computer from the network

Sharepoint Application Pool ID Account

SharePoint always impersonate authentication users in web.config by this entry: <entity impersonate="true" /> and it also has a Application Pool Account. What does this account do?

1. In case Kerberos is used, this is the account that clients(such as IE) try to communicate with. This is why this account has be registered with a SPN for Kerberos authentication;
   
2. In case you have custom code which need to hop to another server (SQL, File or any web service server), this account will forward login user credential(ticket in kerberos term) to the other server. This is why this account needs to be trusted for delegation;


3. This is the account that sharepoint use to connect its own Content Database, which I bet is through a call RunWithElevatedPrivelege.

A couple other things I learn about web application pool account:

if you try to create an application from directly from IIS, you have to run:

ASPNET_regiis.exe -ga domain\pollIdAccount

if you use NetWork Service as pool id in window server 2k, you have to grant "Act as part of the operating system" privilege for impersonation to work. This is not necessary in Server 2003.

All application pool id should be in the IIS_WPG group which grant most permission they need. See here for a full list permission IIS built-in accounts have.

Hookup SharePoint outgoing email with your Email vendor

update on window server 2008 configuration. First read this post. Following that post, you can setup sharepoint outgoing email IF your target email server accepts annonymos relay or don't need authentication from your sharepoint smtp server. But in case that you want to send to gmail or hotmail or like the following scenario where your company outsources email server to a third party, continue to read:

I ever had a client who outsource their Email service to a vendor, and the vendor doesn't accept anonymous relay, in stead they require authentication. OOB there is no place for SharePoint to provide this info, can sharepoint outgoing email still be set?

Yes, you can. Use sharepoint local smtp and configure its delivery outbound security:

First change relay restriction:



Then configure Security of outbound Delivery:

There you have option to choose authentication mode and enter credentials.
After that, you need to configure smart host by clicking "Advanced" button. Your mail vendor should provide your smart host name.

update on Win2k8: IIS 7.0 SMTP setting has no effect on sharepoint mail outgoing. All you need to configure is IIS 6.o SMTP.
update on sync of user AD info(including email): user AD data are sync-ed with sharepoint profile data by "profile import", and user info which are displayed on sharepoint team siteis actually stored content database, and are sync-ed with Profile data by 2 timer jobs:hourly Profile Syncronization and minutely Quick Profile Syncronization.
So after you change AD data, you must do the followings before seeing new info on sharepoint site (such as email address for alert)

1. import Profile;
2. wait up to 1 hour for existing users,

or
delete users from site collection and add them back in (to trigger Quick Profile Sync timer job, which only applies to newly added users)