Re: DC Admin question

> 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
    ... 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: 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: Restricted Group - [WILDPACKET]
    ... This posting is provided "AS IS" with no warranties, and confers no rights. ... >> printers but are not local admins. ... >> - Created a Group and added Admin and one test user. ...
    (microsoft.public.windows.server.active_directory)