John Policelli's Blog

NOTE: I revised this article to fix some mistakes and to include new content from Windows Server 2008 R2.

Active Directory has built-in processes that exist to secure users that are members of privileged groups. These processes have been around for quite some time, but Active Directory administrators still get stumped by them regularly. What follows, is a updated look at AdminSDHolder, Protected Groups, and SDPROP. Windows Server 2008 R2 specific content has been added.

This article will provide you with the following information:

• Overview
• How AdminSDHolder Works
• Default ACL on the AdminSDHolder Object in Windows Server 2008 R2
• Default Protected Groups and Users
• Modifying How Often the AdminSDHolder Background Process Runs
• How to Determine if a User or Group is Protected by AdminSDHolder
• Orphaned AdminSDHolder Objects
• Security Descriptor Propagator
• How to Force AdminSDHolder to Run
• Additional Resources

Read the rest of this entry »

Since the release of Exchange Server 2010 RC1, there’s been a lot of debate over some ACEs that are added to the AdminSDHolder object by /PrepareDomain in Exchange 2010 RC1. For more information on this, see Exchange 2010 Modification of AdminSDHolder ACL Can Result in Elevation of Privilege and Exchange 2010 RC1 and AdminSDHolder.

A post was added to the Microsoft Exchange Team Blog this morning that confirms that this has been resolved in the RTM version of Exchange Server 2010. More specifically:

• /PrepareDomain no longer applies ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container.  If /PrepareDomain detects the ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container, /PrepareDomain will remove them.
• /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the AdminSDHolder container.  If /PrepareDomain detects this ACE granted to Exchange Servers USG on the AdminSDHolder container, /PrepareDomain will remove it.
• /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the domain partition.  If /PrepareDomain detects this ACE granted to Exchange Servers USG on the domain partition, /PrepareDomain will remove it.
• /PrepareDomain no longer applies an unscoped DeleteTree and WriteDACL ACEs on the domain partition.  Instead, these ACEs are replaced by scoping them specifically to user and inetOrgPerson class objects.

UPDATE: This has been resolved in the RTM version of Exchange Server 2010. Please see Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue for more details.

The PrepareDomain setup phase of Exchange 2010 RC1 adds several Access Control Entries (ACEs) to the Access Control List (ACL) of the AdminSDHolder object. One of these ACEs, Write Property for member, can be used to elevate privileges from Exchange Organization Administrator to Enterprise Admins.

Read the rest of this entry »

I ran across a post on the Ask the Directory Services Team blog which is an important read for anyone who manages Active Directory.

The MS Directory Services team has found that Conficker infected computers are throwing bad password attempts, as many as 10,000 per minute from multiple clients, which in turn causes LSASS to consume a lot of CPU time on DCs.

The full post can be read by going to http://blogs.technet.com/askds/archive/2009/04/16/conficker-causes-lsass-to-consume-cpu-time-on-domain-controllers.aspx.

The Directory Services Restore Mode (DSRM) account is used to log on to a domain controller in Directory Services Restore Mode to perform maintenance and recovery tasks. This account is often forgotten by most AD administrators, which results in a significant security risk. If exploited, this security risk can cause high impact.

I have ran Active Directory security assessments for a number of small, medium, and large sized companies over the years. In almost every case, I have identified the DSRM account as a risk, because it was not being secured adequately. I felt compelled to use this post to emphasize the importance of securing the DSRM account.

This is not a post that describes how-to change the password on a DSRM account; there’s thousands of such articles on the web. This post aims to give you a thorough understanding of the risks associated with not properly securing DSRM accounts, the impact of exploited DSRM accounts, and my recommendations to secure DSRM accounts.

Read the rest of this entry »

Let me start by stating that this article is NOT intended to be used to break Active Directory or for any malicious reasons. This article is intended to show that the use of built-in security groups, coupled with failing to follow the Principal of Least Privilege, is a HORRIBLE practice and can cause significant impact to your Active Directory environment.

In 2005 I provided a demonstration for a user group that showed that the use of built-in security groups, coupled with failing to follow the Principal of Least Privilege, could cause a domain-wide outage. In recent months, I have seen individuals posting in newsgroups and forums who have mistakenly exposed themselves to this same issue. Even more recently, I received an email from someone who attended my presentation in 2005 informing me that they too were impacted by this issue.

I decided to extract the relevant information from my 2005 demonstration and post it online. Again, my intent is not to show how you can break Active Directory. Rather, I intend to show you that by using built-in groups and failing to follow the Principal of Least privilege, you can make it very easy for someone to intentionally or unintentionally cause a domain-wide outage. I have updated my original content to include Windows Server 2008, as this risk also applies to Windows Server 2008.

In this article, I demonstrate how someone with membership in the built-in Account Operators group can (intentionally or unintentionally) exploit a system limitation and prevent all users in your domain from logging on. I start by providing some background information before the demonstration. I then provide some additional information on why the risk exists and what you can and cannot do about it. I conclude with some general recommendations and best practices to avoid such outages. Read the rest of this entry »

Windows Server 2008 introduces a new option designed to protect Active Directory Domain Services Objects (AD DS) objects from accidental deletion. I know of a number of companies that have experienced an impact on business continuity that could have been avoided by using this option. In my experience, the accidental deletions that have created the most impact were Organizational Unit (OU) deletions. This is likely why Microsoft has decided to enable this option by default when OUs are created through the Active Directory Users and Computers (ADUC) console.

Read the rest of this entry »