Secure Remoting Across Domains/Workgroups

[timmmahh]

I'm trying to use the NegotiateStream functionality in .NET 2.0. I
initially made the channel secure by simply adding the 'secure=true'
attribute to the channel configuration settings.

The problem I have is that when all clients/server machines are in a
single domain, everything works fine. However, when I attempt to make
a remote call to a server outside of the domain (say in it's own
workgroup) I receive an exception 'The server has rejected the client
credentials'.

Presuming that this fails because the credentials passed from the
client (in the domain) to the server (in a workgroup) cannot be
authenticated on the server, I then added the following attributes to
the channel configuration:

username=cleart extusername password=cleart extpassword

- where 'cleartextusern ame' is the administrator account on the server
and 'cleartextpassw ord' is the administrator account password.

By doing this, my application worked ok. However, this just doesn't
seem right. It seems absolute madness for Microsoft to design a secure
channel, and then force the usage of cleartext user/password to get it
to work across such a basic network topology as domain to workgroup
relationships. However, I can't seem to find a decent workaround
anywhere.

Therefore, can anyone advise on an alternative, or:
1. Is there someway I can setup a trust between the domain and
workgroup so that the credentials supplied by the client (in a domain)
can be authenticated by a server (in a workgroup)???
2. How can I prevent having to get the user to add a cleartext
username or password in the config file?

[=?Utf-8?B?c2FtMDFt?=]

RE: Secure Remoting Across Domains/Workgroups

This may not be the answer to your question, but it's something I had to do
for different reasons. I stored the username and password of my application
into the configuration file, encrypted at compile-time. But once the
application left the machine it was encrypted on the encrypted settings were
onrecoverable because the encryption keys were machine-level.

So what I ended up doing is creating a whole new section in the config file
like this <protectedSetti ngs Username="someU sername" Password="someP assword"
/>, then created a custom SectionHandler and had the application encrypt it
everytime it starts. Whereby the machine it runs on has the encryption keys
and can use the values as if they were not encrypted. Here's everything you
need to duplicate this solution...

Config File
<?xml version="1.0" encoding="utf-8"?>
<configuratio n>
<configSections >
<section name="protected Settings" type="MyNamespa ce.ProtectedSet tings,
MyAssembly, Version=1.0.0.0 ,Culture=neutra l, PublicKeyToken= bd1505632153fa8 3"
/>
</configSections>
<protectedSetti ngs Username="usern ame" Password="passw ord" />
</configuration>

The SectionHandler
using System;
using System.Configur ation;
using System.Collecti ons.Generic;
using System.Text;
using System.Xml;

namespace MyNamespace
{
public class ProtectedSettin gs : ConfigurationSe ction
{
[ConfigurationPr operty("Usernam e", DefaultValue = "", IsRequired =
true)]
public string Username
{
get
{
return (string)this["Username"];
}
set
{
this["Username"] = value;
}
}

[ConfigurationPr operty("Passwor d", DefaultValue = "", IsRequired =
true)]
public string Password
{
get
{
return (string)this["Password"];
}
set
{
this["Password"] = value;
}
}
}
}

Usage In Your Code
private void VerifyEncryptio n(string sSectionName)
{
try
{
System.Configur ation.Configura tion config =
ConfigurationMa nager.OpenExeCo nfiguration(Con figurationUserL evel.None);
ProtectedSettin gs s =
(ProtectedSetti ngs)config.Sect ions[sSectionName];
if (s != null)
{
if (!s.SectionInfo rmation.IsProte cted)
{
if (!s.SectionInfo rmation.IsLocke d)
{
try
{

s.SectionInform ation.ProtectSe ction("RsaProte ctedConfigurati onProvider");
s.SectionInform ation.ForceSave = true;
config.Save(Con figurationSaveM ode.Full);
}
catch (Exception x)
{
// Handle Exception
}
}
}
}
}
catch (Exception ex)
{
// Handle Exception
}
}