Michael,

This is a snippet taken of Simon Horrell's article off MSDN about
Kerberos...You can refer to the full article thru this link
http://msdn.microsoft.com/webservices/building/wse/default.aspx?pull=/library/en
-us/dnwse/html/wse2wspolicy.asp

<quoteSnippet>
Sending a KerberosToken
If WSE 2.0 is installed on Windows ServerT 2003 or Windows? XP with Service
Pack 1, then it has support for Kerberos authentication in the form of a
KerberosToken. Kerberos has the benefit of being an open security standard,
thus promoting interoperability between WSE-enabled Web service applications
running on Windows and Web service applications running on non-Windows
platforms.

The policy below shows how to configure a Web service operation to accept a
Kerberos ticket as a security token.

<wsp:Policy wsu:Id="PassKerberosToken">
 <SecurityToken wsp:Usage="wsp:Required"
   xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
   <TokenType>
   http://schemas.xmlsoap.org/ws/2003/12/kerberos/Kerberosv5ST
   </TokenType>
 </SecurityToken>
</wsp:Policy>

Again, in this case, because the exact details of a particular Kerberos
ticket have not been specified, the Web service consumer using this policy
must populate the PolicyEnforcementSecurityTokenCache with a specific
token-this time a KerberosToken-before it makes the call to the Web service
proxy, as shown here.

string name = "host/" + System.Net.Dns.GetHostName();
KerberosToken tok = new KerberosToken(name);
PolicyEnforcementSecurityTokenCache.GlobalCache.Add(tok);
s.PassToken();

The KerberosToken is created from the current Windows user's security
context-its Principal property is automatically set to this user-so it wraps
a Kerberos ticket that allows the Web service consumer (running on behalf of
the current user) to communicate with the host specified (the same machine,
in this case).

A policy detailing a particular Kerberos ticket to use is shown below.

<wsp:Policy wsu:Id="PassKerberosToken">
 <SecurityToken wsp:Usage="wsp:Required"
   xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
   <TokenType>
   http://schemas.xmlsoap.org/ws/2003/12/kerberos/Kerberosv5ST
   </TokenType>
   <TokenIssuer>DM</TokenIssuer>
   <Claims>
     <SubjectName>DM\simonh</SubjectName>
     <ServiceName>host/LAP-SIMON</ServiceName>
   </Claims>
 </SecurityToken>
</wsp:Policy>

In this case, all the Web service consumer using this policy needs to do is
call the Web service method, as WSE has all the information it needs to
obtain a Kerberos ticket and wrap it as a KerberosToken.

s.PassToken();
When the message is received by WSE, it automatically maps the Kerberos
ticket to a Windows user account.

It may be that the machine hosting either the Web service consumer or the
Web service doesn't support Kerberos, so using a KerberosToken is not an
option. It may also be that using a UsernameToken is not an option-a
UsernameToken works fine when passing messages from client to server but
won't work for messages sent from server to client as the client has no way
of verifying the server's password. In this case, perhaps an X.509
certificate may be a better choice as the means of specifying credentials.
</quoteSnippet>

hth.