Account Operators Group

  • Thread starter Thread starter mpatraw_EPIC_Imaging
  • Start date Start date
M

mpatraw_EPIC_Imaging

I have 5 users in the Account Operators Group. They can administer only a
few of the 250+ user accounts in AD. On the accounts they can administer the
Account Operators group is listed in the security tab of the user object.
Account Operators is not listed on the security tab of the user objects which
are not available to administer.

I have 2 questions:

1. How is the Built In group (Account Operators) not listed in the security
tab of all user objects?

2. Is there an easy fix for this, or a script that I can modify users
security ACE to add account operators group. Keeping in mind I wouldn't want
to add them to other Built In groups such Exterprise Admins, Domain Admins,
etc...
 
mpatraw_EPIC_Imaging said:
I have 5 users in the Account Operators Group. They can administer only a
few of the 250+ user accounts in AD. On the accounts they can administer
the
Account Operators group is listed in the security tab of the user object.
Account Operators is not listed on the security tab of the user objects
which
are not available to administer.

I have 2 questions:

1. How is the Built In group (Account Operators) not listed in the
security
tab of all user objects?

2. Is there an easy fix for this, or a script that I can modify users
security ACE to add account operators group. Keeping in mind I wouldn't
want
to add them to other Built In groups such Exterprise Admins, Domain
Admins,
etc...
Click to expand...

When a user object is created, I believe the system adds an ACE that grants
the group BUILTIN\Account Operators full control of the object. The only
explanation I can think of is that someone removed the ACE's. I have never
seen a user object without this ACE, except members of Domain Admins.

A VBScript program can check for the ACE in the DACL of the user, and add it
if it is not found. The technique would be similar to that used in this
example VBScript program that adds ACE's that deny permission for the user
to change their password:

http://www.rlmueller.net/Cannot Change PW.htm

I have to think about a script for this. One added feature is that you
probably want a script to operate on all users in bulk, but only modify
those without the ACE. I would certainly test on a few users, before running
a script on all users.

Also, the Administrator user does not have this ACE, and should not. I
wonder what other users should not. Even users that are members of the
builtin Administrators have the ACE, but not members of Domain Admins.
Further research is needed, which may be difficult.
 
Does this article explain what you see:

http://support.microsoft.com/kb/245174

Per the article Account Operators cannot manage users that are members of
the following restricted groups:

Account Operators
Administrators
Backup Operators
Print Operators
Server Operators
Domain Admins

If you have users that are not members of any of these groups, even due to
group nesting, and lack the ACE, then you have a problem. However, any
program to fix it must check each user for membership in any of these
groups, or any other groups that are members of these groups.
 
Richard Mueller said:
Does this article explain what you see:

http://support.microsoft.com/kb/245174

Per the article Account Operators cannot manage users that are members of
the following restricted groups:

Account Operators
Administrators
Backup Operators
Print Operators
Server Operators
Domain Admins

If you have users that are not members of any of these groups, even due to
group nesting, and lack the ACE, then you have a problem. However, any
program to fix it must check each user for membership in any of these
groups, or any other groups that are members of these groups.
Click to expand...

I was going to mention this.

And as to the delegation of authority, it can be performed for
this group or others using either Permission tabs or the
delegation of control wizard (right click on domain or OU.)
 
Richard,

Thanks for the response.
I read this article, but I guess I didn't check every group. I just checked
and all of the users that are not able to be administered by Account
Operators are part of the Print Operators group. I'm not sure how that
happened. I guess it's possible that a new user being created by copying an
existing user, some of those copied users had print operators and were just
not removed after being created.

Question. If I remove those users from Print Operators, should they they
regain the security ACE for Account Operators? I will test a few..
 
I'm glad this accounts for what you see. Yes, changing membership in the
Printer Operators group will make the ACE get added or removed as
appropriate, but there is a time delay. A system process does this in the
background. You may need to wait 15 minutes or so.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

mpatraw_EPIC_Imaging said:
Richard,

Thanks for the response.
I read this article, but I guess I didn't check every group. I just
checked
and all of the users that are not able to be administered by Account
Operators are part of the Print Operators group. I'm not sure how that
happened. I guess it's possible that a new user being created by copying
an
existing user, some of those copied users had print operators and were
just
not removed after being created.

Question. If I remove those users from Print Operators, should they they
regain the security ACE for Account Operators? I will test a few..
Click to expand...
 
Richard Mueller said:
I'm glad this accounts for what you see. Yes, changing membership in the
Printer Operators group will make the ACE get added or removed as
appropriate, but there is a time delay. A system process does this in the
background. You may need to wait 15 minutes or so.
Click to expand...

Amazing (since) I didn't know that <grin>
 
Herb Martin said:
Amazing (since) I didn't know that <grin>
Click to expand...

Well, maybe I'm not completely correct. I tested by adding a user to the
Print Operators group, saw that the Account Operators ACE was still there,
waited about 15 minutes, and saw that the ACE was gone. I then removed the
user from the Print Operators group, saw that the ACE was still gone, and
assumed I would have to wait a similar period. I replied to the post. Since
then I have waited over an hour and the ACE has still not been restored to
the user account. I need to investigate some more, because I'd rather not
try to correct this myself unless I have to. Maybe the background process
runs less frequently than I thought.

Richard
 
Richard Mueller said:
Well, maybe I'm not completely correct. I tested by adding a user to the
Print Operators group, saw that the Account Operators ACE was still there,
waited about 15 minutes, and saw that the ACE was gone. I then removed the
user from the Print Operators group, saw that the ACE was still gone, and
assumed I would have to wait a similar period. I replied to the post.
Since then I have waited over an hour and the ACE has still not been
restored to the user account. I need to investigate some more, because I'd
rather not try to correct this myself unless I have to. Maybe the
background process runs less frequently than I thought.
Click to expand...

My guess is it will (might?) not do that in this direction.....
 
My guess is it will (might?) not do that in this direction.....
Click to expand...

You need to re-enable inheritance on the individual objects, either via
the GUI or using some tool like DSACLS.

HTH,

Wayne Tilton
 
Herb,

It looks like you are experiencing the same thing I am. I have waited all
day (approx. 7 hours) thus far and still have not seen the Account Operators
group reappear on any of the ACE's for AD user objects. I thought I wasn't
waiting long enough, however we have a very simple Domain structure, and no
propagation has ever taken this long.

I will keep you posted.
 
Removed end users from Print Operators and checked all other Built-In groups
to ensure they did not contain normal users. Have waited more then 7 hours
and Account Operators has not been added to any of the user account objects
ACE's that were missing it before.

Is the
 
I believe this KB article describes the process:

http://support.microsoft.com/kb/232199

This only talks about members of the built-in Administrators and Domain
Admins groups, but I think either this or something very similar applies to
the protected groups, including "Account Operators" and "Print Operators".

The AdminSDHolder process runs once per hour on the DC with the PDC Emulator
role (and then gets replicated), but only in one direction. Anyone made a
member of a protected group gets the ACL's assigned to the AdminSDHolder
object, which is a container in the "cn=System" container. You can view the
ACE's assigned to this object and see that they match those assigned to
members of "Print Operators". Unfortunately, if an account is removed from
all protected groups the ACE's remain, they are not restored to what they
were.

The ACE's are completely different. Wayne Tilton is correct that one of the
changes inherited from the AdminSDHolder object is that inheritable
permissions from parent no longer propagate. However, I don't think checking
to allow inheritance will fix the DACL. Per the KB article the ACE's must be
manually changed. Mostly the AdminSDHolder process removes ACE's, but I see
an ACE for "Terminal Server License Servers" is added.

I should note that the "Account Operators" group is a holdover from NT
domains. It remains for backward compatibility. It is recommended (by
Microsoft and others) that it not be used in Windows 2000 Native AD (and
above). Instead you should create your own groups and grant them the
specific permissions required. I think this issue explains the
recommendation.

I have an example VBScript program that dumps out the DACL for a specified
object linked here:

http://www.rlmueller.net/DACL.htm

When I compare two normal (test) user accounts, the first left alone, the
second added to the Print Operators group and then removed, I find that the
output from DACL.vbs is almost twice as large for the first account. This
means a lot was lost when the second account was added to the Print
Operators group.

I'm not sure what to recommend. I've written scripts to add and remove ACE's
from a DACL, but this is a big change, and we would need to assume the DACL
should match that of a newly created user.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
 
I decided that rather than deal with the individual ACE's, I could simply
copy the DACL from one user to another. This is much simpler. I don't know
of any tools for this. The example VBScript below worked for me. I hard code
the DN of a "template" user, a new normal user account that has never been
added to any groups (except Domain Users). You pass the DN of the user to be
fixd to the script:
==========
' CopyDACL.vbs
' VBScript program to copy DACL from one user to another.
Option Explicit

Dim strTemplateDN, strUserDN, objTemplateUser, objUser, objSecDescriptor

' Check for required argument.
If (Wscript.Arguments.Count < 1) Then
Wscript.Echo "Required argument <Distinguished Name> missing. " _
& "For example:" & vbCrLf _
& "cscript CopyDACL.vbs cn=TestUser,ou=Sales,dc=MyDomain,dc=com"
Wscript.Quit(0)
End If

' Bind to the user object with the LDAP provider.
strUserDN = Wscript.Arguments(0)
On Error Resume Next
Set objUser = GetObject("LDAP://" & strUserDN)
If (Err.Number <> 0) Then
On Error GoTo 0
Wscript.Echo "User not found" & vbCrLf & strUserDN
Wscript.Quit(1)
End If
On Error GoTo 0

' Specify Distinguished Name of template user.
strTemplateDN = "cn=TemplateUser,ou=Sales,dc=MyDomain,dc=com"

' Bind to template user object.
Set objTemplateUser = GetObject("LDAP://" & strTemplateDN)

' Bind to the template user security objects.
Set objSecDescriptor = objTemplateUser.Get("ntSecurityDescriptor")

' Update the user object.
objUser.Put "ntSecurityDescriptor", objSecDescriptor
objUser.SetInfo
===========
To do this in bulk for many users I would perhaps operate on an array of
specified user DN's. You don't want to do this to any members of protected
groups, although I guess they would be refixed in the next hour. You could
modify the above to either read DN's from a file, or hard code an array of
DN's. For a few messed up users you can just run the above for each.
 
Used dsacls with the /S /T switch to update Users tree of objects to ACL
defaults. If you do this be careful as the tool doesn't work as indicated.
Under DsAcls Help, Syntax reads:
"/T
Restores the security on the tree of objects to the default for each object
class. This parameter is valid only with the /S parameter."

However Built-In groups such as Domain Admins, Enterprise Admins and others
were also modified to add the Account Operators group and grant full access.
I guess I could be reading this wrong, but I consider Users and Built-In
groups to be different object classes.

Anyway, I removed the Account Operators group from those built-in groups and
all is well.

Thanks to everyone for their input and help on this issue.
 
Used dsacls with the /S /T switch to update Users tree of objects to ACL
defaults. If you do this be careful as the tool doesn't work as indicated.
Under DsAcls Help, Syntax reads:
"/T
Restores the security on the tree of objects to the default for each object
class. This parameter is valid only with the /S parameter."

However Built-In groups such as Domain Admins, Enterprise Admins and others
were also modified to add the Account Operators group and grant full access.
I guess I could be reading this wrong, but I consider Users and Built-In
groups to be different object classes.

Anyway, I removed the Account Operators group from those built-in groups and
all is well.

Thanks to everyone for their input and help on this issue.
 
Back
Top