Windows Server ACL Editor: Mastering Filtered Property Modification for Enhanced Security

Table of Contents

Summary¶

The Per-Property Permissions tab within Active Directory Users and Computers (ADUC) is a crucial tool for administrators managing user objects. However, it’s important to understand that not every property of a user object is visible by default in this tab. This intentional filtering is designed to streamline the user interface and simplify management by preventing an overwhelming display of properties, many of which are rarely modified in routine administrative tasks. While the complete schema defines all possible properties for an object, the list of properties that are filtered from view is governed by the Dssec.dat file. This file resides within the %systemroot%\System32 directory on all domain controllers within your environment.

Administrators seeking to gain visibility and control over these filtered properties can achieve this by directly editing the Dssec.dat file. Modifying the entries within this file allows you to selectively display properties that are otherwise hidden within the ADUC interface, thereby enabling granular control over permissions for a wider range of object attributes. This capability is particularly valuable in environments requiring stringent security configurations and precise permission management across all facets of user objects and other directory service elements. By understanding and utilizing this technique, administrators can significantly enhance their ability to manage and secure their Active Directory environment with greater precision.

Filtered Properties in the Dssec.dat File¶

The Dssec.dat file serves as the central configuration point for defining which properties are filtered within the Active Directory Users and Computers interface. Each object type can have its own section within this file, allowing for tailored filtering rules. Within these object type sections, individual properties are listed along with a numerical value that dictates their visibility and permission display behavior in the user interface. Understanding the structure and syntax of entries within the Dssec.dat file is crucial for effectively modifying property filtering.

A typical entry for a filtered property in the Dssec.dat file follows a simple format:

[ObjectType]
PropertyName=Value

Where:

• [ObjectType]: Specifies the Active Directory object class to which the filtering rule applies. Common examples include [User], [Group], [Computer], and others. This section header is enclosed in square brackets.
• PropertyName: Represents the LDAP display name of the property you wish to control. This is the attribute name as defined in the Active Directory schema.
• Value: A numerical value that determines the filtering behavior for the specified property. This value dictates which permissions (read and/or write) are displayed in the ADUC interface.

The key to controlling property visibility lies in understanding the meaning of these numerical values. By changing the Value, you can customize how permissions for a given property are presented within the Active Directory Users and Computers tool. Let’s delve into the specific values and their effects.

Displaying Read and Write Permissions (Value = 0)¶

To ensure that both read and write permissions for a specific property are visible within the ADUC interface, you need to set the Value for that property to zero (0) in the Dssec.dat file. This setting effectively disables filtering for both read and write permissions, making them fully accessible for viewing and modification through the “Per-Property Permissions” tab. This is the most comprehensive visibility setting, allowing administrators to manage both aspects of access control for the property in question.

For example, if you want to display both read and write permissions for the “userAccountControl” property of user objects, you would modify the [User] section of the Dssec.dat file to include or modify the following line:

[User]
userAccountControl=0

After making this change and restarting Active Directory Users and Computers, the “Per-Property Permissions” tab for user objects will now display both read and write permissions related to the userAccountControl attribute, allowing for complete permission management of this critical user account setting.

Displaying Only Write Permissions (Value = 1)¶

In scenarios where you are primarily concerned with controlling write access to a property and less so with read access, you can configure the Dssec.dat file to display only the write permissions. This is achieved by setting the Value for the property to one (1). With this setting, the ADUC interface will present permission settings relevant to modifying the property’s value, while read permissions might be implicitly granted or managed through other access control mechanisms. This can simplify the interface in situations where write access is the primary focus of permission management.

To illustrate, if you wish to display only write permissions for the “description” property of user objects, you would modify the [User] section of the Dssec.dat file as follows:

[User]
description=1

After applying this change and restarting ADUC, the “Per-Property Permissions” tab for user objects will now emphasize the write permissions associated with the “description” attribute. Administrators can then focus specifically on controlling who can modify the user’s description, streamlining the permission management process for this particular property.

Displaying Only Read Permissions (Value = 2)¶

Conversely, if your focus is on auditing or managing who can read a specific property without necessarily needing to control write access directly through the ADUC interface, you can configure the Dssec.dat file to display only read permissions. This is accomplished by setting the Value for the property to two (2). This setting will cause the ADUC interface to primarily showcase the permissions related to reading the property’s value. This can be useful for scenarios where data confidentiality and read access control are paramount.

For instance, to display only read permissions for the “telephoneNumber” property of user objects, you would modify the [User] section in Dssec.dat to include or adjust the following line:

[User]
telephoneNumber=2

Following this modification and a restart of Active Directory Users and Computers, the “Per-Property Permissions” tab for user objects will now highlight the read permissions associated with the “telephoneNumber” attribute. This allows administrators to concentrate on managing who can view users’ phone numbers, which might be important for compliance or data privacy reasons.

Summary of Filter Values¶

To provide a clear overview, the following table summarizes the meaning of each Value used in the Dssec.dat file for property filtering:

Value	Permissions Displayed	Description
0	Read and Write	Displays both read and write permissions for the property. This is the most comprehensive visibility setting.
1	Write Only	Displays only write permissions for the property. Focuses on controlling modification access.
2	Read Only	Displays only read permissions for the property. Emphasizes controlling who can view the property’s value.
7	Filtered (Default)	The property is filtered and not displayed by default in the “Per-Property Permissions” tab. This is the initial state for many properties.

Understanding these values is essential for effectively customizing the property visibility within Active Directory Users and Computers using the Dssec.dat file. By strategically adjusting these values, administrators can tailor the interface to display the specific permissions they need to manage, enhancing efficiency and security.

Modifying the Dssec.dat File: Important Considerations¶

Before making any changes to the Dssec.dat file, it is crucial to understand the implications and follow best practices to avoid potential issues. Directly editing system files like Dssec.dat requires caution and a clear understanding of the intended outcome.

1. Location and Replication: The Dssec.dat file is located in the %systemroot%\System32 directory on every domain controller in your domain. Changes made to this file on one domain controller must be replicated to all other domain controllers to ensure consistent behavior across the entire domain. Active Directory replication typically handles this automatically, but it’s important to monitor replication health to confirm that changes are propagated successfully.

2. Editing with Administrative Privileges: Modifying the Dssec.dat file requires domain administrator privileges. Ensure you are logged in with an account that has the necessary permissions to make changes to system files on domain controllers. Exercise caution when using domain administrator accounts and follow the principle of least privilege whenever possible.

3. Backup Before Modification: Always create a backup copy of the original Dssec.dat file before making any changes. This backup will serve as a rollback option in case of unintended consequences or errors during editing. Store the backup in a safe location for easy retrieval if needed.

4. Use a Text Editor with Care: Open and edit the Dssec.dat file using a plain text editor like Notepad. Avoid using rich text editors like WordPad or Microsoft Word, as they may introduce formatting characters that can corrupt the file and lead to unexpected behavior.

5. Syntax and Formatting: Pay close attention to the syntax and formatting when editing the file. Ensure that the section headers ([ObjectType]) are correctly spelled and enclosed in square brackets, and that property names and values are entered correctly. Incorrect syntax can prevent the file from being parsed correctly, leading to filtering issues or other errors.

6. Restart Active Directory Users and Computers: After making changes to the Dssec.dat file, it is mandatory to close and restart Active Directory Users and Computers on any workstation or server where you want to see the updated property filtering. The changes are not reflected in the interface until ADUC is restarted, as it reads the Dssec.dat file upon startup.

7. Testing in a Non-Production Environment: It is highly recommended to test any changes to the Dssec.dat file in a non-production environment first, such as a test lab or staging environment. This allows you to verify the desired behavior and identify any potential issues before implementing the changes in your production Active Directory.

8. Documentation of Changes: Keep a record of all modifications made to the Dssec.dat file, including the date, the administrator who made the changes, and the specific properties and values modified. This documentation is crucial for auditing, troubleshooting, and maintaining configuration consistency over time.

By adhering to these important considerations, administrators can safely and effectively modify the Dssec.dat file to customize property filtering in Active Directory Users and Computers, enhancing their ability to manage and secure their directory service environment.

Practical Example: Displaying the ‘msExchHideFromAddressLists’ Property¶

Let’s walk through a practical example of modifying the Dssec.dat file to display a commonly filtered property: msExchHideFromAddressLists. This property, relevant in Exchange environments, controls whether a user or group is hidden from Exchange address lists (GAL). By default, this property is often filtered in ADUC.

Scenario: You need to manage the msExchHideFromAddressLists property for user objects directly from the “Per-Property Permissions” tab in Active Directory Users and Computers.

Steps:

1. Locate a Domain Controller: Log on to a domain controller in your domain using domain administrator credentials.
2. Backup Dssec.dat: Navigate to the %systemroot%\System32 directory. Locate the Dssec.dat file and create a backup copy. For example, rename it to Dssec.dat.bak.
3. Edit Dssec.dat: Open the original Dssec.dat file using Notepad.
4. Find the [User] Section: Scroll through the file to find the section labeled [User]. If it doesn’t exist, you can create it at the end of the file.

5. Add or Modify the Property: Within the [User] section, add a new line or modify an existing line to include the msExchHideFromAddressLists property with the desired value. To display both read and write permissions, add the following line:

   [User]
   msExchHideFromAddressLists=0
   

   If you only want to display write permissions:

   [User]
   msExchHideFromAddressLists=1
   

   For read permissions only:

   [User]
   msExchHideFromAddressLists=2
   

   For this example, let’s use 0 to display both read and write permissions.
   6. Save the File: Save the changes to the Dssec.dat file in Notepad.
   7. Restart ADUC: Close and reopen Active Directory Users and Computers on your workstation or the domain controller where you want to test the change.
   8. Verify the Change: Open the properties of a user object in ADUC. Go to the “Security” tab, then click “Advanced.” Select a user or group in the permissions list and click “Edit.” Navigate to the “Permissions” tab and then to “Per-property Permissions.” Scroll through the list of properties. You should now see the msExchHideFromAddressLists property listed, and you can view and modify its permissions.

Important Note: Remember that this change needs to replicate to all domain controllers. Monitor Active Directory replication to ensure consistency across your domain.

By following these steps, you have successfully modified the Dssec.dat file to display the msExchHideFromAddressLists property in Active Directory Users and Computers, allowing for direct permission management of this attribute through the user interface. This same process can be applied to other filtered properties as needed, empowering administrators with greater control over object attribute security.

Modifying the Dssec.dat file provides a powerful way to customize the visibility of object properties within Active Directory Users and Computers. By understanding the structure of the file, the meaning of the filter values, and the important considerations for editing, administrators can effectively enhance their ability to manage and secure their Active Directory environment with greater granularity and precision.

Do you have any questions or experiences with modifying the Dssec.dat file? Share your thoughts in the comments below!