Using NetworkCredential then a Redirect to the site requiring the credientails

[Jay Douglas]

Hello all.

Ever since the latest patch for IE 6 it is impossible to pass the
username and password to Exchange 2000 (or any site) in the url (i.e.
http://username:[email protected]) ... so I've possibly
came up with a solution (which I'm sure is thought of and implemented
already) Please review my strategy and offer any suggestions / solutions:

- A user is logged into an asp.net / c# website with the same user name and
password for the domain / exchange server
- To prevent a duplicate login, I used to pass the username and password in
the url (as detailed above), this no longer works
- I would have a simple link with the user name and password in the url
that would automatically log the user in
- I was hoping that somehow, with a combination of a WebRequest /
NetworkCredential I could log the user in behind the scenes and redirect
them to the proper location to the OWA inbox for the particular user without
needing to log them in twice.

I'm having a struggle locating the proper information to achieve this goal.

Any and all input is appreciated.

Thanks in advance.

 

[Joe Fallon]

I thought MS "reversed" that in a followup patch!
It broke too many things.

There is a registry hack to undo it to.

 

[Eric Lawrence [MSFT]]

No, it has not and will not be reversed.

There is a registry patch to turn the behavior off if you'd like.


--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

Ever since the latest patch for IE 6 it is impossible to pass the

username and password to Exchange 2000 (or any site) in the url (i.e.
http://username:[email protected]) ... so I've possibly
came up with a solution (which I'm sure is thought of and implemented
already) Please review my strategy and offer any suggestions / solutions:

Hopefully, the setup wasn't ~really~ broadcasting your unencrypted username
and password to the world at large without any protection?

- I was hoping that somehow, with a combination of a WebRequest /
NetworkCredential I could log the user in behind the scenes and redirect
them to the proper location to the OWA inbox for the particular user without
needing to log them in twice.

I don't think this will work. Arguably, if you wanted to get really fancy,
you could create a C# Proxy which passed all requests and responses between
the client and the server and added the authentication information to the
headers on every transaction-- but this would get insanely complicated and
would be very fragile.

If you'd like to reverse the effects of this security update, there's a
well-documented registry key to turn it off. However, I must caution you
that the approaches you've described are very much vulnerable to even the
most inept of hackers.

Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jay Douglas]

Eric, Thanks for your response....

Hopefully, the setup wasn't ~really~ broadcasting your unencrypted username
and password to the world at large without any protection?

Yes I was, as a temporary solution. The latest I.E. patch was almost a
blessing in disguise.. I'm now in a position where I can tell the customer
they need to budget for an additional component.

If you'd like to reverse the effects of this security update, there's a
well-documented registry key to turn it off. However, I must caution you
that the approaches you've described are very much vulnerable to even the
most inept of hackers.

Changing the registry key is not an option. This functionality needs to be
accessed from a lot of PCs, some of which I have no control over the
registry.

I don't think this will work. Arguably, if you wanted to get really fancy,
you could create a C# Proxy which passed all requests and responses between
the client and the server and added the authentication information to the
headers on every transaction-- but this would get insanely complicated and
would be very fragile.

Is there a middle ground? I was hoping I could use C# to start the request,
pass the user information, and then pass the control over to the users
browser. I don't really want to write an application that acts as an
intermediary for all of this communication. It would be a bandwidth
nightmare, and like you said, flakey.

Possibly some more suggestions may help.

Thanks a ton.


--
Jay Douglas
Fort Collins, CO