| Author | Messages | |
AD000001290
Posts:0
 | | 11/15/2005 5:31 AM |
| [I appreciate and understand the role of adminsdholder and sdprop and which objects it protects and how etc etc.]
I'm sure the answer to my question will be 'no' but I have to ask in any case :)
Can additional groups and/or user objects be added to the scope of sdprop and adminsdholder, so that they are protected as are other objects, such as members of the Domain Admins group?
I have additional groups which are protected today by virtue of being in a segregated OU, where special permissions are applied. I would rather protect these objects with adminsdholder, which I find to be a more robust (and enforced) approach.
Is this possible? Are there plans to add the functionality in later editions (Longhorn) perhaps?
Thanks,
neil
___________________________
Neil Ruston
Global Technology Infrastructure
Nomura International plc
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies. | | | |
| AD000001348
Posts:0
| | 11/15/2005 6:34 AM |
| That's interesting. As far as I can tell, the adminsdholder is just a
process that runs on the PDCe that wakes up and checks for all objects that
have admincount set to 1. For each it finds, it ensures that they reflect
the permissions set according to the adminsdholder reference.
My first pass at this would be to do likewise with a custom app vs. trying
to piggy back on the adminsdholder routine. The reason I say this is that I
wouldn't want any kind of confusion in the settings and it's generally not a
recommended solution to modify the adminsdholder. Can be very bad if you do
so incorrectly.
Any reason a script or other app wouldn't be a choice? I realize you're
looking for apps that already exist first, but just curious what the
boundaries are. :)
Al
From:
Reply-To: ActiveDir@xxxxxxxxxxxxxxxxxx
To:
Subject: [ActiveDir] Protecting objects not covered by AdminSDHolder
Date: Tue, 15 Nov 2005 16:16:24 -0000
[I appreciate and understand the role of adminsdholder and sdprop and
which objects it protects and how etc etc.]
I'm sure the answer to my question will be 'no' but I have to ask in any
case :)
Can additional groups and/or user objects be added to the scope of
sdprop and adminsdholder, so that they are protected as are other
objects, such as members of the Domain Admins group?
I have additional groups which are protected today by virtue of being in
a segregated OU, where special permissions are applied. I would rather
protect these objects with adminsdholder, which I find to be a more
robust (and enforced) approach.
Is this possible? Are there plans to add the functionality in later
editions (Longhorn) perhaps?
Thanks,
neil
___________________________
Neil Ruston
Global Technology Infrastructure
Nomura International plc
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete
your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by
law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those
of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation
or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St
Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ | | | |
| ZJORZ
Posts:133
| | 11/15/2005 8:26 AM |
| Cheers,
Jorge
(cool: I think I just wrote something nice for my blog)
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Al Mulnick
Sent: Tue 11/15/2005 7:04 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Protecting objects not covered by AdminSDHolder
That's interesting. As far as I can tell, the adminsdholder is just a
process that runs on the PDCe that wakes up and checks for all objects that
have admincount set to 1. For each it finds, it ensures that they reflect
the permissions set according to the adminsdholder reference.
My first pass at this would be to do likewise with a custom app vs. trying
to piggy back on the adminsdholder routine. The reason I say this is that I
wouldn't want any kind of confusion in the settings and it's generally not a
recommended solution to modify the adminsdholder. Can be very bad if you do
so incorrectly.
Any reason a script or other app wouldn't be a choice? I realize you're
looking for apps that already exist first, but just curious what the
boundaries are. :)
Al
>From:
>Reply-To: ActiveDir@xxxxxxxxxxxxxxxxxx
>To:
>Subject: [ActiveDir] Protecting objects not covered by AdminSDHolder
>Date: Tue, 15 Nov 2005 16:16:24 -0000
>
>[I appreciate and understand the role of adminsdholder and sdprop and
>which objects it protects and how etc etc.]
>
>I'm sure the answer to my question will be 'no' but I have to ask in any
>case :)
>
>Can additional groups and/or user objects be added to the scope of
>sdprop and adminsdholder, so that they are protected as are other
>objects, such as members of the Domain Admins group?
>
>I have additional groups which are protected today by virtue of being in
>a segregated OU, where special permissions are applied. I would rather
>protect these objects with adminsdholder, which I find to be a more
>robust (and enforced) approach.
>
>Is this possible? Are there plans to add the functionality in later
>editions (Longhorn) perhaps?
>
>Thanks,
>neil
>
>
>___________________________
>Neil Ruston
>Global Technology Infrastructure
>Nomura International plc
>
>
>
>PLEASE READ: The information contained in this email is confidential and
>intended for the named recipient(s) only. If you are not an intended
>recipient of this email please notify the sender immediately and delete
>your
>copy from your system. You must not copy, distribute or take any further
>action in reliance on it. Email is not a secure method of communication and
>Nomura International plc ('NIplc') will not, to the extent permitted by
>law,
>accept responsibility or liability for (a) the accuracy or completeness of,
>or (b) the presence of any virus, worm or similar malicious or disabling
>code in, this message or any attachment(s) to it. If verification of this
>email is sought then please request a hard copy. Unless otherwise stated
>this email: (1) is not, and should not be treated or relied upon as,
>investment research; (2) contains views or opinions that are solely those
>of
>the author and do not necessarily represent those of NIplc; (3) is intended
>for informational purposes only and is not a recommendation, solicitation
>or
>offer to buy or sell securities or related financial instruments. NIplc
>does not provide investment services to private customers. Authorised and
>regulated by the Financial Services Authority. Registered in England
>no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St
>Martin's-le-Grand,
>London, EC1A 4NP. A member of the Nomura group of companies.
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
> | | | |
|
|