Blog roll

News

Navigation

Whitepapers

The challenge

It’s not like it didn’t happen in the past. You might not have heard of any organizations going out of business due to disastrous Identity and Access Management, but I’ve seen a couple in my heyday… To be honest, most organizations had trouble throughout, including a lack of proper processes, policies and auditing. The ‘pile-on effect’, due to not being able to find the root cause of issue, inadequate documentation and the inability to restore backups, eventually got the best of them.

(Parts of) The Solution

So, how do we avoid misconfiguring Active Directory?
- Anonymous customer

As many Active Directory admins have asked me how to avoid misconfiguring Active Directory. Either stemming from true loyalty towards their employer or from a Cover Your *ss (CYA) attitude, this question is a good one. The answer is pretty simple though:

Apply the Principle of Least Administrative Privilege

The amount of administrators, able to make changes to the database, and their administrative reach, as in the changes they’re allowed to make, should be as limited as possible. In real-world environments, membership to the groups Enterprise Admins and Enterprise Admins but also domain admins in a multi-forest environment, should only be given to the most trustworthy and capable persons in your organization. The Schema Admins group, on the other hand, should be empty by default as a best practice, since as an Active Directory admin, you would only need access to its permissions when you perform a (planned and tested) Active Directory schema update, defunct and/or extension.

Use the Best Practices Analyzer (regularly)

Since Windows Server 2008 R2, Microsoft ships Best Practices Analyzers (BPAs) with Windows Server. Best Practices Analyzers help you to avoid 80% – 90% of the common misconfigurations that lead to data loss. You do not need to purchase BPAs as extras; you gain access to them from the Server Manager and through the many Best Practice Analyzer PowerShell Cmdlets. The ability to run the BPAs from a remote (management) workstation with the Remote Server Administration Tools (RSAT) installed and through PowerShell make them useful in environments with Server Core installations too.

The Active Directory Domain Services Best Practices Analyzer (AD DS BPA) checks for many misconfigurations at the server level (PDCe time synchronization is a big one, that pops up in many environments I see), at the organization-level (Regular Backups), but also inside the Active Directory. One important AD DS BPA check within the database, that I particularly like, is whether all Organizational Units (OUs) are protected against accidental deletion.

Protect important objects against accidental deletion

Even in organizations with well-skilled Active Directory admins, people slip up.(Administration is still a job done by humans, and humans tend to make mistakes)

Many processes in Active Directory already exist to prevent changes you might not want to see occur. AdminSDHolder is a prime example of such processes; Hourly, it mulls through the ACLs on user objects that are part of typical administration groups (Domain Admins, Print Operators, etc.) and resets them to default. Other objects are marked as system objects and these cannot be deleted with the default tools, like Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe).

The most pervasive human error in Active Directory administration is the accidental deletion of an important object. A feature in Active Directory Domain Services for Windows Server 2008, called Protect against accidental deletion, when enabled, can save your behind.

While presented as a simple check mark on objects in the common management tools, under the hood, this feature changes the ACLs on the object to prevent it from being deleted. The only way to be able to delete it is by either changing the ACLs or remove the check mark.

Since Organizational Units (OUs) hold other objects, these are the kind of object you’d want to protect, regardlessly. Protection against accidental deletion for Organizational Units is enabled by default when an Active Directory domain is first setup using a Domain Controller with at least Windows Server 2008. Also, be weary of Protection against accidental deletion for Organizational Units when you’re using tools like csvde.exe and ldifde.exe to create Organizational Units.

Deploy Read-only (Server Core) Domain Controllers

In organizations where teams of administrators are divided by geographic boundaries, often problems seem to magically appear due to ineffective communication between the teams. Language barriers may apply, but also the loss of nonverbal communication during digital meetings can hamper conveying sarcasm and cynicism.

In these cases, a team of administrators located at the HQ of the organization (or located at any hub in a typical hub-and-spoke networking environment) might decide to prevent changes in the Active Directory database (and surrounding services) while still maintaining an Active Directory foothold at (spoke) locations and allowing the administrators at the (spoke) location to manage the Windows Server(s), hosting Active Directory Domain Services.

In this scenario, Read-only Domain Controllers can be placed in (spoke) locations, installed with Server Core installations of Windows Server. Read-only Domain Controllers, in this scenario, act a more secure method for deploying Domain controllers and Domain Admins can grant non-administrative domain users the right to log on to them while minimizing the security risk to the Active Directory forest. Server Core installations of Windows Server lack most of the Graphical User Interface (GUI) and administrators using these systems are less prone to click-and-miss errors.

As a Domain Admin, you can configure (Server Core) installations of Windows Server for this type of role separation in the following way:

Log on to the Read-Only Domain Controller as a Domain Admin
Click Start, (click Run,) type cmd, and then press ENTER.
At the command prompt, type dsmgmt.exe, and then press ENTER.
At the DSMGMT prompt, type local roles, and then press ENTER.
For a list of valid parameters, type ?, and then press ENTER.

     Note:
     By default, no local administrator role is defined on the RODC after AD DS
     installation. To add the local administrator role, use the Add parameter.
Type add <DOMAIN>\<user> <administrative role>

For example, type add CONTOSO\testuser administrators

Block changes to Active Directory Domain Services

A more rigorous, but viable solution is to block changes to Active Directory. While you can make administration more process-driven by incorporating Role-based Access Control (RBAC) with a super account and making this account perform actions based on workflows, (System Center Orchestrator and SharePoint Server are Microsoft tools you can use to that purpose) or use a 3rd party management solution like Quest’s ActiveRoles Server and its proprietary management tools , blocking changes to Active Directory is also possible with the native tools, like Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe).

One of the solutions that can limit Active Directory administrators from making changes to specific objects, specific attributes and at specific hours is STEALTHbits StealthINTERCEPT. As part of this solution, a StealthINTERCEPT agent is installed on each of the (R/W) Domain Controllers, that monitors changes to the database on the database level (not the protocol level). When the changes do not adhere to the policies laid out by the Chief Security Officer (CSO), the changes do not get applied, get logged and (optionally) the CSO and his/her auditing department get notified.

Set up Adequate Auditing

Speaking of auditing… Every organization, multi-national or not, should have some sort of mechanism for (external) Active Directory auditing. Whether you’d simply want to track changes to Active Directory (a granular auditing feature found in Domain Controllers running Windows Server 2008 and up), set up a 3rd party auditing infrastructure for the CSO and his/her department, or employ the services of an audit, assurance or governance firm, like PwC and KPMG, depends on the needs and requirements of your organization.

In my opinion, though, no auditing is inadequate auditing. To set up auditing of Active Directory changes, including the ability to see old and new values when changes are made to objects and their attributes, perform the following steps:

First enable the global audit policy. With the Group Policy Management Console (gpmc.msc), right-click Default Domain Controllers Policy, and then click Edit.

Under Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Audit Policy.

In the details pane, right-click Audit directory service access, and then click Properties. Select the Define these policy settings check box. Under Audit these attempts, select the Success, check box, and then click OK.
As the second step, enable the change auditing policy. On each of your Domain Controllers running (Server Core installations of) Windows Server 2008 or up, click Start, right-click Command Prompt, and then click Run as administrator. Type the following command, and then press ENTER:

auditpol /set /subcategory:"directory service changes" /success:enable
Now you’re able to determine the objects and attribute modifications you want to have audited. For instance, when you want changes to the Builtin container audited, right-click it in either Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe), and then click Properties.

Click the Security tab, click Advanced, and then click the Auditing tab. Click Add, and under Enter the object name to select, type Authenticated Users (or any other security principal), and then click OK. In Apply onto, click Descendant User objects (or any other objects). Under Access, select the Successful check box for Write all properties. Click OK until you exit the property sheet for the OU or other object.

Now, when an accidental change occurs on a object or its attributes, the old value and new value are logged as event-IDs 5136 (object modification), 5137 (object creation), 5139 (object move) and 5141 (object deletion) in the Security event log.

Concluding

To have control over an Active Directory environment is to take control over it. By adhering to best practices like the ones above, you can take control and be in charge of the contents within Active Directory. When less of your time is spent like a fireman in your networking environment, you have time to become the dentist and pull out some rotting teeth and fill gaps.

Related blogposts

Common Challenges when Managing AD DS, Part 1: Security
Common Challenges when Managing AD DS, Part 2: Unnecessary Complexity & Token Bloat
Common Challenges when Managing AD DS, Part 3: Performance
Common Challenges when Managing AD DS, Part 4: Attribute Integrity
Active Directory Feature Requirements
PowerShell, LDIFDE, CSVDE and Protection from Accidental Deletion

The Dawn of the BYO Era

At TechEd North America, last week, my feelings towards the importance of attribute integrity grew even stronger. Also, the urgency of having processes in place to guarantee attribute integrity dawned on my.

These two new Windows Server 2012 R2 technologies made me feel attribute integrity is now both important and urgent:

WorkPlace Join

A new feature in Windows Server 2012 R2 is the ability to more loosely couple devices and computers to Active Directory. Next to the exclusive Active Directory domain join, a new join will become available: WorkPlace Join.

This new type of coupling allows for devices to attain a level of trust through a certificate, that allows single sign-on from the device to corporate resources, both on-premises and in the cloud. As an admin you can provide granular access to resources based on whether or not a WorkPlace Joined device is being used or not, whether the users primary device is used on or off the corporate network or whether an untrusted device is used.

I think you can guess where I’m heading with this: the relationships between devices and colleagues is based on object attributes.

Web Application Proxy

The Web Application Proxy allows admins to publish claims to the Internet through a secure proxy for cloud-based applications, partners and vendors. Whenever I read claims, I think of attributes.

The Challenge

When you want to take advantage of these new Bring Your Own (BYO)-inspired Microsoft technologies in Windows Server 2012 R2, attribute inconsistencies will stand in your way of adoption.

When attributes are inconsistent, access to files, apps, partners and cloud functionality becomes inconsistent. If you think it won’t happen to you, think twice. During the first internal Microsoft deployment of Dynamic Access Control, attribute inconsistency was the first encountered problem; in the past a user account was incorrectly changed from a temp to an FTE, resulting in Access-denied situations. You’d think Microsoft, of all companies, knows how to manage Active Directory.

(Part of) The Solution

Unfortunately, no turnkey solution exists to eradicate attribute inconsistency throughout your networking environment. However, the following pieces of action exist to remedy the situation:

Optimizing communication

First of all, your biggest problem is not that attributes for users and devices have become inconsistent, but the way these inconsistencies were (unnecessarily) introduced.

Before you can go and perform a meaningful and long lasting spring cleanup of the data in Active Directory, you will need to have a plan of what the information in Active Directory should look like and how to keep the information up to date. This should be captured in a design and corresponding policies with accompanying management procedures and auditing.

Tip!
Needless to say, this design, the policies and procedures should be kept up to date and thus reviewed regularly

Use a (de)provisioning tool and/or script

Now, part of these procedures for optimizing communication, in some organizations Human Resource (HR) Departments are granted delegated control to create and/or manage objects. These colleagues should be provided with a tool and/or script to perform their management tasks. Whether you opt for a GUI on top of your PowerShell scripts or turnkey solutions like Z-Hire and Z-Term, is up to your needs.

Even if you’re not delegating control, one of the things we can learn from the management approaches for Online Services like Microsoft’s Office 365 is to use a script whenever possible. My rule of thumb has become to perform a repeatable action with a script the third time around.

Perform your attribute spring cleanup

With (naming) policies in place, attribute inconsistencies don’t magically disappear. You will need to actively search for these inconsistencies and solve them. The most straightforward way I know is to make an export from Active Directory with csvde.exe, open the export in Microsoft Excel (Web App) and search for inconsistencies by sorting in columns and/or validating data.

Tip!
If you’re not into Microsoft Excel, you can also use Google Docs to this purpose. Spreadsheets in Google Docs allow for sorting and data validation. On the other hand, you’d probably want to keep the information on your colleagues on-premises instead of in a

After identifying the inconsistencies, target the specific rows (users, devices, groups) and change offending attributes to what they’re supposed to be, with scripts.

Audit attribute integrity

Don’t think, after you’ve performed a spring cleanup of your Active Directory, attributes will be fine for the rest of your career. You should perform regular sample surveys to proactively detect attribute (and thus process and/or policy) inconsistencies. Auditing changes to Active Directory objects might allow you to find offending colleagues who (unintentionally) specify inconsistent attributes.

Blocking and/or workflowing attribute changes

A more complete strategy to prevent attribute inconsistencies is to block or workflow changes to attributes. Solutions like Dell’s ActiveRoles, STEALTHbits’ StealthINTERCEPT might work wonders in your environment to prevent unintentional changes to attributes. Custom solutions based on System Center Orchestrator and/or the Windows WorkFlow Foundation in SharePoint, might also make for a more organization-friendly, but more labor-intensive solution.

Concluding

Attributes integrity is getting more and more important in Identity and Access Management (IAM). When you want to take advantage of new Microsoft technologies, like the new Windows Server 2012 Dynamic Access Control, Office 365 single sign-on, or the BYO solutions in Windows Server 2012 R2, attribute inconsistencies will stand in your way of adoption.

Related blogposts

Common Challenges when Managing AD DS, Part 1: Security
Common Challenges when Managing AD DS, Part 2: Unnecessary Complexity, Token Bloat
Common Challenges when Managing AD DS, Part 3: Performance
Why Active Directory attribute integrity is getting more important (and you should care)

The situation

Microsoft has identified two scenarios where you would get incorrect results:

Situation 1

In the first situation, you would still get Access Denied messages, when you log on to a Domain Controller with UAC enabled and you start (the Active Directory Module for) Windows PowerShell elevated as an administrator (not the built-in administrator account) to open another PowerShell window, after you’ve previously started it directly without promoting it by using administrator privilege.

The screenshot below shows this situation:

Situation 2

In the second situation, you first start (the Active Directory Module for) Windows PowerShell elevated as an administrator and then perform a similar action in a second instance of (the Active Directory Module for) Windows PowerShell that is not elevated. In this case the action would succeed.

The resolution

Workarounds

Several workarounds are available to address the specific issues:

Do not log on interactively to Domain Controllers to perform actions in Active Directory. Instead use the Remote Server Administration Tools.
Do not log on interactively to Domain Controllers but instead use Windows PowerShell from a (Windows 7 or Windows 8-based) management workstation or (Windows Server 2008 R2 or Windows Server 2012-based) management server.

Also, the built-in Administrator account does not encounter the situations above, since User Account Control (UAC) does not apply to the built-in Administrator account (the account with RID 500). All programs will be run with all privileges. While I strongly condemn the interactive use of this account, using it is a workaround for the specific situations mentioned above.

Hotfix

Hotfixes are available to address this issue:

For Windows Server 2012-based Domain Controllers, install the May 2013 update rollup, as described in Microsoft KnowledgeBase article 2836988. You must restart the Domain Controller(s) after you apply this update.

For Windows Server 2008 R2 and Windows Server 2008 R2 with Service Pack 1-based Domain Controllers, install update 2806748. You must restart the Domain Controller(s) after you apply this update.

Related blogposts

New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets

The situation

When you have Windows Server 2012-based Domain Controllers and you add an Organizational Unit (OU) to the Domain Controller, where the name of the OU contains some XML escape characters and you create some user accounts or computer objects in the OU for which you enable the Use Kerberos DES types for this account setting, like in the screenshot below:

Then, when you try to run the AD DS Best Practices Analyzer, it fails with error:

BPA scan did not complete for Active Directory Domain Services on one or more servers.

When you walk through the three notifications in the lower pane, you will find a more detailed error mentioning An error occurred while parsing EntityName.

The cause

This issue occurs because characters in the name of the Organizational Unit (OU) that should be escaped are interpreted incorrectly as XML markup. The characters that cause the problem are:

Quote ( " )
Apostrophe ( ' )
Ampersand ( & )
Less than ( < )
Greater than ( > )

These characters, however, are allowed in the names of Organizational Units, according to Microsoft KnowledgeBase 909264 (Naming conventions in Active Directory for computers, domains, sites and OUs).

The resolution

You can solve the situation of the failed BPA scans in three ways:

Rename Organizational Units that contain objects with the Use Kerberos DES types for this account setting enabled to not contain XML escape characters.
Disable the Use Kerberos DES types for this account setting on objects residing in Organizational Units with names containing XML escape characters.
Install the Hotfix for this specific problem.

Each of these three methods will result in the ability to successfully run Active Directory Domain Services Best Practices scans.

The challenges

Caching the Active Directory Database

Every object in Active Directory takes up space in the Active Directory database (ntds.dit). For performance, the Active Directory databases is cached into RAM by Domain Controllers, since accessing data on Random Access Memory is way faster than accessing data on traditional hard disks and solid state disks. When parts of the Active Directory database are not cached in memory, these parts will be significantly slower compared to parts that are.

Keeping the Active Directory database as small as possible is key to Domain Controller performance, especially on (x86-based 32bit-only) hardware that can no longer be beefed up and on Windows Server installations that don’t support more processors or RAM, like Windows Server Standard Edition in previous versions of Windows Server.

While many large Active Directory databases have grown steadily throughout the years, new functionality might lead to sudden growth. Storing user photos and BitLocker recovery information in Active Directory without proper planning will quickly result in poor Active Directory performance.

Indexing of attributes

Indexing an attribute helps queries find objects that have that attribute more quickly and efficiently than if the attribute had no index. The Active Directory directory service index is built automatically by a background thread on the directory server, instead of being created through a query at the moment you need it (and then have to wait for it).

By default, some attributes in Active Directory are indexed. You can index additional attributes for objects, when you (or your application’s vendor) feel this might improve the performance of queries for the attributes.

(Part of) The solution

Properly plan Domain Controllers

When introducing a Domain Controller to a networking environment, ideally, you should make sure you enable the Domain Controller to make it through its economic lifetime without major problems. In most organizations, this means:

Comply with Best Practices
The Active Directory infrastructure needs to comply with Microsoft’s best practices, since these make you avoid 90% of the situations where data loss might occur. Typical best practices include placing at least two Domain Controllers per Active Directory domain and making regular backups of Domain Controllers. The Active Directory Best Practices Analyzer (AD BPA), available since Windows Server 2008 R2, can help you make your environment compliant.
Properly dimension Domain Controllers
Domain Controllers need to be dimensioned to handle the load for four to seven years (their typical economic lifetimes). This means you need to make sure free disk space is adequate to accommodate the Active Directory database and leave sufficient disk space for online and offline defragmentation.
Install Domain Controllers with supported Windows Server versions
Two Domain Controllers might exhaust your budget, but, economically, avoiding the risk of data loss will aid your business case swing in the right direction. Another argument for making the right choices (like not implementing new Windows Server 2003-based Domain Controllers) is, economically it’s more efficient to only implement the environment once (instead of having to migrate it later on). Procrastinating during the planning phase doesn’t pay off.

These planning thoughts, however, are to no use, when your Active Directory infrastructure is suddenly experiencing a performance impact.

Reducing the size of the Database

Reducing the Active Directory Database size will increase the performance of Active Directory on improperly dimensioned Domain Controllers. Not only does this imply only the necessary objects are created, but also that unnecessary objects are gone from the database. The latter is not as easily achieved as you would think, though.

Creating only necessary objects

Let’s start by only creating necessary objects. Since every object in the database consumes at least 4KB in the Active Directory database size, every object that is reused or relabeled saves 4KB both on disc and in RAM. Every large attribute that is stored as efficiently as possible will prevent database bloat.

Part 1 of this series on stale objects and Part 2 of this series on unnecessary complexity and token bloat are good takes on how to successfully achieve this goal within your organization.

Deleting unnecessary objects

The second part would be to keep only the previously created necessary objects, and toss out the unnecessary objects. The first part would be to identify these objects, then deleting them and then the third part would be to take out the trash.

Identify unnecessary data

Unnecessary data appear in many shapes and forms in Active Directory. They can be user accounts, computer accounts, groups, managed service accounts, fine-grained password policies, Active Directory sites, Active Directory-integrated DNS data and Active Directory replication-related data, like old InvocationIDs.

Most of the data won’t take up much space, unless you’re really putting your Active Directory environments through their backup and restore paces. One of the situations in which a new InvocationID is created is a successful non-authoritative Domain Controller restore. This is not something you should be needing to do on a daily basis…

Delete unnecessary objects

Once you’ve identified unnecessary objects, you can delete them. If you paid attention while reading this blog through the years, you should know by now that deleting in Active Directory does not immediately result in a smaller Active Directory database size. That’s because you need to take out the trash.

Take out the trash

When you delete an object in Active Directory, it becomes tombstoned. With the Active Directory Recycle Bin enabled, items become recyclable for a period of time and then tombstoned. Only after the tombstone lifetime period, the object is deleted from the database.

While this deletion helps the performance of Active Directory in terms of caching the database, it merely creates whitespace (slack) in the database. This whitespace does not result in a diminished size of the database on disk.

To diminish the database size on disk, you will need to offline defragment the Active Directory database as described in Microsoft KnowledgeBase article 232122:

Reboot the Domain Controller, select the appropriate installation from the boot menu, and press F8 to display the Advanced Options menu. Choose Directory Services Restore Mode and press ENTER. Press ENTER again to start the boot process.
Log on using the Administrator account with the password defined for the local Administrator account in the offline SAM.
Open a Command Prompt. At the command prompt, type ntdsutil.exe, and then press ENTER.
Type files, and then press ENTER.
Type info, and then press ENTER. This displays current information about the path and size of the Active Directory database and its log files. Note the path.
Establish a location that has enough drive space for the compacted database to be stored.
Type

     compact to drive:\directory

Where drive and directory is the path to the location you established in the previous step. Then press ENTER.

     Note:
     You must specify a directory path. If the path contains any spaces, the entire
     path must be surrounded by quotation marks. For example, type:

            compact to "c:\new folder"
A new database named Ntds.dit is created in the path you specified.
Type quit, and then press ENTER. Type quit again to return to the command prompt.
If defragmentation succeeds without errors, follow the Ntdsutil.exe on-screen instructions. Delete all the log files in the log directory by typing the following command:

     del drive:\pathToLogFiles \*.log

Copy the new Ntds.dit file over the old Ntds.dit file in the current Active Directory database path that you noted in step 6.

     Note:
     You do not have delete the Edb.chk file.
Restart the computer normally.

Depending on the amount of whitespace (slack) in the database, you will need up to 100% more disk size to perform an offline defragmentation.

Index often-queried attributes

When you identify typical Active Directory actions with poor performance, you might opt to index the queried attribute. An example would be an Active Directory-integrated application that references a specific attribute. In that case, you can speed up the action by marking the attribute as an indexed attribute in the Active Directory schema.

The procedure for this is:

Open the Active Directory Schema snap-in (schmmgmt.msc).
In the left-hand pane, click Attributes.
In the right-hand pane, right-click the attribute that you want to index, and then click Properties.
Click Index this attribute in the Active Directory and click OK to save the change.
Close the Active Directory Schema snap-in.

Your Domain Controllers will now build an index for that attribute.

When you’re using Windows Server 2012-based Domain Controllers, however, you might have enabled Deferred Index Creation. In that case, you might need to perform a UpdateSchemaNow rootDSE mod or reboot your Domain Controllers before they start building the index.

Concluding

Optimal performance of Active Directory is not just the art of throwing sufficient hardware at it. Keeping your Active Directory database tidy may have a significant impact on performance, depending on the amount of RAM in your Domain Controllers, the amount of slack in the database and whether crucial attributes are indexed.

Related blogposts

Domain Controllers: Standard, Enterprise or Datacenter?
New features in AD DS in Windows Server 2012, Part 15: Deferred Index Creation

The challenge

Today, we’ll dive deeper into unnecessary complexity within the Active Directory database on your Domain Controllers. When I talk about unnecessary complexity, I’m mostly referring to a group structure in Active Directory where groups, organizational units (OUs) and access control lists (ACLs) were once used to mimic the structure of the organization and its systems, but where this structure has been circumvented, misunderstood and/or neglected, resulting in duplicate group memberships and improper nesting.

This type of misconfiguration leads to:

Inability to audit (see who has access where, why and since when)
More time needed to resolve common issues like granting or revoking access
More time needed to get acquainted with the environment for new admins
Deviance of Microsoft’s best practices, resulting in a higher risk of data and productivity loss
Token bloat

Of these consequences, token bloat is the most serious.

Token bloat

Active Directory uses Kerberos v5 as one of its authentication protocols, based on RFC 1510. As part of the Kerberos authentication process, a Kerberos token is generated. This access token is created for the user containing all security groups to which they belong. These memberships will be enumerated. The group memberships are used for authorization purposes.

The amount of groups a user belongs to and sIDHistory determine the size of the access token. Since this token has to be transferred over the network and cached in memory, size matters. A smaller access token results in faster logon times and improved system responsiveness. Large access tokens will result in unreliable logon experiences.

As Microsoft has set a maximum to the size of the access token, eventually, users with many group memberships will be unable to log on. The MaxTokenSize is set to 8,00 bytes in Windows 2000 Server pre-SP2 and 12,000 bytes in Windows 2000 Server SP2+, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 and Windows Server 2008 R2, by default. In Windows Server 2012, the default value is set to 48,000 bytes to accommodate for Dynamic Access Control.

(Part of) The solution

In the case of unnecessary complexity, Active Directory should be cleaned up. However, it’s idealistic to think you and your organization can start over, design a new view of your organization and be done with it.

Optimizing communication

First of all, the root of the problem is not the unnecessary complexity, but the way this complexity was (unnecessarily) introduced by admins who were not clear with the procedures to manage objects, grant access and revoke access. Another cause might be an overhaul of the business without Active Directory ever getting remodeled to the new situation.

Tip!
Needless to say, this design, the policies and procedures should be kept up to date and thus reviewed regularly.

Mitigating factors

If you’re running into Token Bloat situations, you can opt to increase the MaxTokenSize, on all your servers and workstations, but this will only fix this problem in the short run. Communication, processes and cleanup will fix your environment in the long run. It might, however, be helpful to perform the following actions:

Upgrade or migrate Domain Controllers running versions of Windows Server before Windows Server 2012. The improved Resource SID Compression feature in Windows Server 2012 helps reduce the size of the access token.
Clear sIDHistory. sIDHistory is a method of retaining old SIDs and thus group memberships for access in Active Directory migration scenarios. As a result, when a user with sIDHistory logs on, the access token will contain both the information for the new Active Directory environment and the old environment.
Limit the number of users that are configured to use trusted for delegation. For accounts that are configured to use "trusted for delegation" the buffer requirements for each SID may double.

Cleanup

With the policy in hand, you can now dig into your Active Directory and clean things up. Naming conventions for groups and accounts can be executed upon and kinks in group memberships can be ironed out.

A couple of solutions exist today to help you with Active Directory inventory and cleanup.

When it comes to group inventory, and especially the effective rights on a NTFS folder gained by group membership, the amount of available tools diminishes fast. STEALTHbits offers a free StealthAUDIT Active Directory Assessment aiming at the above issues, able to report on:

Circular, improper and deep nesting
In Microsoft’s best practices for Active Directory, the AGULP (Account, Global Groups, Universal Groups, Local Groups, Permissions ) principle is used to nest groups into groups. However, when fully anticipating for all Active Directory use cases, token bloat is easily encountered.
Empty groups
A group without members might indicate an unnecessary group.
Direct and effective duplicate group membership
Groups with direct of effective duplicate membership are prime targets to be consolidated. One or more groups can be consolidated based on the outcome to minimize token size and to minimize the possibility of admin adding a group or user to the wrong group.
Stale groups
When a group has a large percentage of members that have been inactive for a period of time, the group may be stale and thus ready for consolidation.
Groups without a description or manager
Documentation within Active Directory to indicate the use of a group is stronger than documentation in an (offline) manual or procedure. Descriptions can be used to identify the right group membership for the right purpose. The Managed by attribute has many uses, both inside and outside Active Directory.
Groups with a large percentage of users
Active Directory comes with built-in groups. These groups can be used to govern access within the environment. Groups with a large percentage of users might indicate the group might better be replaced with one of the built-in groups, like Authenticated Users.

The graphical output looks like this:
(only a portion of the Toxic Group Conditions report is shown below)

Unfortunately, the free StealthAUDIT Active Directory Assessment does not offer the much coveted effective rights report, showing who has access where (on File Servers, in Exchange) based on Active Directory group memberships and Dynamic Access Control. When you want this functionality, StealthAUDIT Data & Access Governance is the suite you might want. The free StealthAUDIT Active Directory Assessment, however, will give you a fair preview of what you might expect from the full platform.

An alternative solution

As an alternative to using group memberships as your access management strategy, you might opt to implement Dynamic Access Control (DAC). This new feature in Active Directory Domain Services in Windows Server 2012 offers a way to manage access to files and folders, based on attributes in Active Directory (fields like location, manager and department) and (optionally) file classification. No longer will you need to create thousands of groups to build a granular access solution. As a bonus, you can create far more robust access rules.

In contrast to group memberships, in Dynamic Access Control scenarios, access is granted based on attribute values. These attribute values result in claims. These claims are then used for authorization purposes, where filtering is done based on the combination of claims.

To migrate to an environment where authorization is based on claims instead of group memberships, the two authorization methods, most likely, need to coexist for a while. To remediate Token Bloat in this situation, increasing the MaxTokenSize throughout your environment is a good temporary fix.

Concluding

Only after you’ve created a policy and processes within the organization will you, your admins and your auditors, be able to model your Active Directory environment to your organization and enjoy easy Identity and Access Management…

Related blogposts

Common Challenges when Managing Active Directory Domain Services, Part 1: Security
New features in AD DS in Windows Server 2012, Part 20: Dynamic Access Control (DAC)
New features in AD DS in Windows Server 2012, Part 21: Resource SID Compression
How to search for groups of different type and scope
Groups and tokens

The challenge

Today, I want to talk to you about stale user objects and stale computer objects. From a security point of view, these objects represent a real security risk to your organization.

Stale user objects

Depending on the process surrounding creating user objects, these objects are usually created with a predefined password. This makes the tasks of creating an account and communicating the account to the actual colleague two separate tasks, that can be carried out by two different persons at two different times.

Alas, the delegation of work does not outweigh the security risk involved with tens, hundreds or even thousands of user objects that can be brute forced for their password , most of the time configured with a default password for new accounts (Welcome123 and P@ssw0rd come to mind). Tools like Zohno’s free Z-Hire, I discussed last year, have the explicit option to provide a default password (but not generating one) per template.

One of the other factors that don’t help in the situation with stale user objects is that account lockout settings are non-existent in default Active Directory implementations.

Stale computer objects

Stale computer objects are even worse than stale user objects from a security point of view. By default computer accounts have broader access to information in Active Directory and by default, the password for the security channel used to be a default derivation of the hostname as explained in Microsoft KnowledgeBase article 255042 on How to make machine accounts programmatically by using ADSI with Visual C++:

The initial password for the machine account must be set to the name of the computer in lower case.

Using net use from a non-domain joined computer using the computer account (the NetBIOS hostname) and the default password for the computer account, a malicious person might gain access to data in Active Directory, on file servers and in Exchange public folders, as explained by Marcus Murray in his Live demonstration about some of the ways hackers attack [PDF] on page 11.

Luckily, by default a domain-joined computer will change its computer password at a regular interval. This means, the security concerns surrounding stale computer objects only apply to the first week or month of the lifecycle of the computer object, depending on the Operating System of the domain-joined machine:

Windows 9x, Windows NT4, Windows 2000	7 days
Windows XP, Windows Vista, Windows 7, Windows 8	30 days

A more permanent solution to the problem was introduced with Windows 7 with Offline Domain Join. Not only does this Active Directory Domain Services-related feature offer the ability to join a computer to an Active Directory domain without a networking connection between a Domain Controller and the computer to be joined. Its communication streamlining also applies to every domain join, as I covered earlier in my blog post on the Top 5 Myths on Offline Domain Join.

(Part of) The solution

A lot of times, the root cause of stale objects in Active Directory is the lack of (procedures for the) interaction between an HR department (who known who were hired and fired), a facilities department (who knows where computers are located) and the IT department (who need to make these changes to keep Active Directory up to date).

Optimizing communication

Optimizing communication between the HR, facilities and IT departments should be your main focus when trying to solve the situations surrounding stale user objects and computer objects. A process-based approach would best suit tackling this.

Mitigating factors

Processes will save you in the long run, but as an Active Directory admin, there’s also a couple of things you can do right now. You can take action to prevent most of the security breaches, by:

configuring Account lockout policies in Active Directory
configuring new user objects with randomly generated complex passwords
migrating client computers to Windows 7 and/or Windows 8

Cleanup

With the long term covered with processes and the biggest security problems tackled, the only task left is the perform a cleanup in the Active Directory database.

You might want to get rid of:

Computer objects that have not been used to log onto in the last 30 days
User objects that have not been used to (interactively) log on ever
User objects that have not been used to (interactively) log on in the last 30 days.

Cleaning stale computer objects

To detect stale computer objects, Microsoft has released a script as part of Knowledgebase Article 197478 that, under the hood, uses nltest.exe to check the PasswordLastSet output. Several PowerShell scripts exist that check the PwdLastSet (script) or lastLogonTimestamp (script) attributes directly in the Active Directory database. Joe Richards’ command-line tool oldcmp.exe is one of the leanest tools available to tackle the problem, while many other 3rd party solutions offer the functionality as part of a more elaborate reporting solution.

Many of these Active Directory reporting solutions will set you back a fair amount of budget, but STEALTHbits’ free StealthAUDIT Active Directory Assessment will both report on stale objects in bar graphs and will output its findings in XML-based files, ready for your PowerShell scripts. Since StealthAUDIT uses its own Microsoft SQL Server database, the load on your Domain Controllers when being examined remains minimal.

When you use these tools, you might find a surprising list of computers that have been identified as stale, but purring away peacefully as part of every day operations… This situation can be caused by settings that disable computer account password resets. Always browse through the list with inactive computer objects, before accidentally deleting active computer objects.

Tip!
Protection from Accidental Deletion on individual computer objects might help preserving often targeted computer objects

Tip!
Before performing any cleanup actions, would be an excellent moment to enable the Active Directory Recycle Bin.

Cleaning stale user objects

Stale user objects can be targeted with much of the same 3rd party tools. Again, a load of scripts can be used to find (and remove) unnecessarily created user objects.

When running Windows Server 2012 and Windows Server 2008 R2-based Domain Controllers you can also use the Global Search functionality in Active Directory Administrative Center (dsac.exe). The Global Search option has a couple of helpful default criteria, that help you identify dangerous user objects. Below is a view on the criteria in the Windows Server 2012 Active Directory Administrative Center:

Obviously, the stale user objects that have the most potential to be used to wreck your environment would be:

enabled user objects
user objects without a password expiration date
user objects that have not been used to log on for more than 30 days.

Clicking on the Search button, would return a list with objects that need the attention of an Active Directory admin. Now, the list should not be considered as input to a script, since several reasons exist why user objects appear as stale, but still need to be retained:

User objects belonging to colleagues on maternity leave, sabbatical, etc.
User objects belonging to services that don’t log on interactively

From the list in the Active Directory Administrative Center you can easily pick the user objects you want to delete and disarming them by either right-clicking the selection and select Delete or Disable all from the context menu or pressing the Del button on your keyboard.

Concluding

Stale objects in Active Directory pose a significant security risk. You can address these risks by introducing processes to control the lifecycle of objects in Active Directory. Additionally, you can take actions to clean up your Active Directory.

Related blogposts

Tip: Zohno’s Z-Hire & Z-Term (freeware)
Top 5 Myths on Offline Domain Join

Related blogposts

Active Directory Domain Services Management Pack for System Center updated last week
System Center Monitoring Pack for Active Directory was updated today

Related downloads

System Center Management Pack for Windows Server Operating System
System Center Management Pack for Windows 8 Client Operating System

Posted: Monday, May 13, 2013 8:06 AM by Sander Berkouwer | 0 Comments

Filed under: Active Directory, Microsoft Windows Server 2008, Microsoft Windows Server 2008 R2, Microsoft Windows Server 2012, System Center, Microsoft Windows Server 2003

Active Directory Services and PowerShell manageability

As you might be aware, every Microsoft server product has the requirement to be manageable through PowerShell and System Center. The PowerShell requirement is formulated as part of the Common Engineering Criteria (CEC).

With PowerShell available as a version 3 product (and part of Windows Server 2012) it’s time to see how the teams, responsible for the Active Directory products have built their management stories around PowerShell.

Active Directory Domain Services

The Active Directory Domain Services, that we love and loath as the core of our networking infrastructure on our Domain Controllers is manageable through PowerShell scripting. To enjoy PowerShell support in Active Directory Domain Services, it is recommended to manage your Domain Controllers from Windows Server 2012 or from a Windows 8 installation with the Remote Server Administration Tools (RSAT) for Active Directory installed. This way you can enjoy the 135 Active Directory Domain Services management-related PowerShell Cmdlets and 9 Active Directory Domain Services deployment-related PowerShell Cmdlets.

The Active Directory Domain Services team even went a few steps further and incorporated the PowerShell History viewer into the Active Directory Administrative Center (dsac.exe), that helps you discover the PowerShell magic that happens under the hood.

A couple of exceptions still exist, that make it impossible to manage Active Directory Domain Services from the PowerShell prompt completely. Tools like ntdsutil.exe, dsamain.exe, redirusr.exe and redircmp.exe come to mind, almost immediately. On the other end of the spectrum, several other functions in Active Directory Domain Services are only easily manageable with PowerShell. MSAs come to mind, quite to my own surprise...

Active Directory Lightweight Domain Services

The Active Directory Lightweight Domain Services offer specialized Domain Services, targeted at applications and perimeter networks. Their charm is you can manage the Lightweight Directory Services (mostly) with the same tools as you can manage the Directory Services in PowerShell (as long as you install the AD LDS Display Specifiers schema and Display Specifiers by importing MS-ADLDS-DisplaySpecifiers.ldf.).

Alas, the PowerShell learning ability, offered by the Active Directory Administrative Center (dsac.exe), is not available for Active Directory Lightweight Directory Services, since this management tool can not be directed to a Lightweight Directory Services installation.

Since most tools are exchangeable between Lightweight Directory Services and Directory Services, roughly the same exceptions for full PowerShell manageability exist.

Active Directory Certificate Services

Active Directory Certificate Services enable you to run Certification Authorities on Windows Servers. For Windows Server 2012, the team behind Active Directory Certificate Services has developed twelve PowerShell Cmdlets to deploy Certificate Services. Also an additional nine PowerShell Cmdlets were specifically created to manage certificates, but you can also manage these by mounting the Certificate Store as a PowerShell drive, if need be.

In versions of Windows Server earlier than Windows Server 2012, no built-in PowerShell Cmdlets were available to manage Active Directory Certificate Services, but you could rely on certutil.exe to script through them.

Active Directory Federation Services

As was the case with Active Directory Federation Services 2.0, which was a separately downloadable installation, Active Directory Federation Services 2.1, that comes bundled with Windows Server 2012, can be managed through PowerShell. A total of 48 Active Directory Federation Services-related PowerShell Cmdlets are available on Windows Server 2012, covering both deployment and management.

Active Directory Rights Management Services

As you might expect, the Active Directory Rights Management Services in Windows Server 2008 R2 and Windows Server 2012 are also PowerShell-enabled. Three straightforward Rights Management Services deployment-focused PowerShell Cmdlets (appropriately named Install-ADRMS, Uninstall-ADRMS and Update-ADRMS) and 21 Rights Management Services administration-focused PowerShell Cmdlets are at your disposal.

Related blogposts

New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets
New features in AD DS in Windows Server 2012, Part 5: PowerShell History Viewer

	Official website http://europe.msteched.com
	Blog http://channel9.msdn.com/Blogs/TechEd
	Twitter http://www.twitter.com/TechEd_Europe and tags #msteched and #TEE13
	Facebook http://www.facebook.com/TechEdEurope
	LinkedIn http://www.linkedin.com/groups/Microsoft-TechEd-Europe-1055617

	The Cloud OS: It’s Time! Brad Anderson June 25, 2013 from 9:00AM to 10:30AM GMT +1 (Brussels, Copenhagen, Paris, Madrid) Brad Anderson will review a broad set of newly-announced updates across the full suite of Microsoft Cloud OS products and technologies.
	Windows is the Future Jon DeVaan June 27, 2013 from 8:30AM to 9:45AM GMT +1 (Brussels, Copenhagen, Paris, Madrid) In this keynote, Jon DeVaan, Corporate Vice President, Windows, will discuss a broad set of new features for Windows 8.1.

Related

Blog roll

News

Recent Posts

Tags

Navigation

Top posts in the past

Whitepapers

Archives

The challenge

(Parts of) The Solution

Apply the Principle of Least Administrative Privilege

Use the Best Practices Analyzer (regularly)

Protect important objects against accidental deletion

Deploy Read-only (Server Core) Domain Controllers

Block changes to Active Directory Domain Services

Set up Adequate Auditing

Concluding

Related blogposts

Further reading

About attribute integrity

The Dawn of the BYO Era

WorkPlace Join

Web Application Proxy

The Challenge

(Part of) The Solution

Optimizing communication

Use a (de)provisioning tool and/or script

Perform your attribute spring cleanup

Audit attribute integrity

Blocking and/or workflowing attribute changes

Concluding

Related blogposts

Further reading

The situation

Situation 1

Situation 2

The resolution

Workarounds

Hotfix

Related KnowledgeBase articles

Related blogposts

Further reading

About the AD DS BPA

The situation

The cause

The resolution

Related KnowledgeBase articles

Further reading

The challenges

Caching the Active Directory Database

Indexing of attributes

(Part of) The solution

Properly plan Domain Controllers

Reducing the size of the Database

Creating only necessary objects

Deleting unnecessary objects

Identify unnecessary data

Delete unnecessary objects

Take out the trash

Index often-queried attributes

Concluding

Related blogposts

Related KnowledgeBase articles

Further reading

The challenge

Token bloat

(Part of) The solution

Optimizing communication

Mitigating factors

Cleanup

An alternative solution

Concluding

Related blogposts

Further reading

The challenge

Stale user objects

Stale computer objects

(Part of) The solution

Optimizing communication