RE: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - Registry Security

[Fugleberg, David A]

Title: Message

We had a situation some time ago where much of the DDCP was accidentally changed.  While troubleshooting another issue, PSS had one of our people recreate the 'local' group policy file on a DC, using the procedure in Q278316.  PSS assured him that they do this all the time and it would not affect any policy at the domain level.  When things began to fail, we discovered that many things were missing from the DDCP.  For example, the Exhange Enterprise Group no longer had the "Manage auditing and Security" user right.  In addition, there were things in the DDCP that don't belong there, like user rights assigned to 'Power Users".  We were assured again that the process in 278316 could in no way affect the DDCP.  After many phone calls and e-mails, PSS tried it and recreated the issue.   In the mean time, we compared the DDCP with a backup we had snapped with the GPMC some time before, and we saw that there were hundreds of strange things in the DDCP before this change was done - mostly stuff in the User Rights Assignments section of Computer Configuration/Windows Settings/Security Settings/Local Policies section.  I know that nobody would have editied them into the DDCP manually.  I suspect they got there by applications being installed on DCs that meant to modify local policy on the server but wound up in the DDCP.  Yeah, I know, the apps shouldn't have gone on the DC in the first place...we're cleaning that up.   Also, we saw similar issues when an admin followed the wrong procedures and ran the basicsv.inf security template on a DC - it changed a bunch of the account policy stuff in the DDP.  That was fun too.   So, there are several ways to mess up your DDP/DDCP without touching them with the GPE or GPMC.  I'm intrigued with the ideas discussed by Willem and Guy - they sound like a promising approach to provide some protection for those policies.  Has anybody seen new problems introduced by modifying the ACLs of those objects ?   Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Tuesday, November 09, 2004 3:00 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - Registry Security Thanks Guy - I'll take that hint into consideration as well.    Mind you, instead of fooling around with the SDDL version of the defaultSecurityDescriptor of any object in AD's schema, it's much easier to edit it via the Schema Mgr MMC => go to the respective object and edit the default ACLs via the "Default Security" tab (in Win2000 this tab is called "Security", but also refers to the default security of new objects of this type).   This way I've also adjusted the default rights for users, so that the SELF sec.principal doesn't have any special write permissions on the user object (protecting AD from unwanted updates by users). We then grant inherited permissions for SELF at the OU level for only those attributes of the user objects which the users are supposed to be allowed to edit (which aren't many).  This saves us from internal "attacks" such as users uploading a large picture file to the thumbnail attribute etc.   Thanks, Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Tuesday, November 09, 2004 1:11 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - Registry Security What we did in our environment was: -         disabled the links of DDP/DDCP to domain object and Domain Controllers OU -         remove “Group Policy Creator Owners” from the ACL of “CN=Policies,CN=System,DC=domain,DC=com” and added our own group with permissions to create objects in the container. -         changed the defaultSecurityDescriptor attribute of Group-Policy-Container object, trimmed the Domain Admins to read-only and introduced a new security group with full permissions over newly created GPOs (SDDL is an ugly thing to work with, so if you are interested in quick and dirty SDDL parser I wrote, grab it from here: http://www.petri.co.il/forums/download.php?id=43 ). This way the GPOs are created with ACL which does not allow default groups to change it (see http://www.jsiinc.com/SUBL/tip5500/rh5528.htm for details) -         created new GPOs to replace DDP/DDCP (those were created with the adjusted ACL)   Guy   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Willem Kasdorp Sent: Monday, November 08, 2004 5:40 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - Registry Security   I have had similar issues before at customer sites with apps modifying the DDP and DDCP, although none this bad. ADMT is a notorious offender.  I am seriously tempted to fix it in the following way:   -          create a new DDP/DDCP (new name of course) with highest prio. Edit any additional settings in the new policies. -          Remove write for Domain Admins on the DDP/DDCP, and instead create an additional group for write permissions. This group is empty by default.     This story might just trigger me to do it…   --     Regards, Willem   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Monday, November 08, 2004 2:57 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - Registry Security   Hello folks,   I've just had a very curious issue at a customer, which took us a while to figure out. You should all be aware of this as it could hurt you as well.  After testing everything successfully in the lab (and ADPREPing the production forest + domains), we've inplace-upgraded the first production DC from Win2000 to Win2003 and it failed with errors such as a crashing LSASS and a DHCP service, which couldn't start due to access violation etc.   It turns out that this was caused due to a lengthy list of policy settings on the Def Domain and Def DC Policy, which configured Security (ACL) over one hundred registry keys and File System folders and files.   The resulting permissions were ok for Windows 2000, but incompatible with Windows Server 2003 - e.g. the DHCP Client Service and the TCPIP Service require specific permissions on their respective registry keys for the DHCP service to start via the new Network Service account. I see other's in this list have also had issues with the DCHP service, which may be related to the same thing.   Although we now fixed the issue by cleaning the policies and un-promoting the DC and reinstalling it from scratch (since the 2003 OS's default permissions were effectively overwritten due to the policy), I am looking for clues on how these weird settings were introduced to the Def Dom and the Def DC policy in the first place?     The settings were definitely not added manually "by accident" -  more likely by some whacky setup routine.  Does anybody have an ideas or experience with respect to services/apps which could have changed the domain policies in this way?     Thanks for any feedback, Guido