I'm running this directly on a lab DC, so that particular guess shouldn't apply...I'm not about to start mucking around in c++ for this (too many years since I've written a line of c or c++ code).
Your suggestion of dsacls /s started me down a different path...turns out the /P:N switch along with the /S switch takes care of both turning on inheritance and sorting out the ACLs. I put it in a script, which also sets AdminCount to zero, and that seems to work ok.DSACLS has a /P switch that I'd never noticed before. Thanks to google, I found someone else who had used this successfully to do the same thing I'm trying to do. So, now my script simply: - sets AdminCount to zero - runs DSACLS DNofUser /P:N /R Guest /S For some reason, the /P:N doesn't seem to work without the /R Guest. I never would have figured that out if I hadn't found that google posting... Anyhow, thanks for (once again) putting me on the right track. Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 09, 2004 7:21 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Scripting new ACE into DACL fails with Account Op erators 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/ 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/
