Re: DC Admin question

I think we are standing on the same hill.

Per the original post, I am still with, it is all in the "etc".
Centrally define the shares and allow mgmt of their content
via mapping, place the print queues on a workstation, and
hope to find ways to address each other "etc".

Roger

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:Oo8PKXNPHHA.4368@xxxxxxxxxxxxxxxxxxxxxxx
It is just this part on which I am presently withholding judgement

Yep, until we get it out in the real wild and people get to really beat
against it, who knows where we will go. Though from my talks with the DS
guys, I think they are doing a bang up job to plug the holes. The only
thing (outside of the previously mentioned poor secret caching policy) I
could think of right now that could possible cause an issue from an RODC
would be if the person already had access to the directory and could find
some way to force the replication. Obviously if they have that, they don't
need the RODC at all.

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.

Understood, but I think even granting local logon is going too far. There
are exploits that have come out that simply required local interactive
access to allow for escalation and in addition, not everyone is very good
at locking machines down against local access. The security model really
is based on the non-trusted folks being on the outside of the box tapping
against network interfaces, not the inside.

If someone needed to manage file shares, I would say, there are these X
shares on the server. You don't get to manage those, but I will let you
manage the NTFS perms under that, but you do it through the shares.
Printers would be right out, wouldn't let them get near it. 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. Every
externally available handle on a DC I can kill I kill as every single one
is a possible vector for attack.


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Roger Abell [MVP] wrote:
"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
    ... 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: DC Admin question
    ... are evil and if they are not". ... solutions to the unacceptible obvious one of giving admin. ... acceptable to me as a risk than giving someone local logon rights. ... it is to protect AD but that is the primary issue with the DCs ...
    (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: Accessing C$
    ... Shares don't have passwords. ... This posting is provided "AS IS" with no warranties, and confers no rights. ... > About hidden c$ admin share... ... > - 1 user account per PC, ...
    (microsoft.public.windowsxp.network_web)