All objects (classes) of Active Directory have a predefined set of attributes (properties). For example, the AD user class has the attributes Name, Surname, City, Office, OfficePhone, and so on. You can store user options in existing attributes, use the special extensionAttribute1-15, or create a new attribute.
In this article, we’ll look at how to add a new attribute (for example, vehRegCode) to a user in on-prem Active Directory.
Important Notes
- Schema change affects the entire AD forest;
- Schema extensions are effectively permanent. Although custom attributes cannot normally be deleted from the schema, they can be marked as defunct and removed from active use;
- Before changing the schema, back up Active Directory.
- Test schema extensions in a lab/isolated AD forest before implementing them in production;
- To change the schema, you need to have schema admin privileges. Add your account to the Schema Admins group.
Note that after adding your account to the Schema Admins group, you need to sign out and sign in again (or obtain a new logon token) before attempting schema modifications.

Configuring Active Directory class attributes
The Active Directory Schema snap-in is not visible in the standard Administrative Tools by default. You must manually register the library and add it to a management console.
Active Directory class attributes are configured in the AD schema. You should use the Schema Manager snap-in to edit the Active Directory schema. To register the Schema DLL, perform the command:
regsvr32 schmmgmt.dll
After registering a snap-in:
- Open a new MMC Console (mmc.exe)
- Click File > Add/Remove Snap-in;
- Add the Active Directory Schema snap-in and click OK.

Schema modifications can only be performed on the domain controller holding the Schema master FSMO role. Connect to a DC that owns this role.
Expand Active Directory Schema, right-click Attributes, and select Create Attribute.
You will be warned that changing the AD schema is a permanent operation.

Fill in parameters of new attribute
In the opened form, you need to fill in the parameters of the new attribute:
- Common Name โ attribute name (must not contain spaces).
- LDAP Display Name โ this value is automatically populated after the CN is determined, but you can change it. The LDAP display name must be unique within the Active Directory schema. When an object is referenced in a script, it must be called using the LDAP display name instead of the CN.
- X500 Object ID (OID) โ unique attribute ID in the AD schema. Use the below PowerShell script to generate this parameter value.
- Syntax โ attribute type (Boolean, Unicode String, Numeric String, Integer, Large Integer, SID, Distinguished Name, etc.). Depending on the selected value in the Syntax field, you need to fill in other values. In our example, this will be a regular Unicode String with a maximum length of 10 characters.
PowerShell script to generate X500 Object ID
Important. Every custom schema attribute must have a globally unique OID. Never reuse OIDs from other organizations or published examples.
# Define the base Microsoft OID prefix for private extensions
$Prefix="1.2.840.113556.1.8000.2554" # Generate a new GUID and convert to string
$GUID=[System.Guid]::NewGuid().ToString() $Parts=@() # Parse the GUID into segments to create the OID suffix
$Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier") $Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier") # Format the final OID string
$OID=[String]::Format("{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}",$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6]) # Output the result
$oid

Complete all fields in the Create New Attribute form and click OK.

After creating a new schema attribute, you should allow time for schema replication across DCs. Depending on the environment, the new attribute may not appear immediately in ADUC/PowerShell.
Add new attribute to user class
Now we need to add a new attribute to the user class:
- Expand the Classes container, find the user class, open its properties and go to the Attributes tab;
- Click the Add button and select the attribute you created earlier from the list.

Now run the Active Directory Users and Computers snap-in (dsa.msc), open the properties for any user, and verify if the Attribute Editor tab now displays the new attribute. You can change its value.

Keep in mind that if the attribute must be available through Global Catalog searches, you need to enable the Replicate this attribute to the Global Catalog option in the attribute properties.
If the attribute will be frequently used in LDAP searches, you should consider enabling indexing in the schema. Indexing should be planned carefully because it affects replication and database size.
Get value of new attribute using PowerShell
To get the value of a new attribute using PowerShell, use the command:
Get-ADUser -Identity bjackson -properties vehRegCode|select name, vehRegCode
To set the value of a new user attribute for the first time:
Set-ADUser a.novak -Add @{vehRegCode = "3265JA"} In case the attribute already contains a value, you need to use the -Replace parameter in order to update it:
Set-ADUser a.novak -Replace @{vehRegCode = "3265JA"} What is a custom attribute in Active Directory?
A custom attribute is a schema extension that allows you to store additional information not covered by the default Active Directory attributes. For example, you might create a custom attribute such as vehRegCode to store vehicle registration codes for users.
Should I create a custom attribute or use an existing one?
Before extending the schema, consider whether an existing attribute or one of the built-in extensionAttribute1โ15 fields can meet your requirements. Creating a new schema attribute should generally be reserved for cases where no suitable existing attribute is available.
What permissions are required to create custom Active Directory attributes?
You must be a member of the Schema Admins group to modify the Active Directory schema.
After being added to the group, you must sign out and sign back in (or obtain a new logon token) before performing schema changes.
Do schema changes affect only one domain?
No. Active Directory schema changes affect the entire forest, not just a single domain. Any custom attribute added to the schema becomes available throughout the forest after replication completes.
Can a custom Active Directory attribute be deleted?
Generally, no. Schema extensions are effectively permanent. Custom attributes cannot normally be deleted from the schema, although they can be marked as defunct and removed from active use.
