I received a some offline questions on this that can
be collected into three main questions
1. What are the things these non-admin but natively
enhanced users do to compromise the DC or enhance their
permissions?
2. What would you do in this situation?
3. SBS seems to contradict everything you say, MS obviusly
doesn't have an issue with these things all being together.
The first I will not respond to in any real detail. I do
not want a response from me becoming the guidebook for evil people on how to
escalate privs on a DC and compromise a forest, I am not thinking any customers
I help would be appreciative of that because there really is no feasible way of
locking this stuff down. Suffice to say that someone in that position can run
anything they want to on the DC and can easily get a security context over and
above what they should have. If you want the simplest stupid thing that could be
done is they could put a trojan on the box that some silly domain admin runs.
Alternatively, because this is a higher bar item I will mention it, servops can
load drivers. Say like a keyboard driver...Those are the hard ways to get things
done.
The second is tough, it depends on the specific situation.
However those that have worked with me on projects directly know that if a hard
problem comes up, I can become pretty creative. If I am responsible for the
security of a domain controller, I can be extremely creative.
First off, print sharing. I wouldn't do it through
the DC, most corporate printers now are connected through the network and have
their own queuing mechanisms, use them. If it has to go on a DC, I as a domain
admin, would handle all server based operations around it. I would not delegate
it directly. As I had time, I would whip up a web based proxy system to give
others the ability to do limited operations scoped by specific business rules on
the print queue, such as being able to clear it maybe. I have done this in the
past.
Second off, file sharing. Again, I wouldn't do it through
the DC. I think setting up file sharing through a DC is one way to lower your
availability of f&p shares. Domain controllers sometimes have to be rebooted
to clear various replication issues. The key components are so deeply embedded
in DCs that you can't just stop and start pieces. MS is working on that, but at
the moment, it isn't there. If you have a replication issue or authentication
issues, do you boot everyone out of the shares so you can fix it? If so do you
go to everyone's desk to make sure they properly close the Office Docs so they
don't get corrupted? If I had to do it, again, domain admins would have a new
job, managing the file share info and backup processes. The file shares would
not be on any physical disk with my OS or AD files. I would work on delegating
off specific items through a web proxy again with specific business rules. I
would also make it so the stuff created could NOT be regularly accessed by
Domain Admins (only allow backup access which is handled through different
perms). This could be overridden so I would set up a process that constantly was
rewriting ACLs on the shares and the folder structures. Reason being, you don't
need some admin accidently running some program that some knuckle head uploads
to the server that can cause harm if run by someone with a lot of rights. But
wait, domain admins need to be able to work and they keep files on those servers
to.... Domain Admins should not be using Domain Admin IDs for most work, they
should only use those special IDs when they are purposely making changes or
looking at something they absolutely can not get to without the domain admin ID.
I was a domain admin for a long time, by far, most of my time was
spent using a normal userid for troubleshooting and daily work.
The third question, SBS. Do not take your environment
security and operations cues from SBS. SBS is a very specific product for a very
specific niche. It comes with you having to understand that you are compromising
best security and system operating practices strictly for the sake of saving
money. Microsoft isn't saying these things are ok to do, they are saying, hey
there is a market here and we are going to take advantage of it, if the
customers are willing to assume the risk to save the money we are willing
to supply the product for them to do so.
If any decent sized company started running their
environment by spinning up DCs with all SBS services and got MS in to do a
review MS would almost certainly report issues with it. SBS is the solution when
cost overrides security very early on in the game. If someone ever comes up with
something to target SBS by coming through one of the many possible penetration
vectors and then targeting the domain controller aspects, there are going to be
a lot of small businesses that are really hurting. Imagine, if you will, an
attack that comes through one of the random and many services on the machine and
gets localsystem access rights and takes over the machine. That attack can now
successfully eat every other machine in that domain. Done properly, an attack
here would completely wipe out all Windows computing cabability of the business
very quickly and very easily.
This is why you always run as few services and people
with access rights on Domain Controllers. The more vectors for attack you have,
the more insecure you are. Add to that that a domain is NOT a security
boundary. I won't describe the mechanisms but someone you give serv op
rights (or even less) to in one domain one night could find you
looking at that same person with Enterprise Admin rights the next morning while
you have no rights to correct it without hacking the DC at a core rather
unsafe level.
joe
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!
