We can agree to disagree. :o)
You make someone a server operator on a domain controller
because you don't trust them to be a domain admin due to their judgement or
perceived skill set. Making them a server operator does nothing to protect the
DC from that judgement nor skill set. If you can trust them to not do bad things
as a server op, why can't you trust them not to do bad things as a domain admin?
You are just drawing lines in the sand, the group the user is in
shouldn't matter if you know they won't cross that line.
The concept behind groups is to do more than draw a
line, it is to enforce the line. Unfortunately server ops doesn't enforce
any lines, it just uses colored sand for the line which is more appealing to
some people. The main purpose now in my eyes is to give people a
false sense of security that exists. Exactly like the false sense of security
someone will have with an environment with multiple domains where someone is a
domain admin in one domain but not in another. At some point, I am sure someone
thought that group would enforce some level of security, that was quickly shown
to be incorrect.
A person with servop can purposefully or accidently
through running something they don't understand effect a compromise on the
environment. Just because they may not know how to directly elevate their
rights and may not even intend to doesn't mean some app they run won't know
how to and does want to. Such apps exist, it is theoretically possible that
I may have written some. Someone who is a servop may think they are safe in what
they run simply because "I'm not a domain admin, I must be blocked from being
able to do really bad things...".
On the data protection against admins, this is a completely
different item because it does have a good concrete answer. If someone,
including any level admin isn't supposed to have access to data, there are
mechanisms to make sure they can't. It is called Data Encryption. And I am not
talking about the MS Freebie, I am talking about going out and purchasing third
party software that encrypts the files or groups of files that shouldn't be
accessed by anyone but the specific parties.
I argue that if you have that much faith your serv ops,
that should be ok as a domain admin. You are still drawing lines as to what they
can and can't do but everyone is fully aware of how much they can really do any
time they choose to. It is far more honest and well understood. If someone asks
you what a server operator can do, what is the response? Most people don't know
but the first answer I always give is "make themselves a domain admin". That
trumps any other "official" rights they have. It is sort of like when someone
grants permissions to an object and gives a couple of specific ones and for some
reason modify permissions as well. When you look at the ACL what do you tell
people they can do? The answer is anything they want to do. Another example, if
you give someone the ability to create computer objects, OUs, and group objects,
have you blocked them from being able to create users? Nope. However not
everyone may understand that when they take a quick glimpse at the ACL.
Doing this kind of sand drawing does nothing but give some
casual form of comfort in your security. It may help prevent casual oops
mistakes but I don't consider that any comfort, people who make casual oops
mistakes probably shouldn't be playing with domain controllers in the first
place.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Moon, Brendan
Sent: Friday, June 10, 2005 5:05 PM
To: [email protected]
Subject: RE: [ActiveDir] mstsc /console switch for non admins
Joe, I disagree.
And since that has not happened often with your posts, I'll take some time to
elaborate. :)
We all
understand that someone on a DC console can take control of the data on it, and
via replication the forest. However this is not achievable without
"hacking" (for lack of a better term) the intended and pre-assigned rights and
directory data. In other words, the "bad guy" would know he was a bad guy
when he was doing it.
Every day we draw lines around what people are authorized
to do, knowing full well that they could potentially do more, and perhaps even
something very damaging. For instance, the fire alarm handles in most
buildings are a very easy way to effect a crude "denial of service" attack on
the occupants of a building.
A little more to the point, a system administrator can
"take ownership" of files he does not have rights to, and therefore obtain data
which he is not authorized to have. I think it is reasonable and proper to
have files on a system (e.g. payroll or medical files) for which an
administrator does not have rights to. Even though there is a "risk" that
a malicious administrator can access this data, that alone is not reason to
explicitly grant him access to it.
And to the scenario below, just because a Server
Operator can hack a DC, doesn't mean he should be a Domain Admin. Nor does
it mean Server Operators on DCs are always a bad idea. It just has risks
that everyone needs to understand and
accept.
While you are
right that someone who configures this scenario may not understand Windows, or
assume the Server Operators are not knowledgeable -- the other reasonable
possibility is that there is a some level of trust with the Server Operators
that makes the risk acceptable.
- Brendan Moon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, June 10, 2005 10:30 AM
To: [email protected]
Subject: RE: [ActiveDir] mstsc /console switch for non admins
Honestly any time someone asks a question like this my
response is make them domain admins because any time they want it they can take
it and making them server ops is just a way so you can report you have fewer
admins, basically you are adhering to the letter of some rule instead of the
intended spirit.
Someone who gives enhanced rights less than administrator
on a DC to someone either doesn't understand how Windows works (nor Forest
security) or assumes that the people they are giving the access to don't
know how it works or how to enhance themselves. The bad thing is they may
at some point those untrusted people may run some program that does know how to
enhance those permissions OR they learn how to do it themselves.
Basically what security do you think you have by not giving
them domain admins right up front?
This has been a popular
discussion point over the years on this list. Look through the
archives.
This also goes for people
who allow other non-admin groups to run things like monitoring, Software
Delivery, Auditing, and distributed AV solutions that have services running
on DCs as local system or with other high privileges that allow ad hoc software
load or process execution.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Abagnale
Sent: Friday, June 10, 2005 4:57 AM
To: [email protected]
Subject: [ActiveDir] mstsc /console switch for non admins
Hi,
Our IT Operations team will require access to our remote Windows 2003 DC's
which act as File & Print Servers.
At the moment, they are members of the Built-in domain Server Operators
group which they use Remote Desktop to connect through to the DC's for
data/print services support/administration which gives them the remote access
they require.
I would like them to use the mstsc /console switch however, it seems only
members of the domain administrators group can use this switch as they are
unable to logon.
The IT Ops user can logon to the server via the physical kvm console using
the same account and have access. Only through mstsc /console are they denied
access.
The Server Operators group have the following rights:
Allow logon through Terminal Services
Log on Locally
Log on Locally
Does anyone know of a way around this so I can allow Non-Admins use the
/console switch?
Any ideas or alternative workarounds appreciated and I already understand
that Non-admins are not supposed to logon to DC's but due to politics we have to
allow this...for the time being.
Thanks
- Frank
Discover Yahoo!
Have fun online with music videos, cool games, IM & more. Check it out!
