7

I have a Windows 2008 machine A with Administrator account X. I have another Windows 2008 machine B with Administrator account Y.

Both machines have an account Z, with same username and password on both.

Account Z is in the local Administrators group on both machines.

They're not on a domain.

From machine A, as user Z (the Administrators one that's common to both machines) I want to start/stop services on Machine B.

(I actually want to do this programatically from c#, but for now via the command line to prove it works is my aim.)

I've tried a few things (e.g. using runas /user:Z cmd, then using sc.exe), but found SysInternal's psservice to be nice and flexible, since I can specify a username and password on the command line. I've also tried coding it via WMI.

I always get the same result:

If I use the user/pass for Account Y (then actual admin on machine B), it works. If I use the user/pass for Account Z (or impersonate it locally), it fails with access denied.

Since Z is in the Administrators group, why is this the case?

Thanks.

Update:

Here are my UAC settings on both machines:

UAC

Nik
  • 228
  • 3
  • 14
  • just because z is in admin does not mean the commands are being run as admin you must elevate the command to admin as in runas admin. Uac is involved more then likely. – tony roth Aug 03 '12 at 16:01
  • I'm not trying to run as the admin user, I'm trying to runas user Z. I have tried using runas /user:Z. UAC is disabled on both machines. – Nik Aug 03 '12 at 16:04
  • I know you are trying not to runas admin and you are doing the correct thing by doing a runas/user:Z etc. What error message do you get? Sorry I missed the "runas/user:Z" in your post. – tony roth Aug 03 '12 at 16:15
  • do the runas again then run "wmic /node:b os" whats the result? – tony roth Aug 03 '12 at 16:17
  • "Access is denied" comes back immediately. – Nik Aug 03 '12 at 16:22
  • this is strange, do the same thing but remove the /node:b part. So yes this will be testing local access.. – tony roth Aug 03 '12 at 16:48
  • Returns successfully a whole bunch of data relating to the O/S. I take it then that this scenario as I've described should work? – Nik Aug 03 '12 at 16:52
  • yes what you are doing if done the way you said should work fine. – tony roth Aug 03 '12 at 17:08
  • within the runas Z cmd session do a "dir \\b\c$" whats the result? – tony roth Aug 03 '12 at 17:21
  • Exactly the same actually - "access is denied", almost immediately. When I connect to a specifically shared UNC folder (\\b\foo), that is shared with Z, it works. – Nik Aug 03 '12 at 17:37
  • dang this is wierd, I'd delete the z account from both servers, then readd it then add to administrators group. – tony roth Aug 03 '12 at 18:21
  • @Nik Silly question, but are you explicitly specifying the machine name? As in, `/user:machinename\adminuserz`? My first guess would be that it's picking the wrong domain (machine, really) for that user. And it never hurts to check the Security Event Logs to see if there's a reason for the failure other than "wrong password." – HopelessN00b Aug 03 '12 at 23:57
  • @HopelessN00b to be clear that should be (using his examples) /user:A\Z in this case, correct? – tony roth Aug 04 '12 at 01:00
  • @tonyroth Correct. – HopelessN00b Aug 04 '12 at 01:06
  • Hi all. Thanks for your comments thus far. a) I've removed and re-added Z into the Administrators group on B. b) When using runas, I am NOT specifying a machine name. In fact, trying to do so throws an error. c) I've double checked the username and password are the same on both boxes (by logging in interactively with them) – Nik Aug 04 '12 at 11:38
  • d) When I try access \\b\c$, from A, I can see the following Audit Failure entry in B's event log: A network share object was accessed. Subject: Security ID: B\Z Account Name: Z Account Domain: B Logon ID: 0x6cf1960 Network Information: Object Type: File Source Address: ip address here Source Port: 55592 Share Information: Share Name: \\*\C$ Share Path: \??\C:\ Access Request Information: Access Mask: 0x1 Accesses: ReadData (or ListDirectory) – Nik Aug 04 '12 at 11:39
  • I have also tried the advice here http://tipstricksandmore.blogspot.co.uk/2009/09/control-windows-services-of-remote.html - to NET USE the admin$ share, and also got "access is denied" – Nik Aug 04 '12 at 13:12
  • @Nik what error do you get when you specify the user with RunAs? And happens if you create a new administrative user that doesn't exist on A, and try to connect to B with B\newadminaccount? – HopelessN00b Aug 05 '12 at 17:29
  • Is UAC actually disabled ("Run All Administrators in Admin Approval Mode" set to disabled in group policy) or just configured not to prompt? – Harry Johnston Aug 06 '12 at 01:20
  • @HopelessN00b - Sorry - must have made a typo or something, I can do the runas with the machine name without issue now. However, I still get access denied, when running cmd as B\Z, and trying to do a dir \\B\c$ . I created a B\Z2, which doesn't exist on A, and the behaviour is the same. – Nik Aug 06 '12 at 10:50
  • @HarryJohnston - UAC appears to be completely disabled on both (see updated image) – Nik Aug 06 '12 at 10:51
  • just an fyi doing a dir \\B\c$ is basically the same test as doing net use admin$. Just to clarify the runas command on machine A is "runas /user:A\Z cmd" anything else will be wrong. then within that cmd windows do a dir \\b\c$.. – tony roth Aug 06 '12 at 13:33
  • its also strange that within your failed audit log entry the failure does not really show? – tony roth Aug 06 '12 at 13:39
  • Hi Tony. Yep - I am specifying the machine name there. But since I am running this from A, it makes no real difference. With/without the machine name, when I run "whoami" after cmd is launched, it shows the same - A\Z. In both cases, I immediately get "Access is denied" on the c$. I also get the same if I runas B\Z. If I use B\Administrator, it works. There must be a setting somewhere specifying that members in the Administrators group are different to the actual Administrator user. – Nik Aug 06 '12 at 13:49
  • @tonyroth Not sure what you mean by "does not really show"? It shows an audit failure trying to do the dir... no? Thanks – Nik Aug 06 '12 at 13:50
  • within a failed audit event you'll usually see what actually failed, this event that you posted looks like a normal non failed share access. – tony roth Aug 06 '12 at 14:01
  • boy this "There must be a setting somewhere specifying that members in the Administrators group are different to the actual Administrator user" would be a real bad thing. You are not using blank passwords are you? – tony roth Aug 06 '12 at 14:03
  • under local policies what is this set to "Deny access to this computer from the network" – tony roth Aug 06 '12 at 14:09
  • No - not blank password. Deny access to this computer from the network" is blank. – Nik Aug 06 '12 at 14:14
  • on device A open a command prompt without runas, do a "net use *" if it won't cause a problem with whats connected do a "net use * /del", then within the same cmd do a "net use \\b\c$ * /user:b\Z", what happens, does it prompt for a username etc? – tony roth Aug 06 '12 at 14:59
  • After the net use * /del : "There are no entries in the list." I then did the command you said, and got "System error 5 has occurred. Access is denied." – Nik Aug 06 '12 at 15:39

1 Answers1

6

Very grateful to everyone's comments, but here is the answer:

http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/22/766945.aspx

There is a registry setting

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

Which impacts this.

If I set that registry entry to 1, everything works as expected - users in Admin group can access remotely properly.

It's not clear to me whether this is over and above any UAC setting (i.e. those local UAC settings never impact remote access), or whether my disabling of UAC is somehow inadequate. (I disabled it by using the Windows UI - my settings are as per the original question screenshot).

quanta
  • 51,413
  • 19
  • 159
  • 217
Nik
  • 228
  • 3
  • 14