Freigeben über

VSTT Controller, agent in a workgroup

  • Artikel

So I moved from the networking group to Visual Studio Team System Test. Recently, I was investigating an issue where the client, controller and agent are not working together
when in a workgroup topology. In other words, the machines that are running the client, controller service, and agent service are *non* domain joined and are
part of a workgroup. In this situation, the client is simply failing to connect to the controller. The client gets the message
"The server rejected the client's credentials - Log on failed".

For this discussion let’s say I have Machine CLEINT with user Tony. The machine that is running controller (lets say CONTROLLER) has the same user and password Tony.

I started investigating this issue by enabling the security audit in the security policy. In examining the security audit log, I found that the user on the client
machine was rejected. The message goes like "Bad user name or password, user Tony, Domain CLIENT". On the first thought it kind of makes sense that the user
CLIENT\Tony will be unknown to CONTROLLER. However, the windows workgroup security needs to enable this scenario since there is no central
domain controller. So CLIENT\Tony should be able to authenticate to CONTROLLER as CONTROLLER\Tony. This scenario should work. So what gives?

The next thing I tried is to simply map a network share from CLIENT to CONTROLLER, something like \\controller\c$. Since both CLIENT and CONTROLLER
have Tony as the interactive user, this file share mapping should work. (I already enabled the firewall for this). What I got is a dialog box asking me for credentials.
The strange thing is that the user box is grayed out and says CONTROLLER\Guest. I wondered why it is forcing me to login as guest. A quick call to
the security team gave me the clue.

For Windows XP, in a workgroup situation, there is a setting that forces all NETWORK logins as GUEST. Which means that even if you
are trying to authenticate with a legitimate user and password credentials, it will force you to login as GUEST. Clearly, this is failing
because I am trying to login as Tony and not as Guest.

The fix is to edit the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest
and set the value to 0. This will remove the restriction of forcing the network logins as "Guest". Once I set this value to 0 on *all* the machines (client, controller and agent) and rebooted
the machines, it all worked perfectly.

To recap,

1. Windows XP "ForceGuest" is on by default in a workgroup scenario, which means all network logins are allowed as Guest only..

2. Set the registry key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest to 0 to remove this restriction

3. Reboot after applying the security setting

I will post a more detailed article on the controller, agent and client setup, users and permissions shortly.

Comments