Am I missing something or has MS missed the plot?

[Dominick Baier]

Hi,

you are right - Windows needs the password in plaintext to impersonate a user (having to call LogonUser, which requires a password). Thinking about it - it is the only way Windows can do it.

So if you want to use the Windows infrastructure that's already there you have to combine option 1 or 3 with option 2. If SSL seems too slow to you - buy a SSL processor card (IIS6 supports them) to speed up the encryption.

Another option would be (works only on IIS 6 being a domain member) -

you can leverage the new W2K3 Kerberos S4U services.

1) use wse the send hashed password

2) authenticate the user somehow and provide the cleartext password in UserNameTokenManager

or

1) use a X509 Token

2) authenticate the token somehow

associate the user with a existing windows account (e.g. through a database) and call

WindowsIdentity winid = new WindowsIdentity("user@domain");

WindowsPrincipal principal = new WindowsPrincipal(winid);

you will get a token that you can use for role inspection (calling IsInRole).

To impersonate to access local resources the service has to run as LOCAL SYSTEM

To impersonate to access remote resources, configure constrained delegation in AD for the WebServer (you don't have to be running under SYSTEM in this case)

to enable both scenarios, just call winid.Impersonate();

hope this helps

---
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

nntp://news.microsoft.com/microsoft.public.dotnet.framework.webservices/<#v**************@TK2MSFTNGP11.phx.gbl>

Hello all,

I'm trying to do something which I believe is very normal, standard sort of
requirement. I want to secure access to a web service across the Internet
using username/password on the server, then impersonate the account on that
server.

Option 1 - set IIS to basic authentication, which all works great, except
that passwords are transmitted in clear, so that's obviously useless.

Option 2 - as option 1, but encrypt everything using IIS. Seems great, but
runs ridiculously slowly because asymmetric encryption is so ludicrously
slow and a complete waste as there's no need to encrypt much apart from the
password.

On to option 3, WSE, but as far as I can tell from the confused
documentation, the only ways to impersonate are to use Kerberos (no use
here) or plain text passwords (just as bad as option 1). There seems to be
some chat about using hashed passwords, which would be absolutely ideal, but
I've yet to find and useful examples of a token manager which can do this
and just drop-in to an application?

It just seems that MS has really missed the plot here. Why has MS made
something so standard so difficult?

Any pointers, code, hints etc most welcome.

Cheers,

Tim
t_********@hotmail.com



[microsoft.public.dotnet.framework.webservices]

[Tim Haynes]

Thanks, thought so. Why does MS make it so hard to do the obvious simple
things while constructing great edifices to do obscure complicated things?
Come on MS - why not do something to make life easier for us developers?

I guess a solution might be for me to use SSL (or X.509 in WSE) to transmit
username and password to the server where it can be stored, then use plain
HTTP after that. The pain is that I presumably have to do some code at the
top of every method to impersonate that user, as well as sending some hash
to prove client identity - all very painful. Is there some way to use WSE
to hide this sort of stuff away under the hood? Ideally it should just
happen transparently, or perhaps need no more than an [Impersonate]
attribute on a class or method!

SSL processor cards are not much good, as I can't assume that every user
will want to buy one. Judging by the speed of Amazon's secure site at the
weekend (presumably they have these) even such addons aren't enough to make
SSL usable. Why oh why can't someone do the obvious and come up with
"SSL++", a protocol which uses asymmetric encryption to swap a secret key,
then use this key to encrypt/decrypt subsequent traffic symmetrically much
faster, all under the hood? It would really make web services practical at
last! Come on Microsoft - this is a fantastic addon for WSE 3.0, Indigo
and/or IIS. Revolutionise the Internet and save the world...

It's just so frustrating - all this security stuff, but the simplest, most
obvious thigs have slipped through the net!

Cheers,

Tim

"Dominick Baier" <do****@leastprivilege.com> wrote in message
news:ey***************@TK2MSFTNGP10.phx.gbl...

Hi,

you are right - Windows needs the password in plaintext to impersonate a user (having to call LogonUser, which requires a password). Thinking about
it - it is the only way Windows can do it.
So if you want to use the Windows infrastructure that's already there you have to combine option 1 or 3 with option 2. If SSL seems too slow to you -
buy a SSL processor card (IIS6 supports them) to speed up the encryption.
Another option would be (works only on IIS 6 being a domain member) -

you can leverage the new W2K3 Kerberos S4U services.

1) use wse the send hashed password

2) authenticate the user somehow and provide the cleartext password in UserNameTokenManager
or

1) use a X509 Token

2) authenticate the token somehow

associate the user with a existing windows account (e.g. through a database) and call
WindowsIdentity winid = new WindowsIdentity("user@domain");

WindowsPrincipal principal = new WindowsPrincipal(winid);

you will get a token that you can use for role inspection (calling IsInRole).
To impersonate to access local resources the service has to run as LOCAL SYSTEM
To impersonate to access remote resources, configure constrained delegation in AD for the WebServer (you don't have to be running under
SYSTEM in this case)
to enable both scenarios, just call winid.Impersonate();

hope this helps

---
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

nntp://news.microsoft.com/microsoft.public.dotnet.framework.webservices/<#v**************@TK2MSFTNGP11.phx.gbl>
Hello all,

I'm trying to do something which I believe is very normal, standard sort of requirement. I want to secure access to a web service across the Internet
using username/password on the server, then impersonate the account on that server.

Option 1 - set IIS to basic authentication, which all works great, except
that passwords are transmitted in clear, so that's obviously useless.

Option 2 - as option 1, but encrypt everything using IIS. Seems great, but runs ridiculously slowly because asymmetric encryption is so ludicrously
slow and a complete waste as there's no need to encrypt much apart from the password.

On to option 3, WSE, but as far as I can tell from the confused
documentation, the only ways to impersonate are to use Kerberos (no use
here) or plain text passwords (just as bad as option 1). There seems to be some chat about using hashed passwords, which would be absolutely ideal, but I've yet to find and useful examples of a token manager which can do this
and just drop-in to an application?

It just seems that MS has really missed the plot here. Why has MS made
something so standard so difficult?

Any pointers, code, hints etc most welcome.

Cheers,

Tim
t_********@hotmail.com



[microsoft.public.dotnet.framework.webservices]