Psychology Technology

Recently during the setup of a SharePoint Project Server setup, the setup involved more than one IIS server.  One for the projects, and one for the reports (reporting doesn’t do clusters).

After setting this up, we could access all the sets without issue while directly on the reporting server.  Access the WSS Project Server website is also without issue from both the server and any workstation.  however, when we try to run a report (which calls up IIS on the ‘other’ server) the dreaded three login strikes and you are 401.1′d happens.

To better isolate where the authentication is failing.  There are two things to do.

a) check the IIS logs

b) enable some auditing on the folder directories

To enable auditing on access to particular files/folders:

On the machine the files reside, start gpedit.msc

enable the settings as above.  Warning, if you enable process tracking – never ever do that on a production machine!  Well, do so at your own peril.  It is a resource hog.  Also, make sure your event logs are going to have adequate space for the additional auditing.  Our concern here is going to be the failure audits.

Next we go to the specific folder we want to watch/audit.  By default, this will apply to all subfolders and files, though u can choose to monitor just that chosen folder or file.

Go to the properties of the folder/file and navigate to the Security Tab.

You can now choose the Audit tab.  From here, you have to add each individual user and group for which to monitor.  If a user which is either outside of the group, or is not added, then no audit entry will take place.

Auditing will take place indefinitely at this point.  So if you are doing this solely for troubleshooting.  Remove the users from here, and reconfigure the above gpedit.msc when you have finished.

Also, remember that if you are monitoring across multiple servers, this will need to be done on each machine.  Also, getting familiar with Network Monitor 3.1 will be very helpful!

All of the above setup auditing will appear in your Windows Event Viewer Security Log.  You should be able to correlate this either with other systems, AD, or events in the Application or System logs.

This cropped up in our MOSS 2007 domain environment recently.  After a bit of searching, this KB article got us off to the right start (After being on the wrong start trying to find the config database presented like in SP2003):

http://support.microsoft.com/kb/823287

In our case, the issue ended up being one of the Application Pool identities having its password expire (this should have been set when the service account was created to never expire).  The way I found this 3rd option to be the issue was by digging in the HTML log.

By going to the Home Directory of a problematic website in IIS, I was able to identify the log location (Windows\Logfiles is it by default).  in this were a few 400 and 401 errors.  There were also some application event log errors that also indicated a permissions issue.  Event 5586

Lastly, the service account may very well have had the ‘Password Does Not Expire’ option removed by a modification to Group Policy.

In one of the MOSS environments I have worked in, there was an issue on one of the web frontends where each time you accessed the Central Administration website remotely, it would prompt you to login three times, then give an ‘Unauthorized’ Access Denied HTTP message.

However, when you logged in directly to the web frontend, you could pull up the Central Administration website without any problems.  But why!?  Well, the answer is that the worker process account you have setup for this website doesn’t have an SPN (Server Principal Name) set.  Rather than re-hash what Grant Thompson has wrote, see his blog.

Just note that you may not have to reset the passwords as well.  The restart was enough for me.