Create a plan that allows for flexible delegation and proper naming of roles but don't build the actual delegation until it is needed.
-- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Wednesday, July 26, 2006 3:30 AM To: [email protected] Subject: Re: [ActiveDir] ldp in ADAM-SP1 Thanks Guido. That helps a lot. I was going to create the role structure but leave them unpopulated and do most of the work myself. I.e I am all roles!! I was then going to populate them as and when I found skilled and trusted chaps. I'll keep it very simple now. Cheers M@ P.S. Thanks again to everyone that read and responded. On 7/26/06, Grillenmeier, Guido <[EMAIL PROTECTED]> wrote: > well, do as you should always do to ensure that your systems are > maintainable: keep it simple! > Don't introduce extra complexity if you don't require it. For AD ACLing > this means, don't introduce roles and permissions for users, if you do > not need that role - there is certainly no need to implement all the > roles that are described in the delegation whitepaper to maintain a > stable AD infrastructure. > > most ACLing issues that I have come across was in companies that granted > their delegated admins the rights to create OUs underneath their > location specific OU - soon afterwards they had an AD structure with OUs > and permissions that looked like a badly managed file-server... > > so the issue is not so much setting ACLs in AD (which as discussed can > be a complex task to do right, depending on your needs), but more > controlling who is allowed to set ACLs. This should be done centrally by > domain and/or enterprise admins. As a rule of thumb you should not grant > any non-domain or enterprise admin the rights to create OUs and also > limit the rights to create any other objects (especially groups) to very > few delegated admins. Less critical is delegating the ability to manage > existing objects (e.g. to reset PW of user, mail-enable users and > groups, change membership of groups, etc). I also consider the rights to > create computer objects as low risk (which is usually required by local > desktop admins in branch offices). > > /Guido > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha > Weerasinghe > Sent: Tuesday, July 25, 2006 9:18 PM > To: [email protected] > Subject: Re: [ActiveDir] ldp in ADAM-SP1 > > Thanks to Al and Guido for your further input. Even though it may seem > pretty obvious, I would like to know of any horror stories due to AD > ACL'ing if possible. The reason is Al's comments have made me take a > much more cautious approach to ACL'ing. I get the feeling that even > though the granular feature is there, if there arent enoug people with > the correct skill level available to maintain it, then it shouldnt be > pursued. I hope I can get that skill and that is one fo the goals > here. But I may not be here all the time..... > > So any stories from anyone ? > > M@ > > On 7/25/06, Al Mulnick <[EMAIL PROTECTED]> wrote: > > > > I wholeheartedly applaud the effort being put into this. That said, I > urge > > you to reconsider your administrative model and favor as much > simplicity as > > is possible. Why? Because the best laid plans of mice and architects > and > > all that. > > > > "The tricky bit is the matching a trusted and > > appropriately skilled person to the relevant role." > > > > That makes me laugh and cringe at the same time. Yes, it is very > difficult > > to find that "perfect match" but at the same time I think a design > should > > take that into account where possible. That's a design philosophy and > I > > won't debate that for this thread. But I would caution you that any > design > > that has the people intricately relied upon is going to have a failure > point > > at some point when you least can tolerate it. > > > > While you can use the command line tools as much as possible, as joe > and > > Guido both pointed out, consider rolling your own scripts if you > absolutely > > cannot do what you *need* to do at the GUI. But remember you can > really > > really really^^ hurt yourself with security permissions. Believe me, > it can > > be ugly and it can be the undoing. > > > > Two thoughts consider as you walk through the design: > > 1) You should never try to solve wetware issues with software or > hardware. > > 2) Complexity is the anti-security. > > > > Best of luck. > > > > > > > > On 7/25/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> wrote: > > > Wow, > > > > > > Thanks you so much for the detailed info guys. Basically my goal is > > > quite simple. At least it is in my head. What I want to do, is to go > > > through the entire case study given in the AD delegation whitepaper, > > > and do all of that permissions configuration entirely at command > line > > > (where possible). I am willing to use the delegation wizard to some > > > extent, but as I am configuring quite a lot of permissions for an AD > > > design I am involved in, I would rather avoid having to use GUI > tools > > > for this. > > > > > > You see, I am going to end up as been a very privileged service > > > administrator and data administrator once my proposed AD design > model > > > is in place. I expect I will be making some endeavour to train > > > sufficiently capable people in doing this. But I dont plan to spoon > > > feed. I want the guys to know to a decent level ACL'ing and if not, > do > > > their research. At least on an adhoc basis. Then once they > understand > > > whats involved, they can go ahead and add/modify/delete ACE's , > revoke > > > perms, define new roles etc... > > > > > > Reading this delegation doc has made me believe I can configure an > > > extremely secure delegation model where each role can be given just > > > enough to do that role. The tricky bit is the matching a trusted and > > > appropriately skilled person to the relevant role. > > > > > > So you see, as there is a lot involved and this is a big > > > infrastructure to attempt to administer perms for 20,000 users plus > > > many OUs used to organise users based on the business unit (at least > a > > > dozen in each geographical hub) they work in and the site (we have > > > more than a 40 geographical hubs and 1000 satellite sites) they are > > > located at. Different levels of data admin roles. I would like to > get > > > this right to a large extent from the moment go. Admittedly it may > not > > > be big as in Fortune 5 ADs. But its the biggest I've had the > privilege > > > to design and support. > > > > > > I figured if I test this using the case study as a lab, I will get a > > > good feel of whats involved in my lower level design. I am getting a > > > little miffed when I have to swap between several tools to do what I > > > need to do. There is just so many buts and ifs. "You can do this but > > > you cant do this. To do this use this. For this use that. And then > > > try this. If all else fails script ...." > > > > > > I admit I was ranting a bit when asking why is this named and like > > > such and the discrepencies in the docs and syntax help of command > line > > > tools. My sincere apologies for been anal. > > > > > > Is it too much to ask, to have at the very least a reliable command > > > line or GUI tool (ldp) to configure perms just the way I want and > > > need? Actually I don care even if I have to use a series of command > > > line apps. I dont care how complex it is/willbe right now. I just > want > > > something that works. And I want the tool from MSFT. For free ;0) > > > > > > Please! > > > > > > Cheers > > > > > > M@ > > > > > > > > > P.S. thanks once again for reading, for escalating, for laughing, > for > > > educating , the kind words, hugs > > > Control-H,Control-H,Control-H,Control-H,Control-H, etc... > > > > > > > > > > > > On 7/25/06, Grillenmeier, Guido <[EMAIL PROTECTED] > wrote: > > > > I guess Matheesha's original question has been answered as good as > it > > > > can for now with the information given. I just quickly want to > comment > > > > on the 3rd party tool aspect joe is mentioning below - naturally, > before > > > > spending considerable money on the tools, you'd need to test if > they do > > > > what you want them to do in the first place. > > > > > > > > What I've found from many years of leveraging and checking > different > > > > ACLing tools is that they also just go so far... I've had various > > > > different customer requests, which could not be achieved with the > tools, > > > > but could be achieved with the native ACLs (mostly talking AD > here). > > > > After getting over the hurdles of the basics, scripting quickly > becomes > > > > your friend. I am not saying that 3rd party tools aren't quite > useful > > > > for general ACLing stuff - it's when your own security model is > complex, > > > > the tools will often not be able to help you reach your goal. > > > > > > > > Often this is a result of the complex ACLing rules build by MSFT > > > > themselves. Very hard for a developer to keep up with all changes > (think > > > > of all the changes in Win2003 compared to 2000 and then with > Win2003 > > > > SP1) and to understand the plethora of rules, especially when it > comes > > > > to combining specific ACLing settings set at totally different > places in > > > > the directory. A great example for this are various options to > > > > controlling delegation of password settings (I've written this up > > > > internally and for my upcoming Windows security book, as joe had > been > > > > pointed at in his other reply). Win2003 provides three new not so > well > > > > known extended rights, which allow domain admins to control which > > > > delegated admin can change critical password attributes on user > > > > accounts: > > > > > > > > * Enable-Per-User-Reversibly-Encrypted-Password > > > > * Unexpire-Password > > > > * Update-Password-Not-Required-Bit > > > > > > > > The challenge: these extended rights are set at the domain level, > while > > > > other permissions to control which delegated admin can do what in > an OU > > > > (e.g. create and manage users) are typically set at the OU level. > So if > > > > you give a delegated admin full control over users, he would for > example > > > > not be able to set the "Password never expires" and the "Store > password > > > > using reversible encryption" options on the user accounts he is > allowed > > > > to fully control, UNLESS he is ALSO granted the appropriate > extended > > > > right at the root of your domain ("Unexpire-Password" and > > > > "Enable-Per-User-Reversibly-Encrypted-Password" in this > > example). > > > > > > > > This is certainly challenging for any domain admininstrator and > moreso > > > > for 3rd party ACLing tools. Realize that by default the three > extended > > > > rights I have mentioned above are granted to Authenticated Users, > which > > > > means that any delegated admin who is also granted the rights to > control > > > > the account restrictions of a user can set the respective password > > > > options. As these are rather sensible settings though, I'd rather > > > > disable any delegated admin from setting them (which is why the > extended > > > > rights have been added to Win2003 in the first place). If you > have > > > > different admins allowed to create users, just check out your > domains > > > > and see how many users are configured with the "password never > expires" > > > > flag - you will quickly understand what I mean. > > > > > > > > But again: it is very tough for 3rd party tools to remove default > rights > > > > for you => they usually just handle adding permissions and it is > up to > > > > you to fully understand the ACLing concepts of Windows to make > > > > everything work correctly. > > > > > > > > /Guido > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf > > Of joe > > > > Sent: Monday, July 24, 2006 7:00 PM > > > > To: [email protected] > > > > Subject: RE: [ActiveDir] ldp in ADAM-SP1 > > > > > > > > Yes the tools are not quite what they could be. A lot of this is > based > > > > on > > > > the complexity of the subject. The model is quite cool but it is > also > > > > quite > > > > complex and getting more so. Look at the confidential attribute > hack and > > > > the > > > > extended rights for protecting userAccountControl (Update Password > Not > > > > Required Bit, etc). > > > > > > > > When you take into account all of the special rules in the DIT > (usually > > > > around SAM attributes) which conflict with schema definitions as > well as > > > > the > > > > special cases of ACLing like the confidentiality bit and the > > > > userAccountControl "modifiers" etc, the inheritence model it is > very > > > > difficult to write one tool to handle all of the various cases to > tell > > > > you > > > > what you have and to help you get to what you want. An additional > > > > difficulty > > > > is that Microsoft isn't quick with updating tools to handle new > > > > features. > > > > > > > > Now third parties get into this realm and start playing but for > many > > > > people > > > > that just pisses them off and makes them say... Hey Microsoft > should > > > > already > > > > be supplying this, I'm not buying something. That combined with > the fact > > > > that just maybe MSFT will realize they should correct this will > tend to > > > > kill > > > > most third party folks from even going into that realm. > > > > > > > > Oh another additional complexity and LDP actually exposes this. > You > > > > could > > > > create a tool that could build any kind of ACL you want without > making > > > > any > > > > judgements on what is being done so that at a later time if > something > > > > changes the tool doesn't have to be corrected. However, there are > few > > > > people > > > > who understand how ACLs really work and are configured to the > point that > > > > the > > > > tool would really be useful to any large number of people. > > > > > > > > Something we recommended previously to MSFT is that we need to > radically > > > > update the ACL dialog editors for ADUC, etc so that they have an > easy > > > > mode > > > > and an advanced mode for those who really understand what they are > > > > doing. > > > > The challenge to MSFT is to work out the easy mode, you don't want > it > > > > too > > > > simply and ineffective and the advanced you still have to be > careful > > > > with > > > > because there are a lot of people out there who think they are > advanced > > > > security/AD people and they really don't have enough of a clue > other > > > > than to > > > > really hurt themselves. > > > > > > > > But yes, every MSFT security tool out there has some shortcoming > in it. > > > > The > > > > new LDP is the most flexible and has the most capability but as > you have > > > > found, there are some bugs in it. We have reported those bugs, > hopefully > > > > they will be corrected. The issue then becomes one of release. > More than > > > > likely I expect we wouldn't see something before Longhorn and > maybe not > > > > even > > > > before Longhorn R2. I hope that isn't the case, but expect it will > be > > > > Longhorn timeframe. > > > > > > > > So the question comes down to are people willing to spend $1000 or > $2000 > > > > or > > > > $5000 or more on tools to manage the ACLing in their directory? If > so, > > > > third > > > > party tools are the answer. I am aware of a couple of tools that > do > > > > things > > > > in this area, BindView (BVAdmin/BVControl) and Active Roles. > However > > > > again, > > > > usually people immediately start talking about costs and the fact > that > > > > MSFT > > > > should be supplying the tools to do this. I am not arguing the > point, > > > > but > > > > that is where we are at at the moment. > > > > > > > > I will say this, writing c code around ACLing is not trivial. From > what > > > > I > > > > understand the NET 2.0 framework is alleged to make this much > easier. > > > > Usually easier means less flexibility and builtin assumptions but > I > > > > don't > > > > know enough about it to speak to it for the NET Framework. > > > > > > > > As a sidenote... I just this second received an email from the > developer > > > > working on LDP and can say that he is digging into this. I can't > say > > > > much > > > > more than that though. > > > > > > > > > > > > joe > > > > > > > > > > > > -- > > > > O'Reilly Active Directory Third Edition - > > > > http://www.joeware.net/win/ad3e.htm > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto: [EMAIL PROTECTED] On Behalf > > Of Matheesha > > > > Weerasinghe > > > > Sent: Monday, July 24, 2006 11:32 AM > > > > To: [email protected] > > > > Subject: Re: [ActiveDir] ldp in ADAM-SP1 > > > > > > > > I dunno about you guys but I am very disappointed with the tools > > > > available to me for configuring perms. dsacls can configure most > perms > > > > but cant configure control access rights to certain attribs of > certain > > > > objects. (e.g. when you configure an attribute as confidential and > > > > need to allow certain people the control access right to view the > > > > attribute). dsacls also cant display perms that great and gives > > > > details as "special access". In order to see whats special, I have > to > > > > use something like acldiag and sdcheck. And then to revoke, yet > > > > another tool dsrevoke which only works on domain objects and OUs. > > > > > > > > After reading joe's book I figured ldp.exe from ADAM-SP1, here I > come. > > > > Now that also has issues. > > > > > > > > I know I can write scripts for handling this. But they are > cumbersome > > > > and slow. I think a nice fast C++ tool that does all this would be > > > > much appreciated. I am not sure how hard this is to do. But MSFT > > > > certaintly have the expertise. May be longhorn will ship with > > > > something like that. But I aint holding my breath. > > > > > > > > I am no expert and no MVP. I aint convinced my rant is gonna be > heeded > > > > to. But please, guys out there with the influence (MVPs) help!! > > > > > > > > M@ > > > > > > > > > > > > P.S Please!!! > > > > > > > > > > > > On 7/24/06, joe <[EMAIL PROTECTED] > wrote: > > > > > Beautiful, this is bug week.... > > > > > > > > > > There are actually two bugs here. > > > > > > > > > > 1. The inherit only check box is greyed out. This is the > checkbox you > > > > would > > > > > need to check in order to specify an inherit only ACE (i.e. > Child > > > > Objects > > > > > Only). > > > > > > > > > > 2. When you try to work around it and specify the actual object > types > > > > to > > > > > inherit to it creates two ACEs instead of one. The first ACE is > the FC > > > > > inherit only to the object class you specify but then there is > also a > > > > FC > > > > to > > > > > the object itself. In the example below note the TEST\joe > ACEs... I > > > > only > > > > > added a single FC for nTDSConnection objects for test\joe but > got that > > > > AND > > > > > the non-inheritable Test\joe FC on the object itself. > > > > > > > > > > > > > > > G:\>dsacls "\\r2dc1\CN=NTDS > > > > > > > > > > > > Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Conf > > > > igur > > > > > ation,DC=test,DC=loc" > > > > > Access list: > > > > > Effective Permissions on this object are: > > > > > Allow TEST\joe FULL CONTROL > > > > > Allow TEST\Domain Admins SPECIAL ACCESS > > > > > DELETE > > > > > READ > > PERMISSONS > > > > > WRITE > > PERMISSIONS > > > > > CHANGE > > OWNERSHIP > > > > > CREATE CHILD > > > > > LIST CONTENTS > > > > > WRITE SELF > > > > > WRITE PROPERTY > > > > > READ PROPERTY > > > > > DELETE TREE > > > > > LIST OBJECT > > > > > CONTROL ACCESS > > > > > Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS > > > > > READ > > PERMISSONS > > > > > LIST CONTENTS > > > > > READ PROPERTY > > > > > LIST OBJECT > > > > > Allow NT AUTHORITY\SYSTEM FULL CONTROL > > > > > Allow TEST\Domain Admins FULL CONTROL > <Inherited from > > > > > parent> > > > > > Allow TEST\Enterprise Admins FULL CONTROL > <Inherited from > > > > > parent> > > > > > > > > > > Permissions inherited to subobjects are: > > > > > Inherited to all subobjects > > > > > Allow TEST\Domain Admins FULL CONTROL > <Inherited from > > > > > parent> > > > > > Allow TEST\Enterprise Admins FULL CONTROL > <Inherited from > > > > > parent> > > > > > > > > > > Inherited to nTDSConnection > > > > > Allow TEST\joe FULL CONTROL > > > > > The command completed successfully > > > > > > > > > > > > > > > > > > > > So in order to generate a generic FC that is only inherited, you > > > > can't, > > > > > because of bug 1 do it with LDP. If you want to create an ACE > for a > > > > specific > > > > > objectclass (which nTDSConnection should be ok in terms of what > you > > > > are > > > > > trying to delegate) it can do it but you have to go back and > clean up > > > > the > > > > > the additional ACE created by bug 2. > > > > > > > > > > > > > > > I will alert MSFT. > > > > > > > > > > joe > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > O'Reilly Active Directory Third Edition - > > > > > http://www.joeware.net/win/ad3e.htm > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Matheesha > > > > > Weerasinghe > > > > > Sent: Monday, July 24, 2006 8:12 AM > > > > > To: [email protected] > > > > > Subject: [ActiveDir] ldp in ADAM-SP1 > > > > > > > > > > All > > > > > > > > > > Could someone with more experience with ldp provided with > ADAM-SP1 > > > > > tell me how I would go about configuring inherit-only Full > Control > > > > > permissions on nTDSDSA objects in the > > > > > CN=Sites,CN=Configuration,DC=ForestFQDN ? The > > inherit-only perms > > > > > options is grayed out here and I dont know how to do it. > > > > > > > > > > Based on joe's comments I assumed the ldp.exe's ACL editor is > the most > > > > > comprehensive and capable ACL gui editor available. I must be > doing > > > > > something wrong here so I would appreciate some help. > > > > > > > > > > Regards > > > > > > > > > > M@ > > > > > List info : http://www.activedir.org/List.aspx > > > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > > > List archive: > > http://www.activedir.org/ml/threads.aspx > > > > > > > > > > List info : http://www.activedir.org/List.aspx > > > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > > > List archive: > > http://www.activedir.org/ml/threads.aspx > > > > > > > > > List info : http://www.activedir.org/List.aspx > > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > > List archive: http://www.activedir.org/ml/threads.aspx > > > > > > > > List info : http://www.activedir.org/List.aspx > > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > > List archive: http://www.activedir.org/ml/threads.aspx > > > > List info : http://www.activedir.org/List.aspx > > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > > List archive: http://www.activedir.org/ml/threads.aspx > > > > > > > List info : http://www.activedir.org/List.aspx > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > List archive: http://www.activedir.org/ml/threads.aspx > > > > > > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
