I didn't get you wrong for any of it Jorge. :o) I was just saying what I thought about what I read. If I had thought, Jorge is on crack, I would have said Jorge is puffing the pipe, don't listen to that crazy guy!
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Wednesday, November 16, 2005 10:31 AM To: [email protected]; [email protected] Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered by AdminSDHolder Wait a sec... The first one was A solution (which was a direct answer to his question - is it possible to protect additional objects by the adminSDHolder object)... In the end I still recommended the separate OU with enforced perms. Please don't get me wrong for that Cheers, Jorge ________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Wed 11/16/2005 4:17 PM To: [email protected] Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered by AdminSDHolder I think this is the winner solution. :o) The DL idea scared me, what happens if someone or something decided to security enable it... Whoops. Unintended access. Also no point in loading up the scheduled SD process with additional workload. Hate to see some limit hit. I was chatting with someone once before about how funny it would be if someone lodged a bug with MS that the adminsholder functionality broke when there were > 1024 users that had to have their ACLs adjusted. I don't think this topic was OT at all for this forum. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 9:37 AM To: [email protected] Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered by AdminSDHolder Thanks Al. I think we've now agreed that a locked down OU along with auditing, monitoring and compliance checking/enforcement will suffice. Jorge's suggestion works fine - I've decided against this added complexity, however. I shall propose a change to adminsdholder when I next meet up with our MS rep :) Thanks. neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: 16 November 2005 13:57 To: [email protected] Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered by AdminSDHolder Neil, glad you found a way forward. Just food for thought: A script or compiled app has the advantage of being more flexible while also being very simple. It would wake up on a scheduled basis and verify the groups or users you specify. Same functionality, but focused on the particular needs of the customer scenario vs. general purpose. Otherwise, I agree you shouldn't have to reinvent the wheel to get something done. Personally, I opt for the separation and flexibility in this situation. I want to be able to control on a per object basis the exact rights and be able to log those checks for compliance reasons, as well as change the frequency as needed without impacting the global well being of the active directory service. Interested to hear how the testing with Jorge's approach works out in your situation. Al >From: <[EMAIL PROTECTED]> >Reply-To: [email protected] >To: <[email protected]> >Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered >by AdminSDHolder >Date: Wed, 16 Nov 2005 09:24:28 -0000 > >Thanks for the feedback everyone! > >Jorge - I like the idea of nesting inside a DL - we had considered >nesting into print ops but decided against it. Your approach has the >same end result with none (fewer?) of the issues. Can you confirm that >sdprop only changes ACLs for the well known protected objects? i.e. if >I manually change the admincount value to 1 on some other object, then >am I correct in assuming that sdprop will not touch that object? > >Al - we had also discussed using a script or other to mimic >adminsdholder, but then why re-invent the wheel if native tools can >achieve the same goal? I appreciate your concerns re changing >adminsdholder - I was hoping that the admincount value could be changed >manually for all my protected objects and thus cause sdprop to re-ACL >these objects. [see above] > >Our preferred approach right now is to simply place the 'protected' >objects inside a special OU and hide/protect those objects with >appropriate perms. I shall investigate Jorge's suggestion too, though, >since that ensures that the perms are enforced and refreshed on an >hourly basis. [I shall also test the admincount change mechanism just >for completeness :) ] > >Thanks again, >neil > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, >Jorge de >Sent: 16 November 2005 07:31 >To: [email protected]; [email protected] >Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered >by AdminSDHolder > >Morning all, (at least here it is) > >When users or groups are protected by the adminSDholder object they >"just" end up with the DACL from it where inheritance is disabled so >the objects don't get any DACL from a parent OU > >Another approach is: >When it is possible to have those custom users/groups in a same OU >without any other object, do that and configure strong protective DACL >on the OU those to-be-protected-users/groups are in. > >You can ask yourself: why are those groups you want to protect in the >OU where stuff has been delegated? If they are protected the delegates >will not be able to manage them, so you might as well put them in a >separate OU configure other DACL. > >Remember that an OU structure is based upon three things: >(1) Delegation of control >(2) Hidding objects >(3) Applying GPOs > >The groups you want to protect could fit in (1) and/or (2) > >So if you have the possible to do what I have mentioned here, it is >preferred to do that instead of what I have said earlier > >Cheers. > >Jorge > >________________________________ > >From: [EMAIL PROTECTED] on behalf of Almeida Pinto, >Jorge de >Sent: Tue 11/15/2005 11:13 PM >To: [email protected] >Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered >by AdminSDHolder > > >To make a protected member of a protected group a NON-PROTECTED object >you need to: >* remove his membership from the protected group >* enable inheritance again on the object >* set the admincount attribute to 0 or to <not set> > >What is said is that by removing the member from a protected group, >inheritance will not be changed automatically and the admincount >attribute will also not be changed automatically. All must be changed >manually and when reverting the object back to a non-protected oject it >is best to do all three! > >So, yes I also agree with those recommendations > >Jorge > >________________________________ > >From: [EMAIL PROTECTED] on behalf of David Cliffe >Sent: Tue 11/15/2005 9:56 PM >To: [email protected] >Subject: RE: [ActiveDir] [Slightly OT] Protecting objects not covered >by AdminSDHolder > > >Jorge --> "The group membership of a protected group is the criteria >the process looks at, not the attribute value of 1. The admincount >attribute is just an administrative measure for the process that says >"been here", nothing else." > > This implies that if you later go back and remove a user from any >protected groups, you can then go set his ACL back to what you want, >and not have to worry about the admincount attribute still having a >value of 1, right? Only reason I ask is because I could have sworn >I've seen recommendations on this list to set that attribute back to 0 >after removing all protected group memberships, so just double checking. >Maybe there were other factors involved in those previous >recommendations which I didn't read close enough! > > Also, interesting approach to the original poster's question. >Thanks! > >-DaveC > > >________________________________ > > From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, >Jorge de > Sent: Tuesday, November 15, 2005 3:22 PM > To: [email protected] > Subject: RE: [ActiveDir] Protecting objects not covered by >AdminSDHolder > > > That sounds logical. However the adminsdholder process only looks at >users and groups that are defined in AD as protected objects. >As mentioned in MS-KBQ817433 - "Delegated permissions are not available >and inheritance is automatically disabled" it is possible to include or >exclude some of the default admin groups (account operators, print >operators ,etc.) The process that checks object against the >adminSDHolder object only looks at that definition of protected objects >and in case of groups it will also look at its members. It resets the >DACL to match the DACL of the adminSDHolder object and sets the >admincount attribute to 1. The group membership of a protected group is >the criteria the process looks at, not the attribute value of 1. The >admincount attribute is just an administrative measure for the process >that says "been here", nothing else. > So, to add custom groups as protected groups in AD, MS should see if >it is interesting to implement in Longhorn. > There is a way however to implement your own protected groups. >(I think it will work) > How to do that? > * Take a protected group (weakest one possible) > * Create a distribution group with a name like >"Custom_Protected_Groups_Definition" and make that a member of the >actual protected group > * Put all custom users and groups directly into the distribution group >that need to be protected by adminSDHolder > > Now what will happen? > The adminSDHolder process sees the memberships (transitive >included) and protects them. > When a user logs on, he will be a member of the distribution group >"Custom_Protected_Groups_Definition" but the SID of the actual >(security) protected group will not be in the access token of the user. > If a distribution group is a member of a security group, the members >of the distribution group will not be transitive security members of >the security protected group as the distribution group blocks the >security group membership > > There is a catch however! -> DO NOT EVER CONVERT THE DISTRIBUTION >GROUP TO A SECURITY GROUP! (doing this will lift the security group >membership block and the users/group will suddendly get the SID of the >protected security group in their access token!) > > I agree with Al you should be very careful changing the configuration >of the DACL of the adminSDHolder object! Remember that object protects >the default (very strong) users and groups! > > Cheers, > Jorge > (cool: I think I just wrote something nice for my blog) > >________________________________ > > From: [EMAIL PROTECTED] on behalf of Al Mulnick > Sent: Tue 11/15/2005 7:04 PM > To: [email protected] > 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: <[EMAIL PROTECTED]> > >Reply-To: [email protected] > >To: <[email protected]> > >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/ > > > > >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of >Reuters Ltd. > > > >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. >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/ > > > >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/ 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/ 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/ 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/ 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/ 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/
