March 2006 Entries

KerberosToken and ASP.NET

posted @ Thursday, March 30, 2006 4:24 PM | Feedback (0)

 

Today I found myself debugging a security issue involving the WSE 2.0 SP3. A little background; we have a web service that we wanted to secure; WSE seems to be an obvious choice. We were using WSE to embed a KerberosToken in the SOAP header, this allowed us to retrieve the KerberosToken on the server, access the embedded Principal and check to see if the sender was in fact a member of a specified NT domain group. A simple Windows application proved this worked and I continued on my way. As I started to test an example running with ASP.NET I hit a road block, or at least a slight speed bump. As it turns out, I was unable to construct the KerberosToken on the client side of the ASP.NET application as I could under the Windows application. The returning error message was as follows:

There are currently no logon servers available to service the logon request

Reading the documentation on MSDN regarding the error, Microsoft suggests that you confirm your DNS is setup correctly. A simple ping confirmed that was not the issue. As it turns out, the Windows application I quickly ran my initial test with was running under my domain account, whereas the ASP.NET application was running under the lowly ASPNET local system account. Kerberos requires a Key Distribution Center (KDC); therefore a local system account can not request a ticket. This is valid for IIS 5, whereas IIS 6 uses a Network Service account that would not have this issue. Since we won't be moving everything over to IIS 6 right away, it must run under IIS 5. Two possible solutions are to modify the machine.config file, in particular the processModel element, changing the username and password to a domain account, or to use impersonation. By modifying the machine.config file we can gain even further control over what the domain account can and can not access. Performing impersonation can be an issue when dealing with threading due to impersonation running thread local storage; however impersonation is less invasive, not requiring all developers and web servers to modify their machine.config file. The moral of the story, always test within your true executing environment.

ROI for Agile Methodologies

posted @ Wednesday, March 1, 2006 11:12 PM | Feedback (0)

 

A common question I have heard regarding the use of agile methodologies is how can I determine the ROI of our new found practices. ThoughtWorks, an IT consulting company heavily involved with the agile movement has commissioned Forrester Research to perform an assessment of their processes; here you can read about their results.