How to Create Custom Protected Attribute in Active Directory

What is an Active Directory Schema Attribute?

The Active Directory (AD) schema is the blueprint that defines the structure of data stored in AD. It specifies which object classes (e.g., user, group, computer) and attributes are available, as well as the data types of these attributes.

An attribute is a piece of data associated with an AD object. For example:

  • sAMAccountName → The user's logon name

  • mail → The user's email address

What is a Custom Attribute?

A custom attribute is a new attribute added to the AD schema to meet specific organizational needs that are not covered by the default schema. For instance:

  • Employee ID numbers

  • Department-specific codes

  • License assignment status for users

  • A mobile phone number that needs to remain confidential

Why Create Custom Attributes?

Custom attributes are created for the following reasons:

  1. Business Requirements: To store information that is necessary for business processes but not available in the default schema.

  2. Integration: To adapt AD for integration with custom applications or third-party systems (e.g., an HR system).

  3. Reporting and Management: To enable more detailed reporting or to track specific data for users, groups, or computers.

  4. Advanced Automation: When automating tasks with tools like PowerShell, custom attributes provide additional flexibility.

Requirements for Creating Custom Attributes

Creating custom attributes involves certain prerequisites and considerations:

  1. Schema Admin Permissions:

    • Only members of the Schema Admins group can make changes to the AD schema.

  2. Planning and Testing:

    • Schema changes are permanent and irreversible, so careful planning and testing in a non-production environment are essential.

  3. Global Impact:

    • Changes to the schema are applied across the entire forest and are shared by all domains within it.

  4. Appropriate Data Type:

    • You must choose the correct data type for the custom attribute (e.g., String, Integer, Boolean).

  5. Naming Conflicts:

    • Custom attribute names must not conflict with existing schema attributes.

  6. Replication Considerations:

    • New attributes increase the replication load on domain controllers, so only necessary attributes should be added.

How to Create a Custom Attribute via Management Console

  1. Enable Schema Management:

    • Use the command regsvr32 schmmgmt.dll to enable the schema management snap-in on your system.

  2. Add Attribute via MMC:

    • Open the Active Directory Schema snap-in in Microsoft Management Console (MMC) and define the new attribute.

  3. Link Attribute to Object Class:

    • Assign the newly created attribute to an object class (e.g., user, group).

  4. Test and Replicate:

    • Once the attribute is replicated across domain controllers, test it to ensure it works as expected.

Example Use Case

A company needs to track the project assignment date for users. To achieve this:

  1. Create a custom attribute called projectStartDate.

  2. Set the data type to Date.

  3. Add this attribute to the user object class.

Once added, tools like PowerShell or LDAP queries can manage and report on this new attribute.

Note: Schema changes affect the entire AD forest and cannot be undone. Always implement changes in a test environment first to avoid potential production issues.

What is a Protected Attribute in Active Directory?

A protected attribute in Active Directory is an attribute whose access is tightly controlled to ensure the security and integrity of sensitive data. These attributes often contain critical or sensitive information, such as passwords or security identifiers, that must be protected from unauthorized access or modification.

Protected attributes are typically governed by Access Control Lists (ACLs), which define who can read, write, or modify these attributes. Only highly privileged accounts, such as Domain Admins, Enterprise Admins, or system accounts like the Local System, are granted access to protected attributes.

Examples of Protected Attributes

Some common protected attributes include:

  1. unicodePwd

    • Stores the user's password in an encrypted format.

    • Only writable by system processes (e.g., during password resets); it is not readable even by administrators.

  2. userAccountControl

    • Manages account flags like enabling/disabling accounts, requiring passwords, etc.

    • Modification requires specific privileges.

  3. msDS-PasswordSettings

    • Used in Fine-Grained Password Policies to store password policy settings.

    • Protected to ensure unauthorized changes do not weaken security.

  4. dBCSPwd (legacy attribute)

    • Historically stored LM hash values of passwords.

    • Now deprecated but remains highly protected.

Why Are Attributes Protected?

Protected attributes exist to:

  1. Ensure Security: Prevent unauthorized users from accessing or tampering with sensitive data like passwords or account configurations.

  2. Maintain Data Integrity: Protect critical configurations to avoid accidental or malicious changes that could disrupt services.

  3. Comply with Regulations: Organizations must adhere to compliance frameworks like GDPR, HIPAA, etc., that require securing sensitive information.

How Are Protected Attributes Controlled?

  1. Access Control Lists (ACLs):

    • Define which users or groups have permission to read, write, or modify an attribute.

    • Example: By default, only Domain Admins or Enterprise Admins have write access to the userAccountControl attribute.

  2. AdminSDHolder Object:

    • Certain high-privilege accounts (e.g., members of Domain Admins) inherit their attribute protection from the AdminSDHolder object.

    • Ensures consistent and secure permissions across protected accounts.

  3. Read and Write Restrictions:

    • Some attributes, like unicodePwd, are write-only. Even administrators cannot read this value; they can only reset it.

  4. Auditing and Monitoring:

    • Any changes to protected attributes can be monitored using Active Directory auditing, which logs who accessed or modified these attributes.

Can Protected Attributes Be Modified?

  • Directly: Only if the user has sufficient privileges, such as being a member of the Schema Admins or Domain Admins group, and if the ACL explicitly allows it.

  • Indirectly: Some attributes (like unicodePwd) can only be modified through specific AD tools or APIs (e.g., when resetting a password using the Active Directory Users and Computers (ADUC) console or PowerShell).

Best Practices for Protected Attributes

  1. Restrict Privileged Access: Use Role-Based Access Control (RBAC) to limit who can access or modify sensitive attributes.

  2. Enable Auditing: Track changes to protected attributes using AD's auditing capabilities.

  3. Use Secure Tools: Modify protected attributes using secure and approved methods (e.g., PowerShell, ADUC).

  4. Regularly Review ACLs: Ensure that permissions on critical attributes are not overly permissive.

Protected attributes play a key role in safeguarding Active Directory's security. Managing them properly is critical to prevent unauthorized access and potential breaches.

High-Level Steps to Create a Protected Attribute

  1. Log in as a Schema Admin.

  2. Create a new multi-valued string attribute.

  3. Secure the attribute with appropriate access controls.

  4. Add the attribute to the user class.

  5. Create the CepTelReader group.

  6. Grant read permissions for the attribute to the CepTelReader group.

  7. Assign the ceptel attribute to a user.

  8. Test the functionality and permissions.

# 1. Log in as a Schema Admin
# Create a new multi-valued or single-valued string attribute
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$newAttribute = @{
    lDAPDisplayName = 'hiddenMobilePhone'              # LDAP display name for the attribute
    attributeId = '1.3.6.1.4.1.99999.1.1.1'            # Use your own OID
    oMSyntax = 64                                      # Use 64 for multi-valued string attributes
    attributeSyntax = '2.5.5.12'                       # String syntax
    isSingleValued = $false                            # Set to false for multi-valued, true for single-valued
    searchFlags = 1                                    # Set to 1 to make the attribute indexable
    adminDescription = 'Protected Mobile Phone Number' # Admin description for the attribute
    adminDisplayName = 'HiddenMobilePhone'             # Admin display name for the attribute
}
New-ADObject -Name $newAttribute.lDAPDisplayName -Type attributeSchema -Path $schemaPath -OtherAttributes $newAttribute

# 3. Secure the attribute with access controls
$attribute = Get-ADObject -Filter { lDAPDisplayName -eq 'hiddenMobilePhone' } -SearchBase $schemaPath
Set-ADObject -Identity $attribute.DistinguishedName -Replace @{ systemFlags = 16 }

# 4. Add the attribute to the user class
$userClass = Get-ADObject -Filter { lDAPDisplayName -eq 'user' } -SearchBase $schemaPath -Properties mayContain
$currentMayContain = $userClass.mayContain
$newMayContain = $currentMayContain + @($attribute.lDAPDisplayName)
Set-ADObject -Identity $userClass.DistinguishedName -Replace @{ mayContain = $newMayContain }

# 5. Create the hiddenMobilePhoneReader group
$groupName = "hiddenMobilePhoneReader"
$groupPath = "OU=Groups,DC=e2p,DC=com"      # Use your own organizational unit (OU)
if (-not (Get-ADGroup -Filter { Name -eq $groupName } -ErrorAction SilentlyContinue)) {
    New-ADGroup -Name $groupName -GroupScope Global -GroupCategory Security -Path $groupPath
}

# 6. Grant read permissions for the attribute to the hiddenMobilePhoneReader group
$group = Get-ADGroup -Identity $groupName
$schemaIDGUIDBytes = $attribute.schemaIDGUID
$schemaIDGUID = [Guid]::new($schemaIDGUIDBytes)

$acl = Get-Acl -Path "AD:\$($attribute.DistinguishedName)"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $group.SID, 
    'ReadProperty', 
    'Allow', 
    $schemaIDGUID, 
    'None'
)
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:\$($attribute.DistinguishedName)" -AclObject $acl

# 7. Assign the hiddenMobilePhone attribute to a user
$user = "SomeUser" # Replace with the username
Set-ADUser -Identity $user -Add @{ hiddenMobilePhone = '5001234567', '5009876543' }

# 8. Test
Write-Host "Log in with a user in the hiddenMobilePhoneReader group and run the following command:"
Get-ADUser -Identity $user -Properties hiddenMobilePhone | Select-Object -ExpandProperty hiddenMobilePhone
PreviousSecuring Windows Server

Last updated