Re: Win2k - Account Operator not working properly

Take the whole ACL dump and find/replace domain/group names that indicate anything. You can use domain1 domain2 domain3, etc and group1 group2 group3.

You very likely have other ACL issues other than what was mentioned and I can point them out here for you for free or you can pay someone $200-500 an hour to come check it out.


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

Nope vbscript or perlscript, something that walks through the entire ACL chain looking for duplicate ACEs and removing them. You can not do that with DSACLS, it won't let you remove a single ACE, you need to remove all ACEs that a apply to a security principal with DSACLS and the GUI, it is just the way they are written.


> 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.....

When you use the copy option, the schema tells which attributes get copied. The security descriptor is not set to be copied by default, the system will use the default security descriptor of the object class. In order for that to result in inheritence protection it means the schema had to be modified. Other than that, the user is in a protected group and adminsdholder is cleaning it up.

Try this, set the account in the GUI to inherit from its parents. Save it, then go back and look in a couple of hours. If the inheritence is cleared, this is definitely adminsdholder. If it isn't, it is the creation process.




--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


thawkz wrote:
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: Permissions resetting in Blocked Inheritance OUs
    ... If the ACL that is on the AdminSDHolder object is ... Delegated permissions are not available and inheritance is automatically ... "You do not have sufficient permissions in the Domain" error message occurs ... This user account is in an OU that has Blocked ...
    (microsoft.public.windows.server.active_directory)
  • RE: Starting publishing point

    (microsoft.public.windowsmedia.server)
  • Re: Incoming E-Mail - cant create contact in OU
    ... account out of local administrator to attempt to find any denied access. ... I then added full permissions to my user account on both of these keys, ... local admin rights to the server hosting incoming email. ... what permission I need to give the app pool locally to avoid this issue. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Incoming E-Mail - cant create contact in OU
    ... account out of local administrator to attempt to find any denied ... I then added full permissions to my user account on both of these keys, ... that's for every app pool you create for every new web app on the ... local admin rights to the server hosting incoming email. ...
    (microsoft.public.sharepoint.windowsservices)
  • Consider Windows XP File Security and Group Policies
    ... If you are running Windows XP and are using the NTFS file system, ... Account from being able to purge its history footprint files. ... Changing Folder permissions to Read-Execute instead of Full ... you globally apply Full Control for the Administrators group and the SYSTEM ...
    (microsoft.public.windowsxp.general)