Re: DC Admin question


"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:eNMYXuMPHHA.1248@xxxxxxxxxxxxxxxxxxxxxxx
Personally, I think there is a middle ground between the "if they
are evil and if they are not". If they are well intended, and
would not elevate themselves, then they may be careful or
wreckless as far as exercise of administrative empowerment.

Sure there is for people, but likely the person you aren't giving the
enhanced rights to is for some, likely good, reason. Maybe that person
isn't evil intending but just a little sloppy and maybe runs something
that is evil intending and/or far more informed about how Windows works
than the person running the app. Maybe that person gets pushed over the
edge and does evil things. I don't think anyone is positively evil and
anyone is positively good, they are a mixture with the part showing that
reflects their current mood and circumstances. Even god fearing fathers of
8 angelic children can be pushed into doing things truly bad by
circumstances. This is something that needs to be taken into account when
offering up any forms of trust. Much better to disallow someone from
having any ability to harm you than trust that they won't.


True enough for a human factors analysis.
I was also trying to move toward ways to meet the use cases
of the poster without having to deal with giving out admin, which
actually was the middle ground I was meaning here, alternative
solutions to the unacceptible obvious one of giving admin.

Giving someone local logon to a DC or any server opens up far more vectors
for attack. The Microsoft security model prior to Vista is such that if
you are on the console, you are pretty highly trusted. I.E. I have let you
into my house and most doors in the house aren't as well locked as the
door to get into the house. Of course MSFT has another level of insecurity
in terms of if you can stand in the same room with a machine and can work
on it unhindered you can own it as well. There is really nothing realistic
you can do about that at the moment, hopefully Bitlocker will help there
in Longhorn so right now it is a risk with any DC in an unsecured location
and by unsecured I mean in a location which is accessible to someone who
isn't fully trusted end to end with the machine. Still that is more
acceptable to me as a risk than giving someone local logon rights. There
is no chance for accidental compromise if a box is simply physically in
the same room as you, someone must take proactive purposeful steps to
initiate the compromise which is much easier to prove.


Not really. The read-only DC will just protect AD.

Correct, it is to protect AD but that is the primary issue with the DCs
people want to delegate rights off too... AD is at risk. The RODC will
protect the forest in that you can assign admin rights to a single DC and
theoretically, for now, there is no way to do anything on that one DC to
escalate yourself further into the forest. Obviously you will be able to
do anything you want to the DIT on that specific DC and anyone in that
site using that DC will be at risk. This is far better than what we have
now. Now admins will have the option of putting themselves at risk with
how they manage the secret caching policy like for instance if they say,
yeah, cache admin passwords on DCs, then someone who is made an admin of
that DC will be able to retrieve the hash and go from there.


It is just this part on which I am presently withholding judgement
and theoretically, for now, there is no way to do anything on that one DC
to escalate yourself further into the forest.
as it is quite difficult to see a waterproof block on getting system.


If I am responsible for a forest, there is nothing that could get me to
give rights to a non-DA for DCs, that would be a quitting offense for me.
I would assume the work load and most likely automate it or set it up to
work through some web based proxy admin tool that I bought or wrote. I
have done that in the past, it makes for more initial work for me up front
but down the road things are much more secure and my life is much easier
because I don't have questions or confusion or doubt in my mind about what
might or could have happened when something goes pear shaped. The current
consequences of giving folks enhanced rights on DCs who aren't actually
responsible for the forest as a whole is too high with the current
security model for my tastes.


Sure Joe - but just stating to poster that they have no solution,
which is true when considering only achieving their deployment
objective (manage shares on DCs, install printers on DCs), is
not looking at the use case needs and alternative fulfillments.
I have nowhere advised poster to give the local tech anything
other than a domain user account, but to find ways to let that
do with the remote office needs.

Roger


.

Relevant Pages

  • Re: DC Admin question
    ... Not just from the obvious security issues of allowing someone to install a kernel level component but just from the fact that printers can be quite unstable resources, I would be very careful what printers get put on DCs, actually I would prefer no printers on DCs nor even queues, today's corporate printers don't need them, they can do most all of that internal. ... Sure there is for people, but likely the person you aren't giving the enhanced rights to is for some, likely good, reason. ... solutions to the unacceptible obvious one of giving admin. ...
    (microsoft.public.windows.server.security)
  • Re: DC Admin question
    ... If someone needed to manage file shares, I would say, there are these X ... I would prefer no printers on DCs nor even queues, ... enhanced rights to is for some, likely good, reason. ... solutions to the unacceptible obvious one of giving admin. ...
    (microsoft.public.windows.server.security)
  • Re: DC Admin question
    ... Sure there is for people, but likely the person you aren't giving the enhanced rights to is for some, likely good, reason. ... Maybe that person isn't evil intending but just a little sloppy and maybe runs something that is evil intending and/or far more informed about how Windows works than the person running the app. ... The RODC will protect the forest in that you can assign admin rights to a single DC and theoretically, for now, there is no way to do anything on that one DC to escalate yourself further into the forest. ... Now admins will have the option of putting themselves at risk with how they manage the secret caching policy like for instance if they say, yeah, cache admin passwords on DCs, then someone who is made an admin of that DC will be able to retrieve the hash and go from there. ...
    (microsoft.public.windows.server.security)
  • Re: Administrative rights on specified domain controller
    ... If you need actual admin rights you can't. ... Plus an admin account can trivially escalate themselves to domain and enterpise admin level rights. ... There are some things you can delegate, say like stopping and starting services but doing any of that can be very dangerous with DCs because there are various mechanisms that people can use to escalate their rights or otherwise cause DCs to malfunction. ...
    (microsoft.public.win2000.security)
  • RE: bin/22595: telnetd tricked into using arbitrary peer ip
    ... >> provider I actually came from to do all those very evil things... ... And probably an admin doesn't even know where the host was before as ... One thing that should be considered to be done if an API is created... ... with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)