I would take a wild guess that this is ADSI having an issue with the
built-in group. I will also guess you are running this from a member and not
from a DC so it is probably squawking because the local machine can't figure
out the SID or some such nonsense since acc ops don't exist on members...
That is a complete guess but I have found the only real good ways to work
with ACLs is through c++ and the evil lower level calls. 

Anyway, my recommendation on this one would be to do a Schema Default reset.
Otherwise what would happen is if down the road you change your schema
default and say, for good reason, remove acc op or do something else then
you also have to modify this script. Now you could read the schema default
sd and slap that down or you could parse out to dsacls (/s) and let it do
the work, I would go for the latter. 

  joe

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A
Sent: Friday, July 09, 2004 5:52 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Scripting new ACE into DACL fails with Account Op
erators

I suspect that being a Built-in group has something to do with it...I'm just
looking for a way around that.  Obviously that group CAN be granted Full
Control on a user, since that's the default - I just can't seem to get the
script to see it that way.  Perhaps I'm using the wrong value for the Access
Mask ??

As to why I want to do this per-user...a couple reasons.  One, I don't want
to apply it to accounts that should not have it (although the next run of
the SDProp thread should fix that).  Two, the users in question are in the
default Users container, and Account Operators don't have blanket Full
Control of all user objects in there (although I suppose I could change
that).  The ACE for Account Operators to have Full Control seems to be
applied directly on a user object (not inherited) when the object is
created.

Suggestions are welcome !  What do other folks do when they remove someone
from one of the 'protected' groups to return them to a 'normal'
user status ?

Dave 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Friday, July 09, 2004 4:13 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Scripting new ACE into DACL fails with Account Op
erators


Not completely sure how to work around it, but they are different group
types.  Account Operators are built-in domain local accounts whereas your
test group is not. 

Curious why you want to apply this to each account vs. each OU if
inheritably permissions is in effect?

There may be something helpful here to jog the thought process:
http://www.microsoft.com/technet/community/scriptcenter/user/scrug128.ms
px

-ajm  

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fugleberg, David A
Sent: Friday, July 09, 2004 4:46 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Scripting new ACE into DACL fails with Account
Operators

I'm trying to fix up some user accounts that used to be in one of the admin
groups protected by AdminSDholder.  Using Robbie's most excellent cookbook,
I wrote a script to read a list of users and for each one, do the following:
- set AdminCount to zero
- turn on the "Allow Inheritable Permissions from parent..." checkbox
- grant Account Operators full control

The first two work fine.  The last one fails with an error "The Security ID
structure is invalid". I tried replacing the string "TADS\Account Operators"
with "TADS\Test Group", and that works fine.

Is there something that prevents Builtin groups from working here ?

Also, I have no idea why this works even though the line
oSD.DiscretionaryACL = oDACL is commented out.

Here's the applicable snippet of code:
<SNIP>
                '### Get Security Descriptor  for this user ###
                set oSD = oUser.Get("ntSecurityDescriptor")

                '### Get DACL for this Security Descriptor
                set oDACL = oSD.DiscretionaryACL

                '### Create a new ACE
                set oACE = CreateObject("AccessControlEntry")
                oACE.Trustee    = "TADS\Account Operators"
                oACE.AccessMask = ADS_RIGHT_GENERIC_ALL
                oACE.AceFlags   = 0
                oACE.Flags      = ADS_FLAG_OBJECT_TYPE_PRESENT
                oACE.AceType    = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

                '### Add new ACE to DACL
                oDACL.AddAce oACE                

                '### Replace DACL in Security Descriptor with the updated
DACL
                'oSD.DiscretionaryACL = oDACL

                '### Replace Security Descriptor with the updated SD
                oUser.Put "ntSecurityDescriptor", oSD
                oUser.setInfo
                wscript.echo "error is " & err.number
</SNIP>

Most of this is lifted from Recipe 13.6 in the Tuna book.

Dave 
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to