Some posts in NG as well as a customer case reminded me of that infrequent issue that may happen when a user visit a web site or attempts to use a web-based application hosted on IIS.

HTTP requests/responses contain two parts: the header and the body. The header contains most of time technical information exchanged between the client and the server, the body contains user-oriented information like the content of a webpage or a file to download, for example. The error message ere above is therefore generated by the server because the request sent by the client contains a header that is simply too large compared to what the server expects. But what can make a header section so large? It all depends on how you browser was configured (and the underlying OS as well in some case), but most of time, the culprits of larger header are cookies (header: Cookie) and authentication information (Header: Authorization).

When this error is experienced on an Internet site, there is not much you can do except cleaning up your cookies and hoping it will work afterwards while.
When this error shows up in an intranet environment when web servers are running IIS and possibly SharePoint, SQL Server Reporting Services or Exchange with OWA on top of it, this is caused by a combination of multiple factors which are the following:
- The web server (or web site) was configured to use Integrated Windows Authentication and Kerberos in particular
- The client is able to authenticate using Kerberos (the client system is member of an AD forest, the user too)
- The size of the user’s security token is large. This can be caused by: the user being member of many AD groups  (hundreds of groups), the user’s object in AD contains SID history information as consequence of a domain migration/consolidation, the groups the user is member of is also affected by SID history, just like the user.
IIS is configured by default
- The client sends Kerberos-based authentication AND authorization information. Unlike NTLM and Basic which only send authentication information, therefore smaller, Kerberos includes information such as group membership and SID history information in the request’s header.
-> Depending on the user’s group membership and SID history information, some users may be affected, others not…

Hopefully, there are many solution to work around this problem but all of them have their trade-offs:

Use IP address in the URL instead of host names
Since Kerberos solely works with host names, using UIP addresses will automatically force negotiation to NTLM instead. Of course, this does not only degrades security but it also involves hard coding IP’s, which is rarely practically and also means that this can work if you only host one and only one web site on your IIS, finally, if your application uses “delegation” of credentials, which is a Kerberos feature, it will not work anymore (I am thinking about SQL SRS in particular in this case, or even Exchange OWA when used in FE-BE scenario’s)

Configure IIS to use NTLM only
As part of the Integrated windows Authentication setup, you can simply configure IIS to use NTLM only, the following MS KB article will show you how to do so: http://support.microsoft.com/kb/215383. Although this configuration is less impacting that the first one, you’re still left with lower security as well an compatibility issue with Kerberos is required by your application.

Configure IIS to accept larger headers
You can do so by configuring IIS in registry. It is important to note that this configuration will apply to all web sites running on the system running IIS because this settings is used at kernel-component level (http.sys), it will therefore impact all your applications on that server. This MS KB article explains all those settings http://support.microsoft.com/kb/820129, the one that is to change being MaxFieldLength. Be very careful doing so because this will increase the memory used by the system (kernel memory) to handle requests. On a “busy” (read: getting a lot of requests, not fewer large requests) 32-bit system, this can exhaust kernel memory. If the boot.ini switch /3GB is used (possibility combined to /USERVA), the situation can get worse since less memory is available to the kernel. On a 64-bit system, this configuration is harmless, even if the application is running in 32-bit mode, since this is handled in kernel mode. Of course, take care of what your application is doing with those headers too…

Plan a crash-diet for your AD users
By reducing (read optimizing) their group membership and removing SID history information from both user’s and group’s AD object attribute. Though this solution will be profitable in all scenario and not only web authentication (faster logon, less memory usage on application servers, Exchange mailbox servers…), never implement without a careful impact assessment. This MS KB article explains how to automate this task: http://support.microsoft.com/kb/295758

Now for some background information:
- Since that error is generated by the HTTP.SYS driver, is will not be logged in the W3C of whatever files but in HTTPERR.LOG. To track who is affected, simply look at the client’ip in the log. Of course, since authentication information cannot be handled, user’s identity remains unknown.
- To estimate the token size for general purposes, no only for this issue in particular, you can use this tool provided by MS: http://www.microsoft.com/downloads/details.aspx?FamilyID=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en
- The way IIS handles headers and therefore authorization information is one thing, the way Windows system, in general, handle large token is another. Make sure you keep you IIS and windows configuration consistent so that authentication is successful end-to-end. Read this MS paper for more information: http://www.microsoft.com/downloads/details.aspx?familyid=22DD9251-0781-42E6-9346-89D577A3E74A&displaylang=en
- A good network monitor (I like to call it http://www.wireshark.org/) and well as a troubleshooting tool like MS WFetch (http://www.microsoft.com/downloads/details.aspx?FamilyID=b134a806-d50e-4664-8348-da5c17129210&DisplayLang=en) will help the troubleshooting task. As usual, MS LogParser is your friend when it comes to analyzing IIS log files, look at this forum for help parsing HTTPERR.LOG http://forums.iis.net/1141.aspx or keep on reading this blog for more LogParser scripts.
- For simplicity’s sake, I use the work “Kerberos” when talking about authentication protocol between client and web server. The actual protocol is SPNEGO or “Negotiate”, which is a wrapper for multiple authentication protocols. Refer to Wikipedia for the details: http://en.wikipedia.org/wiki/SPNEGO

And cut!

While configuring client to web server Kerberos-based authentication can be relatively simple, doing the same for server to server communication (SQL, Crawl or SSP for example) can turn out to be something really tricky.
Hopefully Microsoft recently published an excellent paper on this subject on TechNet: http://technet.microsoft.com/en-us/library/cc263449.aspx

While talking about Kerberos client to server, I’d definitely recommend reading Ken Schaefer’s serie of blog posts over Kerberos and IIS, which is a must for all IIS admins. Please note that 90% is applicable to SharePoint too…: http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx

And cut!

What particularly annoys me with some so-called “security engineer” is their lack understanding of (or outdated?) protocol s in general and of Microsoft technologies in particular.
At hearing the words “Microsoft”, “Windows” and “RPC”, they directly react with “insecure”, “anonymous”, “not authorized”…

RPC is wild over (high) ports and you cannot control it
False: by default, RPC uses port 135 as end-point mapper then agrees with the other host it communicates with to use higher ports as necessary. The high port negotiation can be agreed and be restricted to a range of ports or to a single port. If you don’t want to configure RPC behavior on hosts, you can also encapsulate the traffic into IPSec, which is a no-brainer in windows. Here is how to do for both cases: http://support.microsoft.com/kb/908472

RPC cannot be firewalled
Totally untrue, most of recent (and decent) firewall will do the job. Just for the records, I can mention Checkpoint, Whose SmartDefense technology included RPC firewalling since 2003. These MS KB articles with help you further: http://support.microsoft.com/kb/154596 and http://support.microsoft.com/kb/179442

RPC is anonymous by default
Forget about the Windows NT4 era, this is all history! In some very specific cases you may still see anonymous RPC (or CIFS/SMB) call on the network but most of times, it is fully authenticated. Not to mention that when using DCOM over RPC, you can set the authentication mode you wish with a lot of granularity. Look at this TechNet contents for in-depth explanation: http://technet.microsoft.com/en-us/library/cc781010.aspx and  http://technet.microsoft.com/en-us/library/cc738214.aspx. By the way, bear in mind that people making such incorrect claims also seem not to know that even in HTTP protocol, the first request is anonymous…

RPC over HTTP is only valid for Outlook and Exchange
What? Hem, you mean “is up to my knowledge only implemented with Outlook and Exchange”. But nothing prevents you from implementing your own solution based on this technology. Take a look at MSDN for details: http://msdn.microsoft.com/en-us/library/aa375384(VS.85).aspx.
By the way, unlike many people like to think, the FrontPage RPC protocol has nothing to do with standard DCE RPC we’re talking about here. FPRPC is an extension of HTTP that eases web site authoring as well as collaboration work over HTTP. It should be considered as a kind of WebDAV on steroids.

And cut!
Thanks to J.G. for inspiring me this post! I really appreciate talking with people able to scratch the surface and look underneath.

Nothing new here, just a repost by popular demand... 
Many examples on the Internet show how to use the Office Automation COM object to achieve this. But under some circumstances, this is not possible because Excel is simply not installed locally.

More information can be found here:

• http://support.microsoft.com/kb/311731
• http://support.microsoft.com/kb/316934
• http://msdn2.microsoft.com/en-us/library/system.data.oledb(VS.71).aspx
• http://msdn2.microsoft.com/en-us/library/system.data(VS.71).aspx
• http://msdn2.microsoft.com/en-us/library/ms254500(VS.80).aspx

Note: This was not tested using an XLSX files but with a standard XLS instead
Note 2: DataSet can be used instead of DataTable object but I prefer this one in favor of greater simplicity (this is to be used by sysadmins, not developersJ)
Note 3: I blogged about reading but you can update and insert too, see references above for details

And cut!

Nothing new here, just a repost by popular demand... 

We need an SMTP Client object and a Mail Message object:

$SmtpClient = new-object system.net.mail.smtpClient

$MailMessage = New-Object system.net.mail.mailmessage

Then a basic configuration of their properties (you may have to adapt to fit you environment’s needs)

$SmtpClient.Host = "mysmtpserver.mycompany.local"

$mailmessage.from = "notification-services@mycompany.local"

$mailmessage.To.add("itadmins@mycompany.local")

$mailmessage.Subject = “Daily Uptime Reports”

$mailmessage.Body = “Server01. mycompany.local: 99.999% uptime”

And now, the special touch that makes Outlook display the message with a “bell” icon à la SharePoint notification:

$mailmessage.Headers.Add("message-id", "<3BD50098E401463AA228377848493927-1>") 

All you need is to add 3BD50098E401463AA228377848493927 before the actual message ID and separate them with a dash  And then send the message

$smtpclient.Send($mailmessage)

If you want your email to look even more eye-candy, enabled and add HTML to the body before sending

$mailmessage.IsBodyHtml = 1

You can even read from a file using get-content and generate the body

$mailmessage.Body = Get-Content .\report.html

Find more information over here:

• http://msdn2.microsoft.com/en-us/library/aa219030(office.11).aspx

And cut!