RE: [ActiveDir] ldp in ADAM-SP1
Just stepped across this - thanks for fixing it! Ulf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Freitag, 4. August 2006 09:26 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Hi Dmitri, And DSAcls still does not display a computer accounts ACL if someone was being delegated permission to join a computer to this account using ADUC: http://www.windowsserverfaq.org/faq/CompACLs.asp Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811 D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security for multiple child objects at once (and thus these need to be controlled centrally). Many more things to share in this respect, but no delegation model is the same as any other so you're best to understand and plan it from the ground up. There may be similarities between many models, but for the various infrastructures I've planned, every customer has had their special requirements. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 9:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Wow, Thanks you
RE: [ActiveDir] ldp in ADAM-SP1
Hi Dmitri, And DSAcls still does not display a computer accounts ACL if someone was being delegated permission to join a computer to this account using ADUC: http://www.windowsserverfaq.org/faq/CompACLs.asp Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811 D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security for multiple child objects at once (and thus these need to be controlled centrally). Many more things to share in this respect, but no delegation model is the same as any other so you're best to understand and plan it from the ground up. There may be similarities between many models, but for the various infrastructures I've planned, every customer has had their special requirements. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 9:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 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
Re: [ActiveDir] ldp in ADAM-SP1
You and joe are in the same boat :) I understand where the logic for the generalization comes from. My experience and instinct tell me to disagree with the both of you and to interpret the generalization in a different manner. I've worked with and met WAY too many programmers to think that I'd prefer them writing tools vs. a script writer to get the job done. At the end of it all, it really comes down to the right tool for the job. I see no difference between a person writing a script to get something done and somebody writing a tool that the person who otherwise would have written a script would now have to write a batch file to use. Not sure the best written tool would be any better and the person writing the batch wrapper would have even less understanding of the underpinnings of the tasks than they would if they wrote the script. C'est la vie, no? On 7/30/06, Ken Schaefer [EMAIL PROTECTED] wrote: Hi Al, I'm going to have to disagree here. I'd wager that the average programmer has a better understanding of writing code that has: a) proper specifications and design b) robust error handling c) strong typing d) etc Of course, there are always deadlines that result in shoddy code, and there are certainly some shoddy programmers. But the average scripter (in my experience) seems to have far fewer clues on how to write robust, reusable, defensive code than the average programmer. The average scripter doesn't know much about IDEs, debugging, source control, unit tests and all the other goodies that make maintaining large bodies of code easy. There's nothing wrong with writing scripts – especially for things that just require a few lines of code. Trying to maintain something that has 1000+ lines of code is a nightmare when scripted using VBS/JScript Cheers Ken From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent: Sunday, 30 July 2006 10:17 AM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] ldp in ADAM-SP1 I have to say that's weak logic joe. Well, good logic, but weak assumptions. Tool writers are no more likely to prevent unforseen mistakes than a script writer. On the plus side, if you write your own script, you'll have plenty of time to test it and will have gained a great deal more knowledge than you previously had. Mostly about how not to do it, but that's better than figuring that out in production or worse, trusting the tool writer to have done the work for you and to have guessed what you wanted done. joeware tools excepted in most cases of course ;) On 7/29/06, joe [EMAIL PROTECTED] wrote: I am curious about this statement 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. In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
RE: [ActiveDir] ldp in ADAM-SP1
Hi Al, I’m going to have to disagree here. I’d wager that the average programmer has a better understanding of writing code that has: a) proper specifications and design b) robust error handling c) strong typing d) etc Of course, there are always deadlines that result in shoddy code, and there are certainly some shoddy programmers. But the average scripter (in my experience) seems to have far fewer clues on how to write robust, reusable, defensive code than the average programmer. The average scripter doesn’t know much about IDEs, debugging, source control, unit tests and all the other goodies that make maintaining large bodies of code easy. There’s nothing wrong with writing scripts – especially for things that just require a few lines of code. Trying to maintain something that has 1000+ lines of code is a nightmare when scripted using VBS/JScript Cheers Ken From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Sunday, 30 July 2006 10:17 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 I have to say that's weak logic joe. Well, good logic, but weak assumptions. Tool writers are no more likely to prevent unforseen mistakes than a script writer. On the plus side, if you write your own script, you'll have plenty of time to test it and will have gained a great deal more knowledge than you previously had. Mostly about how not to do it, but that's better than figuring that out in production or worse, trusting the tool writer to have done the work for you and to have guessed what you wanted done. joeware tools excepted in most cases of course ;) On 7/29/06, joe [EMAIL PROTECTED] wrote: I am curious about this statement 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. In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
RE: [ActiveDir] ldp in ADAM-SP1
Yeah, extended rights like the one Guido mentions means that Full Control probably shouldn't have been named Not So Full Control as a real Full Control. I wonder if we will see a similar hack to support separation of Exchange attributes? The model is getting to be pretty bad. I vote for a new one. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 2:37 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
Hmm I will probably see this tackled in later notes but after reading this one, the main thing that stuck in my head is don't worry about everything you can do. Work out what you are going to need delegated and then figure out how to do that piece. There were big debates when the delegation doc was being written for instance around how much enterprise admin stuff should truly be delegated? For instance, how many people do you really want creating and manipulating sites and subnets. That can impact so many things at so many levels it probably should be work filtered through a high level group that will have so many high level responsibilities that they should be Enterprise Admins anyway. If I were to delegate any of the subnet/site type stuff it would only be threw some sort of provisioning process that I could assign business rules too for that exact reason. I don't care if the Network group knows all about the subnetting info and they are responsible for it, I wouldn't let them tweak my AD for the subnet info because it impacts at a minimum my replication topology. As we move forward it will impact more as it sounds like Exchange 12 will be using the topology AD has configured for its routing and I have heard more than one argument between SMS admins and AD Admins over topology already. Oh for the record, when it comes down to it, the AD Topology is for managing my replication. If something else can leverage what I have in place, bully for it, but I am not going to design my topology such that the apps benefit and my replication feels pain or even makes it more painful for me to manage and never will application admins get access to sites and subnets in an AD I manage. That is a recipe for AD disaster. 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: Tuesday, July 25, 2006 3:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 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
RE: [ActiveDir] ldp in ADAM-SP1
I am curious about this statement 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. In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Tuesday, July 25, 2006 9:19 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] ldp in ADAM-SP1 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 andappropriately 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 isquite 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 someextent, 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 toolsfor this.You see, I am going to end up as been a very privileged serviceadministrator and data administrator once my proposed AD design model is in place. I expect I will be making some endeavour to trainsufficiently capable people in doing this. But I dont plan to spoonfeed. I want the guys to know to a decent level ACL'ing and if not, dotheir research. At least on an adhoc basis. Then once they understand whats involved, they can go ahead and add/modify/delete ACE's , revokeperms, define new roles etc...Reading this delegation doc has made me believe I can configure anextremely secure delegation model where each role can be given just enough to do that role. The tricky bit is the matching a trusted andappropriately skilled person to the relevant role.So you see, as there is a lot involved and this is a biginfrastructure to attempt to administer perms for 20,000 users plus many OUs used to organise users based on the business unit (at least adozen in each geographical hub) they work in and the site (we havemore than a 40 geographical hubs and 1000 satellite sites) they arelocated 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 notbe big as in Fortune 5 ADs. But its the biggest I've had the privilegeto 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 alittle miffed when I have to swap between several tools to do what Ineed 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 thentry this. If all else fails script "I admit I was ranting a bit when asking why is this named and likesuch 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
RE: [ActiveDir] ldp in ADAM-SP1
It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. Or buy the book in the signature and find out how to step around this limitation... ;) I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). I agree with this and take it a step further. If you are constantly adding new sites or what not that need special ACEs that aren't handled through inheritence from existing structures I highly, no SUPER HIGHLY recommend spending a good amount of time and scripting the creation of those structures and those ACL changes. Yes this means actually have some form of fixed structure. This irks a lot of people but ad hoc OU structures do not work well in large orgs. It is a mess to figure out what is going on when you do that and at someone point, someone always wants to know what is going on. Plus if done that way, it certainly is a lot more efficient to do that work. In the widget company I immediately put together a script to do that stuff and an OU structure that exists for every building in the company that has something like 10 or 12 subous and several groups and lots of special permissions is created in less than a minute correctly each time. By hand, you would be talking 15+ minutes of work and who knows what would be screwed up. Plus... If something happened and all of the ACLs somehow got torched, you can run the script for each of the building OUs and everything is re-ACLed again. I didn't just start doing that on AD, I have done that on NTFS file systems for years because I was often asked as far back as the mid-90's who had access to what and where so I made sure that the permissioning model was shallow and simple. For instance in a project shared folder everyone had access to the top level, and then there was usually 2 groups for every top level folder under that shared folder, one for READ, one for CHANGE. You were in one group or the other and there was no other ACLing below that first folder level. It is much easier to put back together and very simple to work out who has access to what. 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 Grillenmeier, Guido Sent: Tuesday, July 25, 2006 9:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more
RE: [ActiveDir] ldp in ADAM-SP1
Granular ACLing is much preferred to say just giving out account operator or domain admin to people In general though, you need to have a good plan as to what you are giving out and why. As I get older and see more and more deployments I am more and more against native delegation and more and more for provisioning. If MSFT was going to step up and give us business rules so we can define the kind of info that could be set on values then I would not be as against native delegation. The biggest problem I tend to run into anymore is companies who give out FULL CONTROL (or actually NSFC[1]) and then not having a clue what it really means and getting confused why when they add Exchange or some other application that adds attributes or functionality and why some local site admin can read every one of their user's email or other things. This also translates to local site admins overriding centralized application support settings for various things, especially Exchange, think quotas, etc which can be overridden at the user level. Next biggest problem is a huge complicated amount of delegation done to multiple groups such that you run dsacls on an OU or other object and the ACL list scrolls by for 11 screens... This has tremendous impact on your performance and if 2K on the size of the DIT as well. One company I pushed to clean up their ACLs removed quite a few (they had over 100 to start with) and a query I would run that used to take over 90 minutes to run took less than 50 after the cleanup. That is substantial. joe [1] Not So Full Control - I am copyrighting that... -- 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: Tuesday, July 25, 2006 3:18 PM To: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
Or buy the book in the signature and find out how to step around this limitation... ;) well, as I know this workaround I'd comment that it's none of long-term value. At some point you're going to be faced with upgrading your forest to a new Windows Server release and then you won't have the luxury of allowing an older Win2003 DC to exist in your infrastructure (just to mange confidential bits that the updated and newer DCs won't let you set...). Unless ofcourse, you don't want to leverage the new features of the new WinOS... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, July 29, 2006 9:13 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. Or buy the book in the signature and find out how to step around this limitation... ;) I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). I agree with this and take it a step further. If you are constantly adding new sites or what not that need special ACEs that aren't handled through inheritence from existing structures I highly, no SUPER HIGHLY recommend spending a good amount of time and scripting the creation of those structures and those ACL changes. Yes this means actually have some form of fixed structure. This irks a lot of people but ad hoc OU structures do not work well in large orgs. It is a mess to figure out what is going on when you do that and at someone point, someone always wants to know what is going on. Plus if done that way, it certainly is a lot more efficient to do that work. In the widget company I immediately put together a script to do that stuff and an OU structure that exists for every building in the company that has something like 10 or 12 subous and several groups and lots of special permissions is created in less than a minute correctly each time. By hand, you would be talking 15+ minutes of work and who knows what would be screwed up. Plus... If something happened and all of the ACLs somehow got torched, you can run the script for each of the building OUs and everything is re-ACLed again. I didn't just start doing that on AD, I have done that on NTFS file systems for years because I was often asked as far back as the mid-90's who had access to what and where so I made sure that the permissioning model was shallow and simple. For instance in a project shared folder everyone had access to the top level, and then there was usually 2 groups for every top level folder under that shared folder, one for READ, one for CHANGE. You were in one group or the other and there was no other ACLing below that first folder level. It is much easier to put back together and very simple to work out who has access to what. 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 Grillenmeier, Guido Sent: Tuesday, July 25, 2006 9:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been
RE: [ActiveDir] ldp in ADAM-SP1
To explain what Guido is saying. So buy the book now!!! Don't wait until it is too late to help you out!!! Thanks Guido, nice angle, I hadn't thought of that one... For retirement money I would consider specifying some other ways it can be done that will work on later OSes... :o) It has to be enough retirement money to buy an island or something though, because if I keep talking, ~Eric will probably try to come find and kill me. Not because he told me how to do any of it, but because he is very clear on the fact that setting cat-1 attributes to confidential is a strictly untested condition as I am quite clear on that point in the book as well. :) Personally, I think everything around confidential bits is a bad idea. 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 Grillenmeier, Guido Sent: Saturday, July 29, 2006 4:22 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Or buy the book in the signature and find out how to step around this limitation... ;) well, as I know this workaround I'd comment that it's none of long-term value. At some point you're going to be faced with upgrading your forest to a new Windows Server release and then you won't have the luxury of allowing an older Win2003 DC to exist in your infrastructure (just to mange confidential bits that the updated and newer DCs won't let you set...). Unless ofcourse, you don't want to leverage the new features of the new WinOS... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, July 29, 2006 9:13 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. Or buy the book in the signature and find out how to step around this limitation... ;) I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). I agree with this and take it a step further. If you are constantly adding new sites or what not that need special ACEs that aren't handled through inheritence from existing structures I highly, no SUPER HIGHLY recommend spending a good amount of time and scripting the creation of those structures and those ACL changes. Yes this means actually have some form of fixed structure. This irks a lot of people but ad hoc OU structures do not work well in large orgs. It is a mess to figure out what is going on when you do that and at someone point, someone always wants to know what is going on. Plus if done that way, it certainly is a lot more efficient to do that work. In the widget company I immediately put together a script to do that stuff and an OU structure that exists for every building in the company that has something like 10 or 12 subous and several groups and lots of special permissions is created in less than a minute correctly each time. By hand, you would be talking 15+ minutes of work and who knows what would be screwed up. Plus... If something happened and all of the ACLs somehow got torched, you can run the script for each of the building OUs and everything is re-ACLed again. I didn't just start doing that on AD, I have done that on NTFS file systems for years because I was often asked as far back as the mid-90's who had access to what and where so I made sure that the permissioning model was shallow and simple. For instance in a project shared folder everyone had access to the top level, and then there was usually 2 groups for every top level folder under that shared folder, one for READ, one for CHANGE. You were in one group or the other and there was no other ACLing below that first folder level. It is much easier to put back together and very simple to work out who has access to what. 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 Grillenmeier, Guido Sent: Tuesday, July 25, 2006 9:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually
RE: [ActiveDir] ldp in ADAM-SP1
Dmitri, first of all, I should have added to this thread that there are actually already a couple of nice changes in DSACLS in Longhorn, which I am glad do exist: - it can now be used to set Control Access rights on attributes (for example with confidential attributes) - it allows to use SIDs and FQDNs to set/remove ACLs (SID is a major benefit) - it supports setting the new OWNER RIGHTS permissions (which can't be set via the UI right now) However, the thing I think is still extremely annoying is that you can't remove single permissions - you always have to remove ALL permissions for a specific security principal (on the object that you're processing). This makes it extremely difficult to automate removal of permissions, as I first need to check all the permissions that an sec prin has, then remove the one permission that I'd like to remove and at least re-apply all the permissions that I didn't want to remove. Quite a pain - would be great to fix this. At last, it would be nice to combine the feature of DSACLS with that of DSREVOKE. The latter is useful to report on ACLs for a single sec prins in a whole tree (and to remove them) - however, it is incapable of doing so for well-known-security-principals such as Authenticated Users or built-in ones such as Administrators. Would be lovely to see these changes in B3 ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security
RE: [ActiveDir] ldp in ADAM-SP1
Thanks Guido, Nice requests, but not small. So, no promises for LH, it is getting late. I'll get these filed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Friday, July 28, 2006 1:06 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Dmitri, first of all, I should have added to this thread that there are actually already a couple of nice changes in DSACLS in Longhorn, which I am glad do exist: - it can now be used to set Control Access rights on attributes (for example with confidential attributes) - it allows to use SIDs and FQDNs to set/remove ACLs (SID is a major benefit) - it supports setting the new OWNER RIGHTS permissions (which can't be set via the UI right now) However, the thing I think is still extremely annoying is that you can't remove single permissions - you always have to remove ALL permissions for a specific security principal (on the object that you're processing). This makes it extremely difficult to automate removal of permissions, as I first need to check all the permissions that an sec prin has, then remove the one permission that I'd like to remove and at least re-apply all the permissions that I didn't want to remove. Quite a pain - would be great to fix this. At last, it would be nice to combine the feature of DSACLS with that of DSREVOKE. The latter is useful to report on ACLs for a single sec prins in a whole tree (and to remove them) - however, it is incapable of doing so for well-known-security-principals such as Authenticated Users or built-in ones such as Administrators. Would be lovely to see these changes in B3 ;-) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitri Gavrilov Sent: Thursday, July 27, 2006 7:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like
RE: [ActiveDir] ldp in ADAM-SP1
Guido, which changes to you want to see in dsacls in B3? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, July 25, 2006 6:22 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security for multiple child objects at once (and thus these need to be controlled centrally). Many more things to share in this respect, but no delegation model is the same as any other so you're best to understand and plan it from the ground up. There may be similarities between many models, but for the various infrastructures I've planned, every customer has had their special requirements. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 9:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 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
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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
Re: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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
Re: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you should need to do. You've already tripped over some of it's limitations especially around handling the confidential bit - however, I have not seen many customers that actually leverage the confidential bit yet for anything else but OS features (for example for PKI credential roaming). It would be nice to leverage it for many more lockdown scenarios, but you can't use it for the base schema attributes (category 1), which includes almost all of the interesting attributes you may want to restrict access to. Ofcourse you can use it for your own schema extensions. For file-system ACLing that tool is CALS or XCACLS - probably for 99% of what you need to do. Note for the FS you may also want to check out the betas of either Windows Longhorn or the current Windows 2003 SP2 = they include a new commandline ACLing tool called Icacls.exe, which can be used to reset the account control lists (ACL) on files from Recovery Console, and to back up ACLs. It can also handle replacement of ACLs (much like subinacl) and works well with either names or SIDs. At last, unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and thus correctly propagates changes to and creation of inherited ACLs. DSACLs has only been updated slightly in LH, but I hope to see some more changes prior to beta 3. At last, depending on your requirements, you may also need to look into changing the default security descriptor of some of the objects (for example, check out all the default write permissions, which every user is granted on it's own object via the SELF security principal; many companies are still unaware of this). You can check these rights most easily via the schema mgmt mmc (check properties of a class object, such as user and click on the Default Security tab). So it's fair to say that although handling ACLs remains to be a complex topic, you can get most of the things done with existing commandline tools from MSFT. Sometimes it will simply be more appropriate to use the UI for a few settings. And there is always the option to script setting ACLs if you really have special requirements. As for your delegation model = I would not have the goal to teach your delegated admins how to do ACLing inside AD. I'm fine with a delegated admin doing the security on a file-server that he completely manages on his own. But AD security should be kept in the hand of domain and enterprise admins (partly because it is rather complex and you only want few folks to fiddle around with it, partly because it is plain risky to do it otherwise). The critical piece for most delegation models to succeed is to build a centrally controlled OU structure (ideally standardized for your different delegated admin units as I like to call them and not to grant your data admin (= the delegated admins) any rights to create OUs themselves (otherwise - with the current ACLing model - you can't prevent them to configure the security of the OU). Basically the same is true for any objects they create, but it's the OUs that allow you to manage the security for multiple child objects at once (and thus these need to be controlled centrally). Many more things to share in this respect, but no delegation model is the same as any other so you're best to understand and plan it from the ground up. There may be similarities between many models, but for the various infrastructures I've planned, every customer has had their special requirements. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, July 25, 2006 9:34 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 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
Re: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] ldp in ADAM-SP1
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=Configur ation,DC=test,DC=loc Access list: Effective Permissions on this object are: Allow TEST\joe FULL CONTROL Allow TEST\Domain AdminsSPECIAL 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 AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL CONTROL Inherited from parent Permissions inherited to subobjects are: Inherited to all subobjects Allow TEST\Domain AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL 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: ActiveDir@mail.activedir.org 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
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=Configur ation,DC=test,DC=loc Access list: Effective Permissions on this object are: Allow TEST\joe FULL CONTROL Allow TEST\Domain AdminsSPECIAL 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 AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL CONTROL Inherited from parent Permissions inherited to subobjects are: Inherited to all subobjects Allow TEST\Domain AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL 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: ActiveDir@mail.activedir.org 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:
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: ActiveDir@mail.activedir.org 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
Re: [ActiveDir] ldp in ADAM-SP1
Joe joe I see you were configuring Full Control (GA) for nTDSConnection objects by configuring perms on the parent nTDSDSA object. I was trying to actually configure full control to the nTDSDSA using perms on the CN=Sites object but the principal is the same I guess. The only thing is nTDSConnection objects cant have child objects can they? Still I am having some issues repro'ing. You said your workaround was to configure on the object types. Did you mean to configure explicitly on the object or on the parent with the child's object type specified in the ACE? I cant repro here and I am not sure whether you used dsacls or ldp to repro. And why does it not choose the Access System Security option when you edit a Full Control ACE? Is that expected? I thought full control meant everything. Not everything but Access System Security. Also how come there is no string defined for Access System Security? There is for all other access masks. I freely admit I know very little in this arena. Any lesson offered is most appreciated. I am already reading technet and many books by the fine guys on here. I just havent finished them yet ;-) Thanks to everyone who's read this so far and for all the help I am offered. I truly appreciate it. Sincerely M@ 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=Configur ation,DC=test,DC=loc Access list: Effective Permissions on this object are: Allow TEST\joe FULL CONTROL Allow TEST\Domain AdminsSPECIAL 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 AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL CONTROL Inherited from parent Permissions inherited to subobjects are: Inherited to all subobjects Allow TEST\Domain AdminsFULL CONTROL Inherited from parent Allow TEST\Enterprise AdminsFULL 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: ActiveDir@mail.activedir.org 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:
RE: [ActiveDir] ldp in ADAM-SP1
Yeah what I was doing was setting a FC ACE for connection objects only. If you want to cover multiple objects for this you would need to specify multiple objectclasses which would result in multiple ACEs which is not a good option. Which means, use a different tool as the bugs in the current version of LDP make that difficult for this specific task. In my tests, I was specifically using LDP from ADAM SP1. But for what you want to do, use ADUC or DSACLS. As an aside, I emailed Matheesha directly a little while ago when my first email was lost in limbo waiting to be sent out by the list. A version of LDP that doesn't have this issue should be in Longhorn when it is released. The developer quickly fixed the first bug I mentioned this morning after I pinged him and it seems the second bug had already been corrected. This folks is the power of this list Take note. I am not entirely positive what the Access system security is supposed to be... This is not an issue in later versions of LDP... I would say read the chapters on security in the AD book, then if you don't have it, get and read Sakari's book as that has a great chapter on AD security and then finally if you still want to learn more, wander into the MSDN library and start reading about Security Descriptors, Access Control Lists, and Access Control Entries. Once you understand the structures and how they are represented a lot of the security stuff starts making more and more sense. 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 2:03 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Joe joe I see you were configuring Full Control (GA) for nTDSConnection objects by configuring perms on the parent nTDSDSA object. I was trying to actually configure full control to the nTDSDSA using perms on the CN=Sites object but the principal is the same I guess. The only thing is nTDSConnection objects cant have child objects can they? Still I am having some issues repro'ing. You said your workaround was to configure on the object types. Did you mean to configure explicitly on the object or on the parent with the child's object type specified in the ACE? I cant repro here and I am not sure whether you used dsacls or ldp to repro. And why does it not choose the Access System Security option when you edit a Full Control ACE? Is that expected? I thought full control meant everything. Not everything but Access System Security. Also how come there is no string defined for Access System Security? There is for all other access masks. I freely admit I know very little in this arena. Any lesson offered is most appreciated. I am already reading technet and many books by the fine guys on here. I just havent finished them yet ;-) Thanks to everyone who's read this so far and for all the help I am offered. I truly appreciate it. Sincerely M@ 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=Configur ation,DC=test,DC=loc Access list: Effective Permissions on this object are: Allow TEST\joe FULL CONTROL Allow TEST\Domain AdminsSPECIAL 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
RE: [ActiveDir] ldp in ADAM-SP1
Re Access System Security checkbox. We removed it from the latest versions of ldp.exe because it does not do what you want. Even if you grant this right to some principal, he will still be unable to read or tweak the SACLs. The only way to be able to do this is to grant SE_ACCESS_SYSTEM_SECURITY privilege. You do this from gpedit.msc (security settings/User rights assignments). On a more general note -- yes, AD security is a mess to manage and to understand. We are trying to improve it, but it is super super difficult task. Not only the rules are difficult to understand and are numerous, but also we need to respect the existing security setups which use weird ACLs. There were several attempts to improve things, but I don't believe we are getting closer, mostly due to backward compatibility issues, as well as due to the need to introduce new rules (such as confidentiality bit and many new control access rights). BTW, the Delegation Wizard is considered to be the entry-level ACLing tool. Alas, it does not work for ADAM. Dmitri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, July 24, 2006 1:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ldp in ADAM-SP1 Yeah what I was doing was setting a FC ACE for connection objects only. If you want to cover multiple objects for this you would need to specify multiple objectclasses which would result in multiple ACEs which is not a good option. Which means, use a different tool as the bugs in the current version of LDP make that difficult for this specific task. In my tests, I was specifically using LDP from ADAM SP1. But for what you want to do, use ADUC or DSACLS. As an aside, I emailed Matheesha directly a little while ago when my first email was lost in limbo waiting to be sent out by the list. A version of LDP that doesn't have this issue should be in Longhorn when it is released. The developer quickly fixed the first bug I mentioned this morning after I pinged him and it seems the second bug had already been corrected. This folks is the power of this list Take note. I am not entirely positive what the Access system security is supposed to be... This is not an issue in later versions of LDP... I would say read the chapters on security in the AD book, then if you don't have it, get and read Sakari's book as that has a great chapter on AD security and then finally if you still want to learn more, wander into the MSDN library and start reading about Security Descriptors, Access Control Lists, and Access Control Entries. Once you understand the structures and how they are represented a lot of the security stuff starts making more and more sense. 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 2:03 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] ldp in ADAM-SP1 Joe joe I see you were configuring Full Control (GA) for nTDSConnection objects by configuring perms on the parent nTDSDSA object. I was trying to actually configure full control to the nTDSDSA using perms on the CN=Sites object but the principal is the same I guess. The only thing is nTDSConnection objects cant have child objects can they? Still I am having some issues repro'ing. You said your workaround was to configure on the object types. Did you mean to configure explicitly on the object or on the parent with the child's object type specified in the ACE? I cant repro here and I am not sure whether you used dsacls or ldp to repro. And why does it not choose the Access System Security option when you edit a Full Control ACE? Is that expected? I thought full control meant everything. Not everything but Access System Security. Also how come there is no string defined for Access System Security? There is for all other access masks. I freely admit I know very little in this arena. Any lesson offered is most appreciated. I am already reading technet and many books by the fine guys on here. I just havent finished them yet ;-) Thanks to everyone who's read this so far and for all the help I am offered. I truly appreciate it. Sincerely M@ 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
RE: [ActiveDir] ldp in ADAM-SP1
completely different mechanism was followed but using the same basic SDDL/SD stuff. Of course here I am referring to the CUSTOMSD stuff they put in for K3 Event Log permissioning. The first time I saw that I was like, was someone on crack??? They had a perfectly fine set of constants and flag values and these gomers invented something completely different Why was it done? Probably because either someone didn't understand how it was already handled or someone thought it was too complex and was going to make it easier and simply added complexity once they looked outside their little area. My overriding recommendation to everyone and anyone who ever plays with ACLs is to use the NORMAL GUI to assign what you want assigned and then look at the RAW ACL and look at what really happened and ascertain if it made sense. There are lots of times where the GUI will not produce the most efficient ACL butit is a great start. Once you have looked at enough ACLs you start to get a feel for what is and isn't needed and inefficiencies will start sticking out to you as you build up the rule set in your own mind and just start using it subconsciously. I still dump ACLs and look at the raw valueson a regular basis to figure out how things work and if I need to automate the adding of an ACE to something. The script I created for AD3E in the security chapter which dumps a security ACL should give you great info for scripting the modification/creation of ACLs because it specifically dumps out the values for each field that end up getting set. I love using DSACLS for looking at ACLs as well because it is easier for more people to use than say my script and still produces very useful output. I pretty much refuse to look at ACLs from the GUI anymore simply because it is not the best way to look at it because you have to go in and look at each item individually instead of looking at it all in one fell swoop.That is the fault of the GUIs but I don't blame them much because there is a lot of info and I can't visualize myself how to do it better at the moment. I guess a lot of this was to say beating on the ACLing model is too easy of a fight. It is like going up to a horse and beating it and saying you are brown, I am going to beat you. Everyone can see the horse is brown and everyone would like to be able to fix that (well maybe, I might like a brown horse, don't take analogies too far is the lesson here...) but some things just aren't that easy to change no matter how much you want to or how much of a pain it all is. So don't give up, don't go insane, just keep working through it and do it in baby steps. Get a goal and work towards it, the goal cannot be, understand all about ACLs because it is too big. Start smaller. Also state here your actual goal you have for configuring your ACLs in your sites area sosomeone can say whoa, that itsn't a very good idea or tell you how to pull it off. If you know the perfect way all of this could be handled, do feel free to write the perfect script or tool to do it. Lots of people would certainly like to have it but it may not sell well. Everyone wants the perfect tool but they also want it to be free. :) joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Monday, July 24, 2006 9:27 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] ldp in ADAM-SP1 I think you can infer from the posts by Dmitri and joe that this is more complex than you'd like to hear. That said, it might be more productive if you post what you want to accomplish and see if somebody can help you determine/navigate the way forward. A QFE for Longhorn? You're making the assumption that the fix is backported. It may not be. I think that would be the first question to ask before asking to get a copy. Al On 7/24/06, Matheesha Weerasinghe [EMAIL PROTECTED] wrote: There is much in ldp I dont know. Everything I do know, I learned fromJohn Craddock's book and the understanding ldap whitepaper from MSFT. Thanks for all the help so far joe and Dmitri . If I wanted to get myTAM to get the updated version of ldp as it stands, what QFE numbershould I quote?The more I look into this the more insane I get ;-) Why is the Extended Right is defined with the string "SW" in the sddl format butdsacls uses "WS". Different access masks have different namesdepending on what I read."Read permissions" in ldp is "Read Control" in the docs. "Extended write" in ldp is "Write to self" in dsacls. Atleast thats how I understood it.I may have to make my own notes on this. If I ever have to read thisstuff and the delegation docs I am definitely going to go nuts. Would it be fare to say we can do all we need definitely usingscripts? Or is that also not definite?
