Common Challenges when Managing Active Directory Domain Services, Part 1: Security

In many organizations Active Directory Domain Services is the top tier in access management. Access to systems, information and connections, often, is governed by information in Active Directory. User objects and computer objects play a big role in this model, since they represent actual physical objects within the organization.

Now, not every organization acknowledges the importance of an up to date and lean Active Directory environment. In this series, I will show you four of the key challenges involved with managing Active Directory for any organization and how to solve them.

This series will focus most on the data inside the Active Directory database, instead of the actual technical implementation of Domain Controllers and such.


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


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.

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

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:

Criteria when using Global Search when using the Active Directory Administrative Center in Windows Server 2012 (click for larger screenshot)

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.



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 Microsoft Knowledgebase articles

154501 How to disable automatic machine account password changes
255042 How to make machine accounts programmatically by using ADSI with Visual C++
197478 How to detect and remove inactive machine accounts

Further reading

SIA338: Authentication & Passwords, The Good, The Bad & The Really Ugly
Active Directory Recycle Bin Step-by-Step Guide
What's New in AD DS: Active Directory Administrative Center
Using Active Directory Administrative Center in Windows Server 2008 R2
Finding Stale Accounts in Active Directory
Active Directory: How to identify inactive computer accounts
Detecting and Removing Stale Computer Accounts in Active Directory
Active Directory True Last Logon

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.