"vtjdailey" <vtjdailey@gmail.com> wrote in message
news:1151961540.563223.142450@b68g2000cwa.googlegroups.com...
> Here is some further information about the problem:
>
> I figured out that I needed to set a servicePrincipalName parameter on
> the channel. However I can't seem to set this property dynamically
> based on which server I'm accessing:
>
> The following code works:
>
> System.Collections.Hashtable dict = new
> System.Collections.Hashtable();
> dict.Add("secure", true);
> dict.Add("username", XX);
> dict.Add("password", XX);
> dict.Add("domain", XX);
> dict.Add("connectionTimeout", 7000);
> dict.Add("timeout", 30000);
> dict.Add("tokenImpersonationLevel",
> System.Security.Principal.TokenImpersonationLevel.Delegation);
> dict.Add("servicePrincipalName",
> "ServiceName/machine1:9000");
>
> TcpClientChannel clientChannel = new TcpClientChannel(dict,
> null);
> ChannelServices.RegisterChannel(clientChannel, true);
>
> In this case, the event log tells me that the user was authenticated
> with Kerberos.
> But I won't always be connecting to 'machine1'. I would rather do
> something like this:
>
> Configure as above, except without the
> dict.Add("servicePrincipalName"....)
>
> IDictionary dict =
> ChannelServices.GetChannelSinkProperties(myProxy);
> dict["servicePrincipalName"] = "ServiceName/machine2:9000";
>
> myProxy.DoSomething();
>
> Doesn't work -- the event log says NTLM authentication is happening,
> and so delegation isn't working.
>
> I've seen example code doing something like this with other properties,
> but it seems to have no effect with this property. Running in the
> debugger shows that the returned IDictionary does not have an entry
> under the key "servicePrincipalName". In fact, even if I've configured
> "servicePrincipalName" in advance (my first example) it still won't
> appear in the IDictionary pulled from
> ChannelServices.GetChannelSinkProperties(..).
>
>
> So I'm at a loss as to where to go from here. I need kerberos
> authentication which requires the servicePrincipalName configuration
> item. And I need to reset that configuration item depending on which
> remoting server I connect to.
>
> -John
>

Dave Sexton wrote:
> Hi vtjdaily,
>
> TcpChannel is shared by all objects hosted on the same server, so unless
> your application can handle a global change to the servicePrincipalName of a
> particular TcpChannel, Remoting will not meet the needs of your app. In
> other words, if your client application establishes multiple connections
> asynchronously you will not be able to change the servicePrincipalName using
> a single channel, and I don't think that Remoting provides a way of
> requiring that a client object must use a particular TcpClientChannel.
>
> If your app needs to establish synchronous connections try unregistering the
> channel and then registering again with the required servicePrincipalName
> before attempting to connect. A global variable to reference the channel
> when it's created is required:
>
> // Unregister the TcpChannel.
> // 'channel' is a global variable.
> ChannelServices.UnregisterChannel(channel);
>
> // Call a method that registers the channel with the new
> servicePrincipalName.
> // 'channel' must be set in the RegisterChannel method.
> RegisterChannel(servicePrincipalName);
>
> HTH
>