Authenticate to Active Directory from a local PC account

The only thing I'm really concerned about is our webfilter seeing the user bob.smith as being the one browsing from that workstation.  The workstation would be part of the domain, but would be logged in as a local user.  I don't know exactly how AD tells the webfilter who is authenticated at that IP.

These are two separate issues.

You need to handle the access through the proxy.
Then you would deal with access to the AD.


You limited in your question on asking why, so the sequential auth to the different components is what is required.

Different users have different access thru the webfilter and that is determined by what groups the AD user is in.  We log into our workstations (authenticating to AD) and that is then passed on to the webfilter and access is given according to your AD membership.  The webfilter is also our firewall and it works in transparent mode rather than proxy.

It likely handles NTLm, so your connection attempt, will be "prompted" for credentials which your script has to handle.

Access to the AD impossibly does not get filtered, since on logon, user credentials are unknown and computer based account might not be ..........

Access to the AD impossibly does not get filtered

I don't understand what you are saying.  I'm not an expert at web filtering, but I think what happens is I log into a workstation and IP address is given to AD.  Our web filter is tied into AD because we setup an LDAP connection using AD credentials.  So when Bob.Smith logs in, his IP address is passed onto AD.  That info reaches our web filter because it can query AD given that it's connected thru LDAP.

We never have to provide credentials to our web filter.  I log into my workstation, and the web filter applies a policy according to the AD group that I am in.

So after doing some research, it seems that AD does not hold the IP for users.  I'm not sure how the web filter gets that info.  So how does the web filter know the AD user?

So I'm guessing the web filter works with NTLM, but the user is not prompted for credentials.  It looks to me like this is all done in the "type 3 message"...
http://davenport.sourceforge.net/ntlm.html#whatIsNtlm

So I'm guessing NTLM forwards the username of the user who is logged in.

NTLM is handled by the web browser when the access is through a trusted source. I.e. using a IE as a browser you try to access https://www.experts-exchange.com when the request hits the webfilter, the browser gets a response auth needed. At that point it passes the user's "credentials."
Get a chrome, or a Firefox browser and try the same thing, and the browser should display the auth request/prompt.

We do not get prompted in Firefox because we use the "Network.automatic-ntlm-auth.trusted-uris" setting within Firefox.  But you are right... if we did not use that setting, we would get a prompt.  As for Chrome, it never prompts because it utilizes the same settings that IE uses – that is the Control Panel > Internet Options.

At that point it passes the user's "credentials."

So the credentials would be that of the local user that is logged in.  I'm guessing these credentials are cached some place?  Is it possible to replace these credentials?

We are talking about two different things.  The handling when one uses a browser and the process your script has to handle.  
The browser when logged in as a local user, The browser upon providing the local credentials will get a deny/authorization failed response as long as the local user and the AD users with the same password do not exist.
At this point, the browser will trigger the authentication mechanism and will prompt the user for information.

In your case, your VB app/script will need to take care to handle the interaction.
i.e. access requested to connect, getting a response from the webfilter to authenticate, then construct the correct authentication response with whatever credentials you have. then see if it passes the webfilter check.  at that point, your script will be assigned a parameter/or will need to include the authentication parameter with every future request.
The only thing I can provide is the process your script has to handle.

It is peculiar why a joined computer, will need to use a local account, given that an AD computer caches the credentials that are successfully authenticated when the system is connected to the LAN.

It is peculiar why a joined computer, will need to use a local account, given that an AD computer caches the credentials that are successfully authenticated when the system is connected to the LAN.

I didn't want to get into the reason why (which is why I said please don't ask why), but since you asked, this is why.  We are testing a VDI solution that disconnects all of the user when one user logs off.  If I have the system using local accounts, then no one will be logging off.  It would just be a workaround while we discover the reason why the disconnects are happening.  It might be poor programming on the part of the VDI software or maybe a GPO setting in our environment.  Using local accounts is just a plan B, I am first testing a few things to see if we can resolve the issue.

If we are unable to resolve the issue quickly, then we will use local accounts until we track down the problem.  It's difficult because it's one of those intermittent and random issues.  There would be some advantages to using local accounts too.  I could have the VB program go full screen and the users would think they are logging into a workstation, but it would take 2 seconds for them to get to their desktop.  The only issue I would have is the webfilter (I already know how to give them access to their shares).  I think they would have to provide their credentials again because I have no idea how I would handle authentication to the webfilter thru the VB program.  Also, I would NOT want the VB program to be running in the background all the time.  I would want it to connect the users to their resources and exit.

Disconnects from where the VDI environment?

Check the DC security log, check the event.

Does the Vdi deploy a unique "system" to each user, or are they all using the same identicalVDI?

http://technet.microsoft.com/en-us/video/microsoft-virtual-desktop-infrastructure-vdi-explained.aspx

I think expending time as you have, might not be as efficient as using the effort to identify why the TS issues disconnects to all users when one session ends.

Hence the reason I did not want to explain why!  Of course we checked the DC security log (and all event logs on the DC and the VDI server).  I suppose if I asked "how do I get to the 7-Eleven, I'd get the reply, "why do you want to go to the 7-Eleven?  It would be much more efficient to go to Walmart."  But I don't like Walmart!

At times a context for the question is important to identify a possible solution that was not considered.
Using your analogy, there might be a 7-eleven closer to you but might be in a neighboring city.

Are using the broker to deal with VDI access requests?
Is the logout occur when a user logs off from the VDI session?
Is the VDI configured as shared space among the users?