> Reposting here as no reply on the remoting NG or on the remoting
> forum: also it's not specifically related to remoting as I get exactly
> the same result when connecting to a WebService hosted in IIS.
>
> Original post is here:
> http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.
> dotnet.framework.remoting&mid=07fdb621-11f1-4382-b32b-306a6d2df504&slo
> c=en-us
>
> I have a remoting server hosted in IIS on my development machine
> (localhost),
> which is a member of a domain.
> IIS Directory Security is configured to disable anonymous access and
> to use
> digest authentication.
> 1. If I configure my client to use default credentials using <channel
> ... useDefaultCredentials="true"> in the app configuration file,
> everything works.
>
> 2. If I configure my client to use default credentials in code as
> follows,
> everything works:
> object service = Activator.GetObject(...);
> IDictionary channelSinkProperties =
> ChannelServices.GetChannelSinkProperties(service);
> channelSinkProperties["credentials"] =
> CredentialCache.DefaultCredentials;
> 3. If I configure my client to use explicit credentials as follows:
> object service = Activator.GetObject(...);
> IDictionary channelSinkProperties =
> ChannelServices.GetChannelSinkProperties(service);
> channelSinkProperties["credentials"] = New NetworkCredential(username,
> password, domain);
> then I get a WebException "The remote server returned an error: (401)
> Unauthorized" and the Event Log Security tab contains a Failure Audit
> event:
>
> Logon Failure:
> Reason:        Unknown user name or bad password
> User Name:    myUserName
> Domain:        MyDomain
> Logon Type:    3
> Logon Process:    IIS
> Authentication Package:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
> Workstation Name:    MyWorkstation
> 4. If I configure my client to use explicit credentials as in (3)
> above, and configure IIS to enable basic authentication and disable
> digest authentication, then everything works.
>
> How can I troubleshoot the problem (3) above, i.e. how can I use
> explicit credentials with digest authentication?
>

> Thanks for responding.
>
>> which version of IIS is this??
>>
> My dev machine is running XP Pro SP1, which I think is IIS 5.1. But in
> production I will be using W2003, so IIS6.
>
>> in IIS6, digest auth only works against domain accounts by default -
>>
> I am using a domain account: i.e. I am instantiating a
> NetworkCredential object using a username, password and domain.
>
>> why are you using digest? to get around SSL??
>> You HAVE to enable SSL - regardless of the authentication method -
>> otherwise
>> all your communication will be clear text.
> My understanding from the IIS documentation is that digest
> authentication does *not* transmit credentials in clear text - which
> is why I want to use it rather than basic.  The application is
> intended for use in an Intranet environment and SSL seems overkill.
>
> Basically  I want to be able to connect to a remoting server or web
> service using credentials other than those of the current user; avoid
> sending credentials in clear text; and avoid the overkill of using SSL
> (needing a certificate on the server etc).
>

"Joe" <J**@discussions.microsoft.com> wrote in message
news:879099E3-0052-4575-8EE1-73D9258C54E4@microsoft.com...
> Thanks for responding.
>
>> which version of IIS is this??
>
> My dev machine is running XP Pro SP1, which I think is IIS 5.1.
> But in production I will be using W2003, so IIS6.
>
>> in IIS6, digest auth only works against domain accounts by default -
>
> I am using a domain account: i.e. I am instantiating a NetworkCredential
> object using a username, password and domain.
>
>> why are you using digest? to get around SSL??
>> You HAVE to enable SSL - regardless of the authentication method -
>> otherwise
>> all your communication will be clear text.
>
> My understanding from the IIS documentation is that digest authentication
> does *not* transmit credentials in clear text - which is why I want to use
> it
> rather than basic.  The application is intended for use in an Intranet
> environment and SSL seems overkill.
>
> Basically  I want to be able to connect to a remoting server or web
> service
> using credentials other than those of the current user; avoid sending
> credentials in clear text; and avoid the overkill of using SSL (needing a
> certificate on the server etc).
>
>

> Thanks to both of you for responding.
>
>> For digest authentication to work, the passwords of the user accounts
>> must be stored using reversible encryption.
>>
> But digest authentication works fine if I use
> CredentialCache.DefaultCredentials instead of creating a
> NetworkCredential object with custom credentials.  Which surely
> implies that the server must be correctly configured to support digest
> authentication?
>
>> place a .aspx file in the same directory - are you be able to log on
>> using the browser??
>>
> As expected, yes I am able to connect using the browser.  I assume
> using the browser is essentially equivalent to using
> DefaultCredentials, which works as noted above.
>
> The following forum post suggests that someone else is having a
> similar problem - but no solution is proposed:
>
> http://www.hightechtalks.com/dotnet-security/unable-authenticate-diges
> t-authentication-351792.html
>

>> if you connect using the browser - a login pop up must come up -
>> there you specifiy credentials -
>>
>> this is like specifying a NetworkCredential.
>>
> I wasn't getting a login popup - I guess because I had both Digest and
> Windows Integrated Authentication checked in IIS.
>
> If I uncheck Windows Integrated Authentication, then I get a login
> popup when using IE - and the login fails.
>
> So I guess this confirms that the server is not able to use digest
> authentication - perhaps for the reasons in the KB article linked by
> Henning Krause.
>
> I guess this is probably why CredentialCache.DefaultCredentials was
> working: presumably this is using Integrated Windows Authentication
> rather than Digest.
>
>> not sure if this helps - but you can enable tracing for system.net
>> (assuming 2.0)
>>
> Unfortunately not, I'm waiting for an upgrade to XP SP2 before we can
> start using VS 2005.
>

>> this does not apply to IIS6.
>>
>> by chance - have you upgraded your Windows Server 2003 from 2000? In
>> this case digest auth does not use the new SSPI provider - and has to
>> be reconfigured.
>>
> There is no Windows Server 2003.
> All the testing I've done so far has been on my local development
> machine
> running XP SP1.

> Thanks to both of you for responding.
>
>> For digest authentication to work, the passwords of the user accounts
>> must be stored using reversible encryption.
>>
> But digest authentication works fine if I use
> CredentialCache.DefaultCredentials instead of creating a
> NetworkCredential object with custom credentials.  Which surely
> implies that the server must be correctly configured to support digest
> authentication?
>
>> place a .aspx file in the same directory - are you be able to log on
>> using the browser??
>>
> As expected, yes I am able to connect using the browser.  I assume
> using the browser is essentially equivalent to using
> DefaultCredentials, which works as noted above.
>
> The following forum post suggests that someone else is having a
> similar problem - but no solution is proposed:
>
> http://www.hightechtalks.com/dotnet-security/unable-authenticate-diges
> t-authentication-351792.html
>

> Hello,
>
> For digest authentication to work, the passwords of the user accounts
> must be stored using reversible encryption. At least, this is true for
> IIS 5. Don't know if this problem is solved in IIS 6, though.
>
> See http://support.microsoft.com/default.aspx?scid=kb;en-us;222028
>
> Greetings,
> Henning Krause
> "Joe" <J**@discussions.microsoft.com> wrote in message
> news:879099E3-0052-4575-8EE1-73D9258C54E4@microsoft.com...
>
>> Thanks for responding.
>>
>>> which version of IIS is this??
>>>
>> My dev machine is running XP Pro SP1, which I think is IIS 5.1. But
>> in production I will be using W2003, so IIS6.
>>
>>> in IIS6, digest auth only works against domain accounts by default -
>>>
>> I am using a domain account: i.e. I am instantiating a
>> NetworkCredential object using a username, password and domain.
>>
>>> why are you using digest? to get around SSL??
>>> You HAVE to enable SSL - regardless of the authentication method -
>>> otherwise
>>> all your communication will be clear text.
>> My understanding from the IIS documentation is that digest
>> authentication
>> does *not* transmit credentials in clear text - which is why I want
>> to use
>> it
>> rather than basic.  The application is intended for use in an
>> Intranet
>> environment and SSL seems overkill.
>> Basically  I want to be able to connect to a remoting server or web
>> service
>> using credentials other than those of the current user; avoid sending
>> credentials in clear text; and avoid the overkill of using SSL
>> (needing a
>> certificate on the server etc).