Oops I forgot to send this last night when I responded to the rest of the emails...
=== You guys seems to be on the right track here. On the question of setting all objects configured with admincount=1 to admincount=0 is perfectly fine. As Robert indicated, it will get reset based on group memberships. Anything that does get set that way is in some group that is forcing this. I want to correct a couple of things in the post below Unless you have indexed objectclass (which I WHOLEHEARTEDLY recommend) you will want to use objectcategory over objectclass. When you do users you will want to combine objectcategory with objectclass like (&(objectcategory=person)(objectclass=user)) or alternatively do (samaccounttype=805306368). Also you don't need -s subtree, that is the default for adfind. On the admincount and inheritence. The question of whether it safe to reset everything and let it get corrected. The answer is maybe. If you are NOT depending on the functionality provided by adminSDHolder, knock yourself out, reset them all. What do I mean by this? I mean you aren't silly and sticking admin type IDs/groups into OUs controlled by non-admins (or using account operator accounts). This is what that whole piece of functionality is about. If you aren't doing that, you will have no issues resetting the ACL and clearing adminCount and letting AD clean it back up. If you are depending on that functionality (or account operator accounts), my first thought is stop it, but my main thought is you have to be more targeted in what you clean up. Keep in mind that adminCount isn't the main key in this, it is the ACL itself. If you clear all adminCount attributes but don't set inheritence on the ACL, I do not believe you will ever see adminCount get set again until the inheritence is cleared on those objects that are supposed to be protected (it has been a while since I looked into that functionality though) and the process cleans it up. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Thursday, June 09, 2005 10:26 AM To: 'Rimmerman, Russ '; Jorge de Almeida Pinto; 'Robert Williams (RRE) '; '[email protected] ' Subject: RE: [ActiveDir] Security permissions on user object I think the krbtgt account will also be listed. To get all objects (users and groups) with admincount =1 run: adfind -s subtree -b "<baseDN>" -f "(&(|(objectclass=group)(objectclass=user))(admincount=1))" -dsq > GROUPS&USERS_WITH_ADMINCOUNT.TXT For users: adfind -s subtree -b "<baseDN>" -f "(&(objectclass=user)(admincount=1))" -dsq > USERS_WITH_ADMINCOUNT.TXT For groups: adfind -s subtree -b "<baseDN>" -f "(&(objectclass=groups)(admincount=1))" -dsq > GROUPS_WITH_ADMINCOUNT.TXT Use the command line your prefer... Filter out accounts that MUST have the admincount property (e.g. administrator, krbtgt, default protected groups, etc.) Create a batch using excel. Import the TXT file into excel with the accounts you want to change the admincoutn property. admod -b "<baseDN of object>" "admincount::0" If the objects you changed are direct members of protected groups the admincount property will be reset to 1. If you use group nesting the object is a member of a non-protected group and that group is a member of a protected group the same will happenj -> the admincount property will be reset to 1. I prefer to only change those accounts that you want changed and not to change everything and wait until the PDC FSMO resets all accounts that you did not want to change #JORGE# -----Original Message----- From: Rimmerman, Russ To: Jorge de Almeida Pinto; Robert Williams (RRE) ; [email protected] Sent: 6/9/2005 12:53 PM Subject: RE: [ActiveDir] Security permissions on user object But is it safe to reset all admincounts back to 0? Running the ldifde report to see what accounts are going to change, I ended up with 126, and noticed "Administrator" is in there, as well as service accounts. How will setting admincount back to 0 affect these important accounts? ________________________________ From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Sent: Thu 6/9/2005 2:41 AM To: 'Robert Williams (RRE) '; '[EMAIL PROTECTED] '; Rimmerman, Russ; '[email protected] ' Subject: RE: [ActiveDir] Security permissions on user object If you look at MS-KBQ817433 "Delegated permissions are not available and inheritance is automatically disabled" you will see it provides a VB script to "Resets all accounts that have adminCount = 1 back to 0 and enables the inheritance flag". That article also tells you how to configure AD so that you designate which default MS admin groups are protected groups and thus managed by the adminsdholder object Cheers #JORGE# -----Original Message----- From: [EMAIL PROTECTED] To: Rimmerman, Russ; [email protected] Sent: 6/9/2005 5:52 AM Subject: RE: [ActiveDir] Security permissions on user object Oh Certainly...that would work quite well. Joe, how much should he charge for that ;-) Robert Williams, MCSE NT4/2K/2K3, Security+ Infrastructure Rapid Response Engineer Northeast Region Microsoft Corporation Global Solutions Support Center -----Original Message----- From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 10:52 PM To: Robert Williams (RRE); [email protected] Subject: RE: [ActiveDir] Security permissions on user object Can I just use ADSIEDIT and go to individual users and set the admincount to 0? Will that stick? If that works, I could write a winbatch that will prompt for a username, and set their admincount to 0 automatically. ________________________________ From: Robert Williams (RRE) [mailto:[EMAIL PROTECTED] Sent: Wed 6/8/2005 8:34 PM To: Rimmerman, Russ; [email protected] Subject: RE: [ActiveDir] Security permissions on user object Well...I guess you can reset it for all of them and count on the AdminSDHolder thread to reset them to 1 in about an hour or so...other than that, the logic needed in a script to differentiate between users who are / are not currently in one of the 'protected groups' would be astounding. You shouldn't have a problem trusting the fact that it will happen to the accounts still in the "protected groups" since that's what got you there in the first place :-) Hopefully that was helpful...have a great night! Robert Williams, MCSE NT4/2K/2K3, Security+ Infrastructure Rapid Response Engineer Northeast Region Microsoft Corporation Global Solutions Support Center ________________________________ From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:38 PM To: [email protected] Subject: RE: [ActiveDir] Security permissions on user object OK looks like ya'll are on the right track. I found the script in the KB article to reset all the admincounts to 0, but that sounds scary. Can't I selectively set admincounts to 0 on a user-by-user basis somehow? Or is it safe to reset all users' admincounts to 0? I see "Administrator" in there, so that vbscript in http://support.microsoft.com/default.aspx?scid=kb;en-us;817433 scares me. ________________________________ From: [EMAIL PROTECTED] on behalf of Robert Williams (RRE) Sent: Wed 6/8/2005 6:36 PM To: [email protected] Subject: RE: [ActiveDir] Security permissions on user object Also keep in mind that if you were ever a member of one of these 'protected groups' that your inheritance will not be "turned on" again, nor will the admincount attribute be reset to 0....so you can change those back when you know the user isn't a member of one of the 'protected groups' (changing those values before ensuring this will result in the values being reset...as you are well aware by this point). AdminCount is just a 'book keeping' method to know that the ACL has been stamped by AdminSDHolder. I hope that helps. Robert Williams, MCSE NT4/2K/2K3, Security+ Infrastructure Rapid Response Engineer Northeast Region Microsoft Corporation Global Solutions Support Center ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Free, Bob Sent: Wednesday, June 08, 2005 4:00 PM To: [email protected] Subject: RE: [ActiveDir] Security permissions on user object It ssounds like it's the adminSDHolder behavior that's getting you. Are the users members of any of the other protected groups? It varies across versions, IIRC 2003 added more groups. The articles below should help point in the right direction. http://support.microsoft.com/default.aspx?scid=kb;en-us;318180 http://support.microsoft.com/default.aspx?scid=kb;en-us;817433 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Wednesday, June 08, 2005 12:26 PM To: [email protected] Subject: [ActiveDir] Security permissions on user object We migrated all our users from an NT4 domain to our AD domain. Anyone who was in "Domain Admins" on our NT4 domain got migrated into "Domain Admins" on our AD domain. We took them out of Domain Admins on our AD domain, but their accounts are inheriting the permissions like a normal user inherits. Whenever someone who is NOT a domain admin tries to reset a password or modify any properties of these migrated "Domain Admins" who are no longer Domain Admins, they are denied access. If I open up one of these users, they are not inheriting the permissions on their user object like every other normal user does. If I open their account and go to the object security the "Inherit from parent the permission entries that apply to child objects. Include these with entries explicity defined here." box is not checked like every other user. If I check the box, others are temporarily able to modify that former domain admins account, but eventually, the box is unchecked again and they inherit their old security on their user object and it's broken again. I know that I once read that this is by design, but how the heck do I fix these users once and for all? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
