Re: Protecting AD OU's structure against deletion/moves...
- From: "Dmitri Gavrilov [MSFT]" <dmitrig@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 19 May 2008 10:14:53 -0700
Hm, on the second thought... If you do this, then people will come to associate letters D and G with all the weirdnesses in AD access checks. I withdraw the request.
Nice meeting you too!
--
Dmitri Gavrilov
SDE, Exchange
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Paul Bergson [MVP-DS]" <pbergson@xxxxxxxxxxxxxxxxx> wrote in message news:Op35DCbuIHA.552@xxxxxxxxxxxxxxxxxxxxxxx
I would never take credit for info provided by others so it will be in quotes and will Dmitri G at the end. I will eventually plagiarize it though. :-)
Nice to finally meet you at the MVP Summit.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dmitri Gavrilov [MSFT]" <dmitrig@xxxxxxxxxxxxxxxxxxxx> wrote in message news:uPmA975tIHA.6096@xxxxxxxxxxxxxxxxxxxxxxxSure Paul. Just one request: any time you use the below information to answer a similar question, you must use letters D and G in your reply.
I am kidding. You don't really have to :)
Here's one additional piece of info that's sort of relevant to this discussion. 2k8 ADUI tools also include the ADSIEdit tab, which is shown in advanced mode in ADUC and ADSS. I think this is very useful functionality as well. One thing that I learned (just this morning) is that ADSIEdit tab is not shown when you attempt to use Client RSAT in a w2k3 forest. The reason is that the display specifiers are not updated, and it's the display specifiers that cause the tab to be shown.
ADPrep /forestprep updates display specifiers info in AD. That's the only supported way... The unsupported way is to drop a few attribute values into adminPropertyPages attribute in all display specifier objects. The GUID representing ADSIEdit tab is C7436F12-A27F-4cab-AACA-2BD27ED1B773 if I remember correctly.
Some property tabs (e.g. terminal services tabs on users) will not show in Client RSAT because we did not include the required DLLs in the package.
--
Dmitri Gavrilov
SDE, Exchange
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Paul Bergson [MVP-DS]" <pbergson@xxxxxxxxxxxxxxxxx> wrote in message news:u%23NOWM3tIHA.4876@xxxxxxxxxxxxxxxxxxxxxxxDmitri,
Thanks for the granular details. If you don't mind I would like to save this info and use for similar questions in the future.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dmitri Gavrilov [MSFT]" <dmitrig@xxxxxxxxxxxxxxxxxxxx> wrote in message news:9D766613-2F6E-4C47-B698-1858D7873BB7@xxxxxxxxxxxxxxxxIn order to deny deletion, you must deny two things: delete on the object and delete-child on the container.
We have built the functionality to set such ACEs into WS2k8 ADUI tools. This is represented by "protect object from accidental deletion" checkbox on object tab in ADUC. You can download and install these tools on Vista workstations (search for "RSAT client" on msft downloads site). Note that these tools will work against downlevel DCs (all the way down to w2k), no schema extensions/adprep is required.
Note that setting inheritable permissions at the top of OU tree won't work, because admins are normally given explicit full control on each object, which will override your deny aces. You have to protect each OU individually. FWIW, new OUs created in ws2k8 ADUC are automatically "protected from accidental deletion".
--
Dmitri Gavrilov
SDE, Exchange
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Claude Lachapelle" <ClaudeLachapelle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:761303C5-9E1A-4601-8ACA-DADC9031A02D@xxxxxxxxxxxxxxxxHi!
I would like to know what is the best practice to protect an AD OU's
structure against unwanted deletion/moves from domain administrators (human
error).
I tried to apply "Deny" to "Delete" and "Delete subtree" to Everyone group
to the root OU I want to protect, but I'm still able to delete sub-OU of
this OU.
Even applying this security settings to a specific OU (ex: test), and
deleting it afterwards is still working!!!
What's wrong? Deny security should not take precedence over normal security???
Thanks.
Claude Lachapelle
Systems Administrators, MCSE
.
- References:
- Protecting AD OU's structure against deletion/moves...
- From: Claude Lachapelle
- Re: Protecting AD OU's structure against deletion/moves...
- From: Dmitri Gavrilov [MSFT]
- Re: Protecting AD OU's structure against deletion/moves...
- From: Paul Bergson [MVP-DS]
- Re: Protecting AD OU's structure against deletion/moves...
- From: Dmitri Gavrilov [MSFT]
- Re: Protecting AD OU's structure against deletion/moves...
- From: Paul Bergson [MVP-DS]
- Protecting AD OU's structure against deletion/moves...
- Prev by Date: Using NTDSUTIL to restore accounts - Help
- Next by Date: Exporting all the email addresses in our AD
- Previous by thread: Re: Protecting AD OU's structure against deletion/moves...
- Next by thread: Re: Protecting AD OU's structure against deletion/moves...
- Index(es):
Relevant Pages
|