From a local machine, it seems maxing out your network connection can cause a terminal service session to disconnect.

From there, its a small step to enumerate connected users, hammer them and use up available sessions.

Only solution I can think of is qos packet scheduling. I'll have to investigate this one further.

Nice work on the automatically generated code for the login component -

If you name your page login.aspx and put a login control on the page, it seems theres a namespace problem and the code casts to a (Login) control, which really casts to your page class - hence the problem, because it's expecting a Login control instead. Solution is to rename your page class.

1. Rename your page to AccessLogin.aspx for example

2. Rename (right click on it and select refactore-rename for best results) your class in your code behind from Login to AccessLogin

3. Update your "Inherits" tag on your .aspx page from Inherits="Login" to Inherits="AccessLogin"

That should do it.

<asp:HyperLink id="HyperLinkStatement" NavigateUrl="MyUrl.aspx?<%=GetSecureInformationFromEncryptedFile("c:\\somefile.txt")%>" style="Z-INDEX: 101" runat="server">Download</asp:HyperLink>

This will not evaluate the method. I always find it interesting the results you get when searching for asp code on the net. Because of misconfigurations or server migrations, you can view the entire source code for various sites out there.

Accessing a remote resource

First understand the difference between LOGON32_LOGON_INTERACTIVE and LOGON32_LOGON_NETWORK

Second understand that if:

1. You are on a machine (Machine A) that is not part of the domain

And

2. You are trying to access a domain machine (Machine B) using domain credentials from Machine A using LogonUser

This will not work. Machine A doesn't know about this domain, so getting a token with information for some domain that is unknown is useless.

You must be using a domain account. One mistake that is quite common deals with a misunderstanding about logging on users. If I make a call to LogonUser and specify LOGON32_LOGON_NETWORK, there is a search order for domain controllers to validate that name. If you have specified the local machine, then there is no validation unless of course you are on a domain controller. If you are trying to validate against another machine on the network that is NOT PART OF A DOMAIN - you cannot validate these credentials through logonuser. You must map the connection as described below. Even if the local login and password match that of the remote machine, this will not work. It can be confusing, because if I try to access machine b from Machine A, and they both have an administrator account with a different password that I need to specify in the credentials from machine a:

MachineB\administrator

in order to validate the user on machineb. So one would think I can call logon user and specify a remote machine name. False. You cannot (as far as anything I am aware of). So then how does Windows do it you say, or such things like runas.exe? Think what happens in a remote machine network access. Your system tries to setup an SMB session. The remote server requires more information and sends back STATUS_MORE_PROCESSING_REQUIRED. Your system sends over the appropriate authentication information. You then access the interprocess communication share at \\MachineB\IPC$ and once this is established (with a proper account) can perform your network request (ex. c:>dir \\machineb\someshare)

How can you then achieve this behavior? Simply enough, in this case you use the WNetAddConnection2 api to establish a session to \\machineb\ipc$. Once that session is established you have "remote permissions" for your current login and can then do your mojo. You are using SMB session information, and not logonuser to achieve this.

I realize this doesn't relate to secure coding (Although something quickly comes to mind of a way to modify a user's path statement to load libraries they didn't intend to) but felt this was important to post.

I was troubleshooting a coworkers system that was running extremely slow. Running calc.exe would take at least a minute to load. I noticed the network icon was lighting up every 8 seconds or so with a transmit but no receive. One thing to note, once she unplugged her machine from the network, response time was normal again. Loading up tdimon from www.sysinternals.com (netmon would have worked as well but was not yet on this system) I was seeing an attempt to contact a remote machine on port 445. The first though was something had hooked the shell and was receiving notifications of program loading and trying something shady. Turned out to be a bit simpler. The path statement contained a unc path so every program searched this path for dependencies upon loading. I would check your path statements to make sure this isn't there, as this would affect the loading of almost every program on the system. When the machine was unplugged, the network services knew there was no network interface to use to try to contact the remote machine, and thus performance was restored.

You can see here the process that is used and how a dll is resolved upon loading. This process can be examined a bit more in detail at:

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/

The call stack order something like this:

LdrLoadDll
    LdrpLoadDll
        LdrpCheckForLoadedDll
        LdrpMapDll
            LdrpCheckForKnownDll
            LdrpResolveDllName
               RtlInitUnicodeString    
               LdrpResolveDllNameForAppPrivateRedirection
               LdrpSearchPath
                 RtlDetermineDosPathNameType_U    
                 RtlInitUnicodeStringEx
                 RtlDoesFileExists_UstrEx
                 LdrpResolveFullName

So when the path is parsed, a remote unc will be checked om RtlDoesFileExists_UstrEx

Recommendation: Remove all unc paths if you are able to from your path statement

If you run runas.exe with the /netonly flag and specify totally invalid user credentials, it never even checks those credentials until you access the network.

You would think the resulting program that runs (cmd.exe for instance) would check that first, especially since the window title is:

cmd(running as machinename\someinvalidaccount)

Just an oddity to watch out for. You are not actually authenticated with network permissions until you attempt to use those network permissions.

In other news tokenmon from sysinternals has caused a system crash twice now in as many days on two separate systems.

The first was in my physical server in lsass.exe the second occured on a virtual server and it just rebooted the virtual server.

Don't get me wrong, I absolutely love their utilities and they've served me well for a long time. The guys from sysinternals should be role models for everyone in the IT world - but the utilities shouldn't crash my servers. I'm going to try to get an exact duplication as Im concerned about the possibility of a denial of service on any system running it.

I've sent an email to them, haven't heard anything back though.

Im just doing some testing to remotely access a machine using runas in order to test some impersonation code.
Depending on the statement syntax, runas.exe gives a generic message:

"RUNAS ERROR: Unable to acquire user password"

This error can mean the syntax was incorrect, rather than something being wrong with the password. Invalid syntax for a server means problems trying to validate the password.

For instance:
runas /user:\10.102.0.250\administrator cmd

Since the format of the command should take a domain@user or domain\user NOT \\domain\user since thats a unc format. This is just one example of course as to what can make runas fail with that error.
One thing to note, if you are doing this remotely make sure you specify the /netonly flag otherwise you will get:

RUNAS ERROR: Unable to run - cmd
1326: Logon failure: unknown user name or bad password.

So the proper format is:
runas /user:10.102.0.250\administrator /netonly cmd
Note this does NOT create a remote command line running on the remote machine, this is just a token that you can use (you can use psexec from www.sysinternals.com for that which essentially installs copies a small file to the remote computer through the admin$ share and then contacts the SCM to create a new service on the remote machine and start it. It then uses that service to acts as the remote executer and then proxies any console output back to your local instance of psexec. psexec does contain this small embedded executable inside of psexec.exe that it extracts and copies. psexec also works over named pipes)

I had some old vb.net code sitting around from a COM+ comparer program I wrote some time ago to compare catalogs between machines and synchronize them. I imported the project into whidbey and the designer yielded this error:

Method 'System.Drawing.SizeF.op_Implicit' not found.
Seems if you remove the line with "AutoScaleBaseSize" or "AutoScaleDimensions" the designer will automatically fix it for you.

When trying to create a method Could not find a snippet titled 'Method Stub - Body' or 'Method Stub - No Body', or could not find a literal in that snippet whose ID is 'signature'.  No stub was created

Some of my snippets aren't working properly after having Whidbey beta1 and then putting beta 2 on my system. When I try to add a method stub I get:

Could not find a snippet titled 'Method Stub - Body' or 'Method Stub - No Body', or could not find a literal in that snippet whose ID is 'signature'.  No stub was created

Solution: Go to the Tools->Code Snippets Manager menu. Click add, and navigate to the C:\Program Files\Microsoft Visual Studio 8\VC#\Snippets\1033\Refactoring folder (or whatever your install path is). You should be good to go withouthaving to restart visual studio. BTW a reinstall(repair) of Whidbey didn't fix the problem, you have to manually add them.