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=cleartextusername password=cleartextpassword

- where 'cleartextusername' is the administrator account on the server
and 'cleartextpassword' 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?

 

[Guest]

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 <protectedSettings Username="someUsername" Password="somePassword"
/>, 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"?>
<configuration>
<configSections>
<section name="protectedSettings" type="MyNamespace.ProtectedSettings,
MyAssembly, Version=1.0.0.0,Culture=neutral, PublicKeyToken=bd1505632153fa83"
/>
</configSections>
<protectedSettings Username="username" Password="password" />
</configuration>

The SectionHandler
using System;
using System.Configuration;
using System.Collections.Generic;
using System.Text;
using System.Xml;

namespace MyNamespace
{
public class ProtectedSettings : ConfigurationSection
{
[ConfigurationProperty("Username", DefaultValue = "", IsRequired =
true)]
public string Username
{
get
{
return (string)this["Username"];
}
set
{
this["Username"] = value;
}
}

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

Usage In Your Code
private void VerifyEncryption(string sSectionName)
{
try
{
System.Configuration.Configuration config =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
ProtectedSettings s =
(ProtectedSettings)config.Sections[sSectionName];
if (s != null)
{
if (!s.SectionInformation.IsProtected)
{
if (!s.SectionInformation.IsLocked)
{
try
{

s.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
s.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
catch (Exception x)
{
// Handle Exception
}
}
}
}
}
catch (Exception ex)
{
// Handle Exception
}
}