Nick Parker
My Ramblings on Software Development...
Twitter
Follow me on
Twitter
Contact
My GPG key is
0x455A1FEF
Site Sections
Home
Contact
Syndication
Login
Archives
April 2011 (1)
October 2008 (1)
September 2008 (1)
June 2008 (1)
May 2008 (1)
April 2008 (1)
March 2008 (1)
February 2008 (2)
January 2008 (1)
December 2007 (1)
October 2007 (1)
September 2007 (1)
August 2007 (3)
July 2007 (2)
June 2007 (1)
May 2007 (4)
April 2007 (6)
March 2007 (3)
February 2007 (3)
January 2007 (4)
December 2006 (1)
October 2006 (4)
September 2006 (3)
August 2006 (2)
July 2006 (3)
June 2006 (4)
May 2006 (4)
April 2006 (5)
March 2006 (2)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (5)
October 2005 (4)
September 2005 (10)
August 2005 (3)
July 2005 (5)
June 2005 (3)
May 2005 (2)
April 2005 (5)
March 2005 (5)
February 2005 (5)
January 2005 (18)
December 2004 (5)
November 2004 (4)
October 2004 (12)
September 2004 (4)
Post Categories
.NET
Agile
AOP
CI
Design Patterns
DLR
General
IronPython
MSBuild
NAnt
Open Source
Productivity
Ruby
Software
TDD
Vim
Visual Studio
OSX
Emacs
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.