What is a Protected Attribute and How to Create It?
What is Active Directory Schema Attribute?
The Active Directory (AD) schema is a component that defines the data structure of AD. The schema determines which object classes (for example, user, group, computer) and attributes are available and what data types those attributes will be.
An attribute represents a specific piece of data for AD objects. For example:
- sAMAccountName → User's login name
- mail → User's email address
Custom Attribute Nedir?
A custom attribute is an attribute added to the AD schema that isn't predefined and is specifically tailored to the needs of the business. It's used to store information not included in the default schema. For example:
- Personnel number of employees
- Department specific codes
- License status assigned to the user
Why Create a Custom Attribute?
The need to create custom attributes arises for the following reasons:
- Business Needs: To store information that is not included in the default schema but is required for business processes.
- Adaptation and Integration: When it is necessary to adapt AD for specialized software or integrations (for example, integrating into an HR system).
- Reporting and Management: To create more specific reports or track custom data for users/groups.
- Advanced Automation: When additional information fields are needed in advanced automation scenarios with tools such as PowerShell, etc.
Requirements for Creating a Custom Attribute
There are certain conditions and requirements for creating custom attributes:
-
Schema Admin Authority:
- Only users who are members of the Schema Admins group can modify the AD schema .
-
Planning and Testing:
- Changes to the schema cannot be undone , so thorough planning and testing are essential.
-
Global Coverage:
- Any changes added to the schema are shared by all domains in the AD forest.
-
Choosing the Right Data Type:
- When defining a new attribute, the appropriate data type must be selected (for example, String, Integer, Boolean).
-
Attribute Name Conflict:
- The generated custom attribute names must not conflict with the default schema or other custom attributes.
-
Replication Effect:
- New attributes can add additional load to AD replication, so adding unnecessary attributes should be avoided.
How to Create a Custom Attribute?
-
Schema Management Snap-in Activation:
- regsvr32 schmmgmt.dll Activate the schema management console with the command.
-
Adding Attributes Using MMC:
- The "Active Directory Schema" snap-in is added to the MMC and the new attribute is defined.
-
Adding the Attribute to the Object Class:
- The newly created attribute is added to the relevant object classes (e.g. user, group).
-
Replication ve Test:
- The attribute is tested after it has been replicated to all domain controllers.
Example Usage:
A company wants to store the dates users are assigned to a project . To do this:
- projectStartDate A custom attribute named is created.
- It is determined as the data type Date.
- This attribute useris added to the object class.
As a result, it becomes possible to manage and report this information using PowerShell or LDAP queries.
When onboarding, it is important to perform all operations in a test environment first to avoid affecting the production environment.
What is Protected Attribute?
In Active Directory, protected attributes are attributes whose access is tightly controlled and protected to ensure the security of sensitive data. Such attributes contain critical or sensitive information, such as passwords or security identifiers, and are protected from unauthorized access or modification.
Protected attributes are typically managed with Access Control Lists (ACLs) that define who can read, write, or modify this data . Only high-privilege accounts, such as Domain Admins or Enterprise Admins , or system accounts, such as Local System , can access these attributes.
Protected Attribute Examples
Some common protected attributes include:
-
unicodePwd
- It stores the user's password in an encrypted format.
- It can only be written to by system processes (for example, during password resets). Even the administrator cannot read this value.
-
userAccountControl
- Manages account features (e.g., account enable/disable, password requirements).
- Making changes requires special privileges.
-
msDS-PasswordSettings
- Stores password settings in Fine-Grained Password Policies.
- It is closed to unauthorized access to maintain security.
-
dBCSPwd (an old attribute)
- LM used to store password hashes.
- It is now obsolete, but is still highly preserved.
Why is the Protected Attribute Protected?
Protected characteristics were established to:
- Ensuring Security: Preventing unauthorized access to sensitive data such as passwords or account configurations.
- Protecting Data Integrity: Preventing accidental or malicious changes that could cause disruptions to systems.
- Legal Compliance: Regulations such as GDPR and HIPAA require the protection of sensitive information.
How to Check Protected Attributes?
-
Access Control Lists (ACL):
- Determines which users or groups can read, write, or change an attribute.
- For example: userAccountControlby default the attribute can only be changed by Domain Admins or Enterprise Admins .
-
AdminSDHolder Object:
- Some accounts with high privileges (for example, members of Domain Admins ) inherit their privilege protection from the AdminSDHolder object.
- This ensures consistent and secure permissions across protected accounts.
-
Read and Write Restrictions:
- Some attributes, such as unicodePwd, are write- only . Even an administrator cannot read this attribute; they can only reset it.
-
Control and Monitoring:
- All changes to protected attributes can be tracked through the Active Directory auditing system.
Can the Protected Attribute be Changed?
- Direct: Can only be done by users with sufficient privileges, such as Schema Admins , Domain Admins , and accounts allowed in the ACL.
- Indirect: Some attributes (for example unicodePwd) can only be changed through AD tools or APIs (for example, during password reset).
Best Practices for Protected Attributes
- Restrict Authorized Access: Limit who can access sensitive attributes using RBAC (Role-Based Access Control).
- Enable Auditing: Monitor changes to protected attributes using AD auditing capabilities.
- Use Secure Tools: Manage protected attributes only with secure and approved methods (e.g., PowerShell, ADUC).
- Regular ACL Review: Ensure that permissions for critical attributes are not overly broad.
Steps to Create a Protected Attribute
- Log in as Schema Admin.
- Create a new multi-valued or single-valued string attribute.
- Protect your attribute by making the necessary security settings.
- Add the created attribute to the user class.
- Create a group called CepTelReader.
- Define read permission for the attribute to the CepTelReader group.
- Add the ceptel attribute to the user.
- Test the entire configuration.
# 1. Login as Schema Admin
# 2. Creating a new multi-valued string attribute
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$newAttribute = @{
lDAPDisplayName = 'ceptel'
attributeId = '1.3.6.1.4.1.99999.1.1.1' # Use your own OID
oMSyntax = 64 # 64 for Multi-valued string
attributeSyntax = '2.5.5.12' # String syntax
isSingleValued = $false # Set to false to allow multiple values
searchFlags = 1 # Set to 1 to make it searchable (indexed)
adminDescription = 'Cep Telefonu Numarası'
adminDisplayName = 'CepTel'
}
New-ADObject -Name $newAttribute.lDAPDisplayName -Type attributeSchema -Path $schemaPath -OtherAttributes $newAttribute
# 3. Attribute'ü koruma altına alma
$attribute = Get-ADObject -Filter { lDAPDisplayName -eq 'ceptel' } -SearchBase $schemaPath
Set-ADObject -Identity $attribute.DistinguishedName -Replace @{ systemFlags = 128 }
# 4. Attribute'ü user sınıfına ekleme
$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. CepTelReader grubunu oluşturma
$groupName = "CepTelReader"
$groupPath = "OU=Groups,DC=e2p,DC=com" # Kendi OU'nuzu kullanın
if (-not (Get-ADGroup -Filter { Name -eq $groupName } -ErrorAction SilentlyContinue)) {
New-ADGroup -Name $groupName -GroupScope Global -GroupCategory Security -Path $groupPath
}
# 6. CepTelReader grubuna okuma izni verme
$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. Kullanıcıya ceptel attribute'ünü ekleme
$user = "kullanici1" # Kullanıcı adını değiştirin
Set-ADUser -Identity $user -Add @{ ceptel = '5551234567', '5559876543' }
# 8. Test etme
Write-Host "CepTelReader grubundaki bir kullanıcı ile oturum açın ve aşağıdaki komutu çalıştırın:"
Write-Host "Get-ADUser -Identity $user -Properties ceptel | Select-Object -ExpandProperty ceptel"