Al is correct. There is no QFE number at this
point.
The first step would be to present a solid business case
and then Microsoft would officially review it and determine if a QFE which would
mean an official pback port makes sense. A QFE is an official release and takes
some work to get done so there has to be good justification behind it. The more
I think about this, the tougher I think it would be to get a QFE for
LDP. But again if you have the business case, it might get
through.
So is this a case of simply wanting it or this is the only
way? From what I have heard it doesn't sound like this is the only way to go
forward but I am not sure if I know everything required.
What I see right now is
>
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?
> 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?
which doesn't really tell me what you are trying to do. Are
you trying to delegate the ability to manipulate connection objects or
ntdsdsa objects or what? If you are trying to just delegate those two pieces and
trying to do it from the sites level on down, you will have to use at a minimum
two ACEs, one for ntdsdsa objects and one for connection objects. Alternately
you will have to add an ACE at the ntdsdsa object level under every server and
every site.
Again, all of the ACL tools have different shortcomings,
there is no one tool that handles everything perfectly from MSFT at this point
in time and even LDP which is one of the more flexible tools after the mentioned
bug fixes is still going to fall short in people's eyes because the interface is
too low level for some people. This is where the next pieces comes into it on
terms and names comes in.
RE: terms and names and etc, yes, it is all over the map.
Asking questions of WHY is this named that and the same thing named something
else in another tool are going to feel good to ask but aren't likely to be
answered because it isn't constructive to answer those questions. Yes security
is tricky and messy and everyone understands that and attempts are being made to
make it better, but as Dmitri indicated and I indicated, it isn't easy. There
are a lot of special cases to take into account and trying to force one good
easy solution at this point has potential to break a lot of things which will
just instigate more WHY questions. Even from the start the flexibility built
into the ACLing model made it complex, it has only gotten more so as people
demanded more granularity and capability. I can say the same things about my
tools and they are ultra simple next to something like the permissioning model.
But as I or others pushed for more features and capability and I actually added
it complexity increased considerably to the point where I am at some point going
to release a whole new version of the tools based on a whole new code base or
framework. This is "easy" for me to do relative to Microsoft as my support base
is not even a rounding error to the MSFT support base and it still will be quite
hard.
So why is it SW in SDDL and WS in DSACLS? Answer:
because that is the way it is. :)
Read permissions could be stated as Read Permissions or
Read Properties or Read Control or just Read or circumflexuremititis whatever.
Why? See above.
The actual reason behind "because" could be lots of things
- it depends. You would need to talk to the developers of each component. I
expect it wasn't a mass conspiracy to confuse anyone. More likely it is actually
dev people trying to help others with maybe more descriptive terms or possibly
they didn't fully understand the thing themselves in the first place. As Dmitri
mentioned with the "Access system security", they put it in and found out later
things just didn't work the way they expected. Heck if they had asked me I could
have told them it doesn't work that way, it could break the security model
if it did. However I wasn't asked. On the contrary though, there are probably a
ton of other things I would have done wrong that I wasn't aware of because I
didn't have a chance to experience them. I got a chance to read something from
Guido recently on some ACL stuff and it completely stunned me and made me bang
my head on the desk for a little bit. It is a complex complex product and
complex complex security model. Though to be blunt, I don't think I have seen a
simple but flexible and granular security model yet that lends itself both to
easy programming and easy user comprehension.
At this point you have it easy, you are only looking at AD
permissions. Once you step out from that tiny little aspect of where this ACLing
is used you start to see all sorts of fun stuff where different bits mean
different things in ACLs for different objects and in some cases another
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 but it 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 values on 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 so someone 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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Monday, July 24, 2006 9:27 PM
To: [email protected]
Subject: 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 from
John 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 my
TAM to get the updated version of ldp as it stands, what QFE number
should 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 but
dsacls uses "WS". Different access masks have different names
depending on what I read. "Read permissions" in ldp is "Read Control"
in the docs. "Extended write" in ldp is "Write to self" in dsacls. At
least thats how I understood it.
I may have to make my own notes on this. If I ever have to read this
stuff and the delegation docs I am definitely going to go nuts.
Would it be fare to say we can do all we need definitely using
scripts? Or is that also not definite? You see, until recently I was
reading this delegation doc with a grin from ear-to-ear thinking yeah!
And now I am not so ....
Before I break down and cry like Homer, I'm gonna go get some Zzzzzzzzzzzzzz!
Cheers
M@
On 7/24/06, Dmitri Gavrilov <[EMAIL PROTECTED] > wrote:
> 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: [email protected]
> 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: [email protected]
> 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=Conf
> igur
> > ation,DC=test,DC=loc"
> > Access list:
> > Effective Permissions on this object are:
> > Allow TEST\joe FULL CONTROL
> > Allow TEST\Domain Admins SPECIAL ACCESS
> > DELETE
> > READ PERMISSONS
> > WRITE PERMISSIONS
> > CHANGE OWNERSHIP
> > CREATE CHILD
> > LIST CONTENTS
> > WRITE SELF
> > WRITE PROPERTY
> > READ PROPERTY
> > DELETE TREE
> > LIST OBJECT
> > CONTROL ACCESS Allow NT
> > AUTHORITY\Authenticated Users SPECIAL ACCESS
> > READ PERMISSONS
> > LIST CONTENTS
> > READ PROPERTY
> > LIST OBJECT
> > Allow NT AUTHORITY\SYSTEM FULL CONTROL
> > Allow TEST\Domain Admins FULL CONTROL <Inherited from
> > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL <Inherited from
> > parent>
> >
> > Permissions inherited to subobjects are:
> > Inherited to all subobjects
> > Allow TEST\Domain Admins FULL CONTROL <Inherited from
> > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL <Inherited from
> > parent>
> >
> > Inherited to nTDSConnection
> > Allow TEST\joe FULL CONTROL
> > The command completed successfully
> >
> >
> >
> > So in order to generate a generic FC that is only inherited, you
> > can't, because of bug 1 do it with LDP. If you want to create an ACE
> > for a
> specific
> > objectclass (which nTDSConnection should be ok in terms of what you
> > are trying to delegate) it can do it but you have to go back and clean
>
> > up the the additional ACE created by bug 2.
> >
> >
> > I will alert MSFT.
> >
> > joe
> >
> >
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Matheesha
> > Weerasinghe
> > Sent: Monday, July 24, 2006 8:12 AM
> > To: [email protected]
> > Subject: [ActiveDir] ldp in ADAM-SP1
> >
> > All
> >
> > Could someone with more experience with ldp provided with ADAM-SP1
> > tell me how I would go about configuring inherit-only Full Control
> > permissions on nTDSDSA objects in the
> > CN=Sites,CN=Configuration,DC=ForestFQDN ? The inherit-only perms
> > options is grayed out here and I dont know how to do it.
> >
> > Based on joe's comments I assumed the ldp.exe's ACL editor is the most
>
> > comprehensive and capable ACL gui editor available. I must be doing
> > something wrong here so I would appreciate some help.
> >
> > Regards
> >
> > M@
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ml/threads.aspx
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ml/threads.aspx
> >
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
