Re: Win2k - Account Operator not working properly

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Ok, I was keeping up with you, but your last post sent me into the deep end
of the pool, without my water-wings.......
1) Not sure what point you are trying to make with the sentence beginning
with:
"...When talking
about inherited ACLs the object the inheritence applies to is not listed in
the
actual ACE listing. It is broken up into multiple sections in the inherited
ACL
listing. For an example of the inherited piece

Allow DOMAIN\testacct FULL CONTROL <Inherited from parent>
That entry tells me nothing. I have no clue what testacct has full control of.
....."
I don't know if you are saying you need more information from the DSACLS
dump, or if this is just a limitation of the output of that file. In my
previous post, I stated that the output I provided was from one of the
sub-level OUs...This may just be a communication/interpretation issue, that
would be remedied by speaking with you directly, but at any rate, I am just
not following where you are going with this point and unfortunately I will
not be able to post all of the contents of the DSACLS dump to this public
newsgroup....

2) Scripting through what means? Are you recommending the use of DSACLS for
this, as opposed to GUI?

3) Sorry, let me clarify my previous statement....in this environment users
are created with the ADUC. A default user template has been created using the
ADUC, and is copied to create subsequent new users in their respective
OUs...I dont suspect any schema mods, just someone not checking the right box
when they built the user template......
Thanks again for your patience, time and efforts.....

> 1. All of the ACEs are applicable. One set of ACEs could be taking away
> permission granted in another set at the same level or otherwise explain
> behavior to one person that another person doesn't understand. Also ACEs at a
> lower level could take away permissions granted at a higher level. When talking
> about inherited ACLs the object the inheritence applies to is not listed in the
> actual ACE listing. It is broken up into multiple sections in the inherited ACL
> listing. For an example of the inherited piece
>
> >>>>Allow DOMAIN\testacct FULL CONTROL <Inherited from parent>
>
> That entry tells me nothing. I have no clue what testacct has full control of.
>
> 2. You would either need to script the cleanup or you would have to remove all
> permission for the group and reapply again. It is unusual to do that from the GUI.
>
> 3. I am not sure what you mean by the user template. That could mean multiple
> things as people follow different processes for creating user objects. If using
> the standard ADUC, it would require someone modifying the schema to cause the
> ACL to be dorked on a new object create. You would either have to change the
> defaultSD or change the definition of nTSecurityDescriptor to tell ADUC to copy it.
>
>
>
>
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> thawkz wrote:
> > 1) what other info in ACL dump is applicable?
> > 2) how do I get rid of the duplicate ACEs?
> > 3) after googling.....i do not believe that adminsdholder is related to this
> > issue. More research has shown that a template is being used to create user
> > accounts in OUs--the user template does not have the "Allow inheritance...."
> > box checked. That explains the propagation/inheritance thing...ahh the joys
> > of an inherited Active Directory......
> >
> > "Joe Richards [MVP]" wrote:
> >
> >
> >>If permissions are on OUs but not making it to users it means that inheritence
> >>is off on the user objects, this usually means adminsdholder is in play. Do a
> >>google on that term as I mentioned before.
> >>
> >>As for the permission dump, just showing the ACEs doesn't help as there is other
> >>info in the ACL dump that is applicable. All I can tell you is that you have
> >>some duplicate ACEs on your ACL now and they need to be cleaed up. You will note
> >>the duplicated ACEs.
> >>
> >>
> >>
> >>--
> >>Joe Richards Microsoft MVP Windows Server Directory Services
> >>www.joeware.net
> >>
> >>
> >>thawkz wrote:
> >>
> >>>Further analysis/observation......Checked security on the User-Level objects
> >>>in the OUs and verified that security settings are not being propagated from
> >>>the OU level to the user object level.......this explains why some user
> >>>objects can be modified/passwords reset, etc. and some user objects (within
> >>>the same OU) cannot........how can this be fixed? DSACLS can be used for that
> >>>as well I presume....any other ideas, other than DSACLS?
> >>>...continued thanks......
> >>>
> >>>"thawkz" wrote:
> >>>
> >>>
> >>>
> >>>>Ok....here is current status:
> >>>>1) Created a brand new user.
> >>>>2) Verified new user has no special group memberships (only default
> >>>>membership of domain users)
> >>>>3) Used the delegation wizard, on the top level OU, to assign the desired
> >>>>permissions.
> >>>>4) Verified that the new user account can create/delete objects at this OU
> >>>>level and OUs below it........
> >>>>5) Verified that the new user account can modify objects at the top level OU
> >>>>6) Verified that the new user account CANNOT edit previously existing
> >>>>objects (reset passwords, modify account properties, etc.).
> >>>>7) Ran DSACLS on the top level OU and received the following output (only
> >>>>providing relevant parts of the dump--also changed domain name for privacy
> >>>>purposes):
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS
> >>>> READ PERMISSONS
> >>>> LIST CONTENTS
> >>>> WRITE PROPERTY
> >>>> READ PROPERTY
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS for user
> >>>> CREATE CHILD
> >>>> DELETE CHILD
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS
> >>>> READ PERMISSONS
> >>>> LIST CONTENTS
> >>>> WRITE PROPERTY
> >>>> READ PROPERTY
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS for user
> >>>> CREATE CHILD
> >>>> DELETE CHILD
> >>>>
> >>>>Allow DOMAIN\testacct FULL CONTROL
> >>>>
> >>>>8) Ran DSACLS for a sub-level OU (3 levels down from top OU) and received
> >>>>the following output (only providing relevant parts of the dump--also changed
> >>>>domain name for privacy purposes):
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS <Inherited from parent>
> >>>> READ PERMISSONS
> >>>> LIST CONTENTS
> >>>> WRITE PROPERTY
> >>>> READ PROPERTY
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS for user <Inherited from
> >>>>parent>
> >>>> CREATE CHILD
> >>>> DELETE CHILD
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS <Inherited from parent>
> >>>> READ PERMISSONS
> >>>> LIST CONTENTS
> >>>> WRITE PROPERTY
> >>>> READ PROPERTY
> >>>>
> >>>>Allow DOMAIN\testacct SPECIAL ACCESS for user <Inherited from
> >>>>parent>
> >>>> CREATE CHILD
> >>>> DELETE CHILD
> >>>>
> >>>>Allow DOMAIN\testacct FULL CONTROL <Inherited from parent>
> >>>>
> >>>>Allow DOMAIN\testacct Reset Password
> >>>>
> >>>>Based on this output, are there some required permissions missing?
> >>>>Thanks......
> >>>>
> >>>>
> >>>>"Joe Richards [MVP]" wrote:
> >>>>
> >>>>
> >>>>
> >>>>>The tool is a command line tool from Microsoft to enumerate the permissions on
> >>>>>an object. It is much better than using the GUI because the GUI won't always
> >>>>>display what is actually there. Also I wrote a vbscript for the refresh work I
> >>>>>did on O'Reilly Active Directory Third Edition that does similar work but gives
> >>>>>even more info on the security descriptors.
> >>>>>
> >>>>>DSACLS can both read and set permissions. It is part of the support tools
> >>>>>offering. The latest version of DSACLS can be gotten from K3 SP1 or the ADAM
> >>>>>install from the R2 Beta.
> >>>>>
> >>>>>
> >>>>>
> >>>>>--
> >>>>>Joe Richards Microsoft MVP Windows Server Directory Services
> >>>>>www.joeware.net
> >>>>>
> >>>>>
> >>>>>thawkz wrote:
> >>>>>
> >>>>>
> >>>>>>I am not familiar with DSACLS dump.....what will that do for us? I suspect by
> >>>>>>the name of the process, it will show the ACL list for a given object....just
> >>>>>>curious, if after using the utility, there appear to be problems with the
> >>>>>>permissions being applied to the object, how can it be corrected? Does DSACLS
> >>>>>>have the ability to fix problems as well as identify them?
> >>>>>>
> >>>>>>Thanks.
> >>>>>>
> >>>>>>"Joe Richards [MVP]" wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Post a DSACLS dump of an OU of concern and what isn't happening in that OU that
> >>>>>>>you expect should happen.
> >>>>>>>
> >>>>>>>--
> >>>>>>>Joe Richards Microsoft MVP Windows Server Directory Services
> >>>>>>>www.joeware.net
> >>>>>>>
> >>>>>>>
> >>>>>>>thawkz wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>....let me also add some details to my most recent post--we have multi-level
> >>>>>>>>OUs....
> >>>>>>>>I delegated control to Helpdesk group in the top level OU.....So, currently:
> >>>>>>>>Helpdesk CAN modify/reset/create/delete accounts in the top-level OU.
> >>>>>>>>Helpdesk CAN create new accounts/modify/delete/reset passwords for NEW
> >>>>>>>>accounts in OUs beneath the top-level OU.
> >>>>>>>>Helpdesk CANNOT modify/reset existing accounts in the OUs beneath the
> >>>>>>>>top-level OU.
> >>>>>>>>Please feedback comments/questions......thanks for your help.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>"thawkz" wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Good enough.....One followup question......I used the delegate control wizard
> >>>>>>>>>to grant the required permissions for the HelpDesk group. The members of the
> >>>>>>>>>group can now create/delete/modify NEW user accounts and reset passwords for
> >>>>>>>>>these accounts, but cannot create/delete/modify/reset passwords for any
> >>>>>>>>>accounts that existed PRIOR to my running the delegate control wizard.....any
> >>>>>>>>>ideas on a cause and a fix?
> >>>>>>>>>Thanks.
> >>>>>>>>>
> >>>>>>>>>"Joe Richards [MVP]" wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>You shouldn't use acc ops because there are side effects that tend to mess
> >>>>>>>>>>people up (see adminsdholder functionality) plus it was put there simply as a
> >>>>>>>>>>holdover from NT.
> >>>>>>>>>>
> >>>>>>>>>>The proper way to handle this is to create one or more groups and delegate the
> >>>>>>>>>>permissions needed to those groups and add admins to the groups as needed.
> >>>>>>>>>>
> >>>>>>>>>>--
> >>>>>>>>>>Joe Richards Microsoft MVP Windows Server Directory Services
> >>>>>>>>>>www.joeware.net
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>thawkz wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Running (an inherited) Windows 2000 Active Directory.
> >>>>>>>>>>>Helpdesk staff needed permissions to manage user account/reset passwds, etc.
> >>>>>>>>>>>Added Helpdesk staff users to Account Operators built-in group.
> >>>>>>>>>>>Helpdesk staff still not able to manage user accounts/passwords, etc.
> >>>>>>>>>>>Used the Delegate Control wizard as workaround...... but I would like to fix
> >>>>>>>>>>>the issue with Account Operators--how can I make the sure the Account
> >>>>>>>>>>>Operators built-in group has all of the required permissions? What settings
> >>>>>>>>>>>do I check and where? (I suspect some of the default permissions for the
> >>>>>>>>>>>Account Operators group have been modified, but I have no idea which
> >>>>>>>>>>>ones....).
> >>>>>>>>>>>Thanks.
> >>>>>>>>>>>
> >>>>>>>>>>
>
.

Relevant Pages

  • Re: Want to turn permission propagation off in SetNamedSecurityInfo . . .
    ... The ACL and ACEs were pretty easy to parse, ... The object-specific ACEs are a bit weird and I ... determining the exact algorithms used to propagate the permissions. ... SE_FILE_OBJECT, read the dacl, then deleted any ACEs from the DACL ...
    (microsoft.public.platformsdk.security)
  • Re: DataSnap server DCOM installation.
    ... > for some reason it's not on my website. ... the ACL with the standard GetSecurityDecriptorDacl API. ... First build an ACL with the ACES you want, ... reg: TRegistry; ...
    (borland.public.delphi.nativeapi)
  • Re: Default Permissions
    ... When you look using the advanced view you see all ACEs in the ACL ... folder, ... carry no permissions on the contained files. ...
    (microsoft.public.security)
  • Re: Granting write priviledges to a folder
    ... "Rubio" wrote in message ... | I'm trying to grant everything but full control to a well-known local user group ... I basically get the ACL for the folder, create a new EXPLICIT_ACCESS struct, ... | I don't have to worry about the order of ACEs on the ACL. ...
    (microsoft.public.platformsdk.security)