Account Operators Group
in [Active Directory]
|
From: mpatraw_EPIC_Imaging on 29 May 2008 19:06 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. "Herb Martin" wrote: > > "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in > message news:uT9CeIcwIHA.3860(a)TK2MSFTNGP06.phx.gbl... > > > > "Herb Martin" <news(a)learnquick.com> wrote in message > > news:OEZoxybwIHA.3680(a)TK2MSFTNGP05.phx.gbl... > >> > >> "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in > >> message news:uQApoZbwIHA.3384(a)TK2MSFTNGP03.phx.gbl... > >>> 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. > >> > >> Amazing (since) I didn't know that <grin> > >> > > > > 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. > > My guess is it will (might?) not do that in this direction..... > > >
From: mpatraw_EPIC_Imaging on 29 May 2008 19:42 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 "Herb Martin" wrote: > > "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in > message news:uQApoZbwIHA.3384(a)TK2MSFTNGP03.phx.gbl... > > 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. > > Amazing (since) I didn't know that <grin> > > >
From: Richard Mueller [MVP] on 29 May 2008 21:18 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 -- "mpatraw_EPIC_Imaging" <mpatrawEPICImaging(a)discussions.microsoft.com> wrote in message news:6FE36014-EDF7-4930-8B94-CCDE58DFD6CC(a)microsoft.com... > 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. > > "Herb Martin" wrote: > >> >> "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in >> message news:uT9CeIcwIHA.3860(a)TK2MSFTNGP06.phx.gbl... >> > >> > "Herb Martin" <news(a)learnquick.com> wrote in message >> > news:OEZoxybwIHA.3680(a)TK2MSFTNGP05.phx.gbl... >> >> >> >> "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote >> >> in >> >> message news:uQApoZbwIHA.3384(a)TK2MSFTNGP03.phx.gbl... >> >>> 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. >> >> >> >> Amazing (since) I didn't know that <grin> >> >> >> > >> > 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. >> >> My guess is it will (might?) not do that in this direction..... >> >> >>
From: Richard Mueller [MVP] on 29 May 2008 23:08 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. -- Richard Mueller MVP Directory Services Hilltop Lab - http://www.rlmueller.net --
From: mpatraw_EPIC_Imaging on 4 Jun 2008 13:19 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. "Wayne Tilton" wrote: > "Herb Martin" <news(a)learnquick.com> wrote in > news:efE0fdcwIHA.4736(a)TK2MSFTNGP04.phx.gbl: > > > > > "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote > > in message news:uT9CeIcwIHA.3860(a)TK2MSFTNGP06.phx.gbl... > >> > >> "Herb Martin" <news(a)learnquick.com> wrote in message > >> news:OEZoxybwIHA.3680(a)TK2MSFTNGP05.phx.gbl... > >>> > >>> "Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> > >>> wrote in message news:uQApoZbwIHA.3384(a)TK2MSFTNGP03.phx.gbl... > >>>> 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. > >>> > >>> Amazing (since) I didn't know that <grin> > >>> > >> > >> 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. > > > > My guess is it will (might?) not do that in this direction..... > > > > You need to re-enable inheritance on the individual objects, either via > the GUI or using some tool like DSACLS. > > HTH, > > Wayne Tilton >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: windows 2008 machine joining problem Next: cannot join WinXP to Windows 2000 domain |