Process.Start requires a password (which we don't have, because we're not bothering the user by asking). Also, that would start a process on the local machine, not execute a command on the server.

Simillarly, the request for the value of My.User.Name is being run on the client application, and could be changed before being sent to the server. Eg, Domain\Fred could change My.User.Name to Domain\Ben before sending it to the server.

The server can't assume that the name being provided is legal, which is why I was looking for some sort of challenge / response code.

It's OK, I'll stick with IIS's Windows Integrated Authentication for now.

PS: "Non-networked, firewalled, computer?" GOLD - so many levels of pure FAIL!

My personal suggestion would be to implement a simple logging system. When a network user log's-in to your application; simply log to a file or database table the user name that he signed on as, workstation name and IP address along with a timestamp.

After that it's a simple matter of a small query or report to see if Fred from his own computer is loggin on as Bob and fire Fred.

Hey John / Tom,

Thanks both for your input.

John - it does seem like its being overcomplicated, but this a government dept, they overcomplicate everything!

Basically, to implement a system in production we have to show that measures have been taken to ensure that users can’t ‘spoof’ other users, otherwise Fred could pretend to be Bob and we accidentally fire Bob for doing something that Fred did.

Can you smell a lawsuit looming?!

The reason this problem came up in the first place is because users login to the Windows domain using a smartcard, 4 digit pin & fingerprint – all without the user even knowing their Active Directory password.

So I’ve been stumped to find a solution where VB .NET can securely connect to a remote service without asking for a password – except the solution I came up with in my first post.

Thanks both for all your help, I’ll keep you posted if I find any VB .NET solutions.

(Although the IIS one is working really well for now).

Cheers,
Ben

Process.Start was an example of how the user could impersonate much simpler than spoofing Tcp packets... it was not a suggestion to how you should write your windows client application. Faking the Tcp communication is difficult to start with, but you wouldn't sent the account name in clear text over the wire anyway, you would encrypt it. I don't see why you would trust windows security through IIS and not on client workstation, it is the same thing, same security mechanism. Impersonation/login on workstation require the person to know the credentials in order to run your app under various user accounts. If the user knows the credentials for other accounts he would just login as that user and your IIS "integrated security" solution would be none the wiser. What you're saying is that you want to use the Windows security, but you don't trust the Windows security - what gives?

__________________
See this thread about how to use forum markup codes for code blocks etc (present the problem/post properly )
Some useful links: Learning videoes, WMI Code Creator, MSDN, The Code Project, WindowsClient.net, ASP.net, W3 Schools, Regular-Expressions.info, GDI+ FAQ

DR. WEIR: Download it to a non-networked, firewalled computer.
TECHNICIAN: Yes, ma'am.