ADSI Edit: How to View and Change Active Directory Object Properties?

8.5K

In this tutorial we will show you how to manage Active Directory with ADSI Edit MMC snap-in: learn to edit attributes, reset user passwords, run queries, and troubleshoot common ADSIEdit errors.

What is ADSI Edit?

ADSIEdit.msc is a graphical MMC snap-in used as a low-level Active Directory (LDAP) editor. It allows you to directly access to folder objects and attributes without the safety checks that are present in standard tools (like ADUC/ADAC).

Note that ADSI Edit is a powerful tool. It allows you to directly modify the AD data at the LDAP level. However, it is also a potentially dangerous tool. Unlike most of the admin tools, ADSI Edit does not provide validation, warnings, and there is no way to revert the changes. In case you make incorrect changes, it can result in:

• irreversible object/attribute corruption
• replication problems across DCs
• authentication/service failures

Always check that you have a backup or test environment before using the tool.

Important! You should consider ADSI Edit as a last-resort utility.

Use it only when:

• Required attribute is not available in ADUC/ADAC
• You can’t perform the changes using PowerShell cmdlets

In most cases, you should use higher-level tools (that include validation and safety checks).

How to Install ADSIEdit on Windows

The ADSI Edit snap-in can be installed from the RSAT package on both Windows Server hosts and Windows 10 or 11 desktop editions.

Install ADSI Edit on Windows Server (GUI and PowerShell)

ADSI Edit is included with the Active Directory Domain Services and Lightweight Directory Services management tools on supported Windows Server versions, including Windows Server 2025.

• From the Server manager GUI: Add roles and Features > Features > Remote Server Administration Tools > AD DS Tools > AD DS Snap-Ins and Command-Line Tools > Install
  

  

• Now install the AD DS management snap-ins using PowerShell:
  

  Install-WindowsFeature -Name RSAT-ADDS-SnapIns

Install ADSI Edit on Windows 11 (RSAT tools)

If you want to use ADSI Edit console from Windows 11, install it:

• Via the GUI: Settings > Apps > Optional features > Add a feature > check RSAT: Active Directory Domain Services and Lightweight Directory Services Tools > Install

  

• Or add the ADDS tools using PowerShell:
  

  Add-WindowsCapability -online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"

Launching ADSI Edit console

Now you can run ADSI Edit by using the adsiedit.msc command or from Control Panel\System and Security\Administrative Tools.

Connecting to Active Directory with ADSI Edit

The first time you start the ADSI console, you will need to connect to the AD DS/LDS instance.

Default naming context

Important! In AD, naming contexts (also called directory partitions) are separate logical sections of the directory database. Each partition has its own scope and replication behavior. When you connect to a specific naming context in ADSI Edit, you are working directly with that part of the directory.

Note that changes that you’ve made in some partitions (like Configuration, Schema, etc.) affect the entire forest.

Right-click on the root in the ADSI Edit and select Connect to. The LDAP Distinguished Name or Naming Context can be specified manually or selected from one of the known naming contexts:

• Default naming context. This is a domain partition which contains objects (such as users, groups, computers, and OUs). Changes affect only the current domain.
• Configuration. This is a forest-wide partition that stores AD topology, sites, services, and replication settings. Note that changes made here affect all domains in the forest.
• Schema. It’s a forest-wide partition that defines all object classes and attributes in AD. Changes are replicated to all DCs and are generally irreversible. Keep in mind that Schema modifications cannot normally be rolled back. Even in case an attribute/class is later disabled, the schema version change remains replicated throughout the entire forest.
• RootDSE is a special read-only entry. It provides information about the directory service and available naming contexts.

Warning. Keep in mind that modifying objects in the Schema partition is highly sensitive. In case you’ll make incorrect changes, it can permanently affect the entire AD forest (and you won’t be able to easily roll it back).

We recommend using this tool to perform schema modifications only in case you are experienced admin.

Note. In case you connect through a Global Catalog server (ports 3268/3269), not all object attributes are available because the GC stores only the Partial Attribute Set (PAS).

Using SSL-based LDAPS connection

To use the encrypted LDAPS protocol to connect to the domain controller, select the Use SSL-based encryption option.

In most cases, the Default naming context is used. The ADSI Edit console will connect to the specified directory partition and will display all the Active Directory OUs in a hierarchical tree view (is similar to the AD view in the ADUC console).

Navigating the AD hierarchy

Navigate the AD hierarchy using the ADSI console. Click on any OU. In the right pane of ADSIEdit you will see a list of items that this OU contains (including User, Computer, Group, OU, Contact, and other object classes). Note that instead of the object name, ADSI Edit displays the object’s CN (Common Name) and DN (Distinguished Name).

• CN (Common Name) is the object name within its container
• DN (Distinguished Name) is the full LDAP path to the object (e.g., CN=User1,OU=Users,DC=domain,DC=com)

Right-click on any AD object to see a list of available actions. For example, for the User object, in addition to the typical operations with an AD object (Move, New, Delete, Rename), you can reset the Active Directory user’s password.

Viewing Deleted Objects Container

You can also use ADSI Edit to inspect the Deleted Objects container when the AD Recycle Bin feature is enabled. This can be useful when you troubleshooting accidental deletions and in object recovery cases.

Using Attribute Editor in ADSIEdit.msc

There is a built-in AD object attribute editor in the ADSIEdit snap-in, which allows you to view or modify any object attribute value. The Attribute Editor tab is available in the properties of each AD object.

Attribute filter options

By default, both filled and empty (<not set>) attributes are displayed. You can show or hide some attributes using the Filter options:

• Show only attributes that have values
• Show only writable attributes — show only attributes that the current user has permission to change
• Show mandatory attributes;
• Show optional attributes;
• Show read-only attributes (Constructed, Backlinks, or System-only).

To change the attribute value, double-click (or press Edit) and set a new value. Note that attribute values have different data types (string, integer, DN, multi-valued, binary). In case you enter an incorrect value or use an incorrect format, it can break the object functionality or cause replication problems.

Note that changes you are performing through ADSI Edit are written directly to the DC you are connected to. Depending on AD replication topology, it may take time before the changes become visible on other DCs.

You can verify replication health with the command:

repadmin /replsummary

And here is the command to check object replication metadata:

Get-ADReplicationAttributeMetadata `
    -Object "CN=User1,OU=Users,DC=contoso,DC=com" `
    -Server DC01

Editing ms-DS-MachineAccountQuota attribute

ADSI Edit allows you to change AD settings that cannot be configured in any other way. By default, any authenticated domain user can join up to 10 machines to the domain. You can manage this behavior using the ms-DS-MachineAccountQuota attribute.

Security note

In case you allow regular users to join machines to the domain, it may lead to:

• unauthorized devices being joined to the domain
• attacker persistence through domain-joined machines
• uncontrolled growth of computer objects in Active Directory

In protected environments, this value is often set to 0. This prevents non-privileged users from joining devices to the domain.

In case you set ms-DS-MachineAccountQuota to 0, we recommend you to check that:

• only authorized users/groups have permissions to join machines to the domain
• delegated rights are configured using Group Policy/domain permissions

Keep in mind This attribute is located in the domain root object and affects the entire domain.

You should set MachineAccountQuota to 0 unless there is a documented business requirement for allowing standard users to join machines to the domain (this is recommended by many security baselines and AD hardening guides).

ADSI Edit is also commonly used for troubleshooting Windows LAPS deployments because it allows you to verify whether LAPS-related attributes are present on computer objects and if permissions are delegated correctly.

Note. For bulk attribute modifications, we recommend you to use ldifde or PowerShell instead. ADSI Edit is best suited for single-object changes.

Note on protected accounts. Keep in mind that changes to permissions on protected accounts and groups (such as Domain Admins) may be overwritten by the AdminSDHolder process.

Troubleshooting ADSI Edit Issues

When you try to edit the attribute values of some AD objects, you may receive an error:

There is no editor registered to handle this attribute type.

“No editor registered” error explained

This error occurs when ADSI Edit does not have a built-in editor for the attribute’s data type (syntax).

Some AD attributes use complex formats that cannot be edited via the ADSI Edit GUI (such as multi-valued, binary, or structured data). In such cases, you can’t modify the value because ADSI Edit cannot render appropriate UI control. Note that this limitation is not specific to Exchange/Entra ID (although such environments often introduce additional complex attributes).

When “No editor registered” error occurs, you should use PowerShell cmdlets (such as Set-ADObject or Set-ADUser) in order to modify the attribute. PowerShell console allows you to work directly with attribute values regardless of their syntax. It provides you with more control over complex/multi-valued attributes.

Fixing attribute editing errors with PowerShell

In case ADSI Edit cannot edit an attribute, you can use the Active Directory PowerShell module instead. For example, the following command replaces the value of the description attribute:

Set-ADObject `
-Identity "CN=GroupName,OU=Groups,DC=domain,DC=com" `
-Replace @{description = "Updated group description"}

The -Replace parameter accepts a hashtable in which the key is the LDAP display name of the attribute and the value is the new attribute value.

Searching Active Directory with ADSI Edit

The ADSI Edit snap-in allows you to search for AD objects using various criteria.

1. Right-click on the default naming context and select New > Query;

   

2. Enter the query name, select the search scope, and specify the LDAP query code manually or generate it using the wizard (Edit Query button). In this example, we are looking for AD users named David:
   (&(objectCategory=user)(objectClass=user)(givenName=david*))
   
   This query can be broken down as follows:
   (&
   (objectCategory=user) → only user objects
   (objectClass=user) → ensures the object is of user class
   (givenName=david*) → first name starts with “david”
   )
   In other words, this query returns all user objects whose given name begins with “david”.

   

3. Save the query;
4. The ADSI console will display a list of AD objects that match your LDAP query.

   

You can also search for Disabled users using command:

(&(objectCategory=user)
(userAccountControl:1.2.840.113556.1.4.803:=2))

Search for computers that have never updated the lastLogonTimestamp attribute:

(&(objectCategory=computer)
(!(lastLogonTimestamp=*)))

The exact LDAP filter for inactive machines depends on the inactivity threshold. It requires comparison against a calculated lastLogonTimestamp value.

Note.

• objectCategory is indexed and more efficient for filtering
• objectClass may include multiple inherited classes

Wrapping up

ADSI Edit is a powerful but dangerous tool. You should always prefer higher-level tools (ADUC, ADAC, PowerShell) when possible. Use ADSI Edit only when:

• The attribute is not accessible in standard tools
• PowerShell cmdlets do not support the operation

Key safety rules

1. Always have an AD backup before making changes
2. Avoid modifying Schema/Configuration partitions unless it’s absolutely necessary
3. If you encounter a “No editor registered” error, you need to switch to PowerShell