Account Operators Group does not have permissions to users

[CK]

I inherited a domain that is running in Win 2k native mode. There are some
wacky policies that i'm unsure of. I have tried to add Help Desk users to the
Account Operators group however I have noticed that the Account Operators
group is not listed in the user "Security" tab for each user. What is the
best way to push this out to all of the users?

[Richard Mueller [MVP]]

Post by CK
I inherited a domain that is running in Win 2k native mode. There are some
wacky policies that i'm unsure of. I have tried to add Help Desk users to the
Account Operators group however I have noticed that the Account Operators
group is not listed in the user "Security" tab for each user. What is the
best way to push this out to all of the users?

The ACE's listed on the "Security" tab are changed when a user is made a
member of a restricted group like "Account Operators", but you don't see the
group membership there. You should see it on the "MemberOf" tab. If you look
at normal users on the "Security" tab there is an ACE for "Account
Operators". This is removed for members of restricted groups. Does this
explain what you see?

[Richard Mueller [MVP]]

Post by Richard Mueller [MVP]

Post by CK
I inherited a domain that is running in Win 2k native mode. There are some
wacky policies that i'm unsure of. I have tried to add Help Desk users to the
Account Operators group however I have noticed that the Account Operators
group is not listed in the user "Security" tab for each user. What is the
best way to push this out to all of the users?

The ACE's listed on the "Security" tab are changed when a user is made a
member of a restricted group like "Account Operators", but you don't see
the group membership there. You should see it on the "MemberOf" tab. If
you look at normal users on the "Security" tab there is an ACE for
"Account Operators". This is removed for members of restricted groups.
Does this explain what you see?
--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Sorry, I used the wrong term. In Group Policy you use "Restricted Groups" to
enforce membership in groups. A few builtin groups are termed "protected"
groups, including "Account Operators", "Print Operators", and
"Administrators". A process runs on the PDC Emulator once an hour that
enforces the ACE's in the DACL for all members of the protected groups.
That's what you see on the "Security" tab.

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.

[CK]

Richard,
I see what your saying by creating your own groups. Definitely a
possibility, however I would probably rather perform neuro surgery than go
through the delegation wizard. Who thought this train wreck up? I was hoping
to just throw some people in the account operators group and be done with it.
That said, what is the best way to do that? If to involved and complex, I'll
proceed with the delegation wizard.

[Paul Bergson [MVP-DS]]

Account Operators is a Domain group and you place the users in there, that
is it nothing else to do. This is a deprecated group and I would suggest
using the Delegation of Control wizard, but you are managing your domain so
you choose how to manage.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

Post by CK
Richard,
I see what your saying by creating your own groups. Definitely a
possibility, however I would probably rather perform neuro surgery than go
through the delegation wizard. Who thought this train wreck up? I was hoping
to just throw some people in the account operators group and be done with it.
That said, what is the best way to do that? If to involved and complex, I'll
proceed with the delegation wizard.

[CK]

Since I want the Account Operators to have permissions to normal users, I
wouldn't place the users in this group. If we go back to the original issue,
the Account Operators did not have permissions to many users and we noticed
that they were not in the Security Tab of the users in ADUC.

[Richard Mueller [MVP]]

Post by CK
Since I want the Account Operators to have permissions to normal users, I
wouldn't place the users in this group. If we go back to the original issue,
the Account Operators did not have permissions to many users and we noticed
that they were not in the Security Tab of the users in ADUC.

Every normal user should have an ACE that grants special permissions to the
Account Operators group on the user object. Members of protected groups like
Account Operators lack this ACE (and others). For example, if JSmith is a
normal user that has never been a member of a protected group, the JSmith
user object will have a ACE that grants Account Operators special
permissions on the object. However, if MWilson is made a member of Account
Operators, the ACE's will be replaced so that Account Operators no longer
has the additional permissions on the MWilson object. In other words, member
of Account Operators get additional permissions on all users except members
of protected groups (like Account Operators). I believe this is why people
recommend not using the group. Once you make someone a member of Account
Operators it's hard to restore the ACE's. The method I use is to create a
template user that is never a member of any protected group. I can restore a
user to the default permissions by copying the DACL from the template user
to the messed up user.

If you make MWilson a member of Account Operators, and they cannot manage
the JSmith object, then I would suspect that JSmith was once a member of a
protected group. Any users that do not have the ACE for Account Operators
may be in this boat. To be honest, the only solution I know of is to copy
the DACL as I suggested. If you need this, here is the VBScript program I
used to fix users in my test domain. The DN of the "template" user is hard
coded in the program. You pass the DN of the user to be "fixed" to the
program. If the messed up user had any special permissions, those are lost.
==========
' CopyDACL.vbs
' VBScript program to copy DACL from one user to another.
' Version 1.0 - May 29, 2008

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=West,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=West,dc=MyDomain,dc=com"

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

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

' Update the user object with the template security descriptor.
objUser.Put "ntSecurityDescriptor", objSecDescriptor
objUser.SetInfo