computeraccount in admingroup?

  • Thread starter Thread starter joe
  • Start date Start date
J

joe

Hi,
if I set a computer account (not a user) as a member of local
admingroup, who has adminrights?
For example:
Computer 1: local Admins membership Account:Computer 2
Has User X (member of any local group) from Computer 2 adminrights on
Computer 1?

Thanks for help, Joe.
 
Local group and user accounts from one computer can't be placed in another
local computers account.
 
I ment:
Computer-Account 2 is member of Computer 1: group: local administrators

This works.
But why do I need a computeraccount as a member in the
local-admin-group on another server?
Does the services of Computer 2 have adminrights then?
 
I couldn't answer why it is there. It has local rights of which I have no
idea. I would pull it out. This must be some old legacy issue. I haven't
seen this before but it doesn;t look safe.
 
It's used for SMS:
The computer-account of the SMS central server must be a member of the
local administrator group on the site server.
I want to know, if users or services of the central server have
admin-rights on the site server or if it's just done that SMS central
server can replicate the database to/from the SMS site server.
 
Anything running in localsystem security context on computer 2 (i.e. services)
will have admin rights on computer 1, assuming kerberos auth is working ok.

joe
 
I want to know, if users or services of the central server have
admin-rights on the site server or if it's just done that SMS central
server can replicate the database to/from the SMS site server.
Click to expand...

Yes, any service running localsystem or any person who can spawn a process
running as localsystem will have rights (say like through the scheduler, etc).

joe
 
How when the remote machine has a secret password? Am I misunderstanding
the scenario?

--


Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.
 
I am not sure I understand your questions.

However... Computer accounts in AD are a type of user account. The computers
authenticates to those accounts when the machines boot up and gets their
kerberos tickets just like users do. They constantly renew those tickets just
like a user who stays logged on. If that computer is added to a domain group,
that group is in security token of the computer (and in the kerb creds).

Anything that that group has access to the computer itself will have access too
(note that this doesn't mean users on the computer necessarily, only processes
running the computer's context such as localsystem, localservice, and
networkservice).

If you add the AD computer account (or any AD group) to another computer's admin
group, it will work just like a user has been added to the admin group. An
attempt from the computer (not users logged onto the computer) to connect to
that other computer will result in getting kerb service ticket which will
authenticate the computer on the other computer and it will add the
administrators group SID to the local token so that the first computer has admin
rights on the second computer.

Again, this is all just like normal users, you just have to be in the security
context of the computer which is the contexts mentioned above. Getting there
isn't tough if you have more than user rights to the specific computer. You just
have to get the AT service or some other service to do what you want as
localsystem or networkservice. Child's play actually.

joe
 
I guess that is correct but they will have to have significant rights to
spawn the task as a system account. I have only seen local admins do this,
but I'm sure you can tweak rights to do this. So no average user or power
user on this server is going to be able to do this only adminstrating type
accounts.



--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Nope, power users have sufficient rights to escalate to localsystem.

A regular user could possibly do it depending on what is in place on the system
and how patched it is.

Windows security is so so once you are interactively on the machine. If you can
run local code and/or modify system files you are in good shape to do what you
want to the machine. Most of Windows security is to prevent you from getting
into the machine directly and instead only give you interfaces to specific parts
that are safe to allow non-admins to use.
 
I'm going to have to test this out, I was not aware that anyone but admins
or special privileged accounts could do this.

Thanks for the info.

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.
 
There are one or two KBs specifically about power users being able to escalate
themselves. You might want to start by looking for those.
 
Back
Top