What Does Security Descriptor Definition Language Mean?
SDDL, or Security Descriptor Definition Language, defines the string format that the ConvertSecurityDescriptorToStringSecurityDescriptor and ConvertStringSecurityDescriptorToSecurityDescriptor functions use to describe the security settings of an object in Windows as a text string. Think of it like a simple language for defining who can access an object (like a file, folder, or registry key) and what they can do with it.
In this blog we will discuss:
SDDL Key Features
Reading and editing permissions: SDDL allows administrators to easily understand and modify the security settings of objects.
Scripting and automation: It can be used in scripts and other tools to automate security tasks, making it more efficient and consistent.
Debugging and troubleshooting: Analyzing SDDL strings can help diagnose security issues and understand how permissions are configured.
SDDL for Device Objects
SDDL is employed to represent security descriptors. Security settings for device objects can be specified through an SDDL string placed in an INF file or provided to IoCreateDeviceSecure. A comprehensive documentation of the Security Descriptor Definition Language is available in the Microsoft Windows SDK documentation.
While INF files support the complete range of SDDL, IoCreateDeviceSecure routine only supports a subset of the language, which is outlined here.
SDDL strings for device objects follow the format “D:P” followed by one or more expressions in the form “(A;;Access;;;SID)”. The SID value designates a security identifier determining the entity (e.g., a user or group) to which the Access value pertains.
Control the Windows Firewall using Command Line Interface
Here are examples of utilizing PowerShell and netsh.exe to handle Windows Firewall, enabling automation in its management. To create a firewall rule that requires group membership and encryption, the following firewall regulation permits Telnet traffic exclusively from user accounts within a custom group named “Authorized to Access Server.” This access can be further limited based on the device, user, or a combination thereof, by defining specific restriction parameters. A Security Descriptor Definition Language (SDDL) string is generated by extending the security identifier (SID) of a user or group. The following example from Manage Windows Firewall with the command line shows you how to create an SDDL string that represents security groups.
| Powershell |
| $user = new-object System.Security.Principal.NTAccount (“corp.contoso.com\Administrators”)
$SIDofSecureUserGroup = $user.Translate([System.Security.Principal.SecurityIdentifier]).Value $secureUserGroup = “D:(A;;CC;;;$SIDofSecureUserGroup)” |
Utilizing the preceding scriptlet, you can also obtain the SDDL string for a secure computer group, as demonstrated below:
| Powershell |
| $secureMachineGroup = “D:(A;;CC;;;$SIDofSecureMachineGroup)” |
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
This policy setting enables you to establish additional device-wide controls governing access to all Distributed Component Object Model (DCOM)-based applications. These controls specifically regulate call, activation, or launch requests on the device. Conceptually, these access controls function as an extra layer of verification, wherein a device-wide access control list (ACL) is consulted for each call, activation, or launch of any COM-based server. Should the access check fail, the call, activation, or launch request will be denied. Importantly, this check supplements any access assessment conducted against server-specific ACLs. Essentially, it sets a baseline authorization standard that must be met to access any COM-based server, thereby managing access permissions for call rights.
Location of the setting is:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Possible values:
- User-defined inputof the SDDL representation of the groups and privileges
When you designate the users or groups to receive permissions, the security descriptor field is filled with the representation of those groups and privileges in the Security Descriptor Definition Language. Users and groups can receive explicit Allow or Deny privileges for both local and remote access.
- Blank
This value indicates how the local security policy removes the enforcement key for the policy. It deletes the policy and sets it to “Not defined.” To set a blank value, choose “Define this policy setting,” keep the Security descriptor field empty, and then click OK.
Group Policy Setting
Enabling the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy generates registry settings that supersede previous configurations. The Remote Procedure Call (RPC) service prioritizes these new registry keys under the Policies section for computer restrictions over existing OLE registry entries. Consequently, earlier settings become ineffective, and adjustments made to them won’t alter device access permissions for users. Exercise caution when configuring user and group lists.
If administrators face access denial to DCOM applications following Windows OS changes, they can use the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy. This policy allows administrators to manage DCOM access both locally and remotely by specifying permitted users and groups. To define this policy, access its settings, click Edit Security, and define the desired users or groups along with their access permissions. This action sets the appropriate SDDL value, thus restoring control of DCOM applications to administrators and users.
Vulnerability
Numerous COM applications integrate security-specific code, like invoking CoInitializeSecurity, yet they adopt weak settings enabling unauthenticated access to the process. Administrators lack the capability to supersede these settings for enforcing stronger security in earlier Windows versions without altering the application. Consequently, attackers may seek to exploit the vulnerability of an individual application by launching assaults through COM calls.
Security setting
To safeguard individual COM-based applications or services, configure the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax setting with an appropriate device-wide ACL.
Potential Impact and Why Hardening is Necessary
Upon installation, Windows establishes default COM ACLs. Altering these ACLs from their default configurations may result in failure for certain applications or components that rely on DCOM for communication. If you develop a COM-based server and customize the default security settings, ensure that the application-specific call permissions assigned by the ACL are accurate for the intended users. If they are not, you must adjust the application-specific permission ACL to grant activation rights to the appropriate users, ensuring the uninterrupted functioning of applications and Windows components utilizing DCOM.
By automating the process of setting up strict machine access controls for DCOM, large organizations can save time and resources. Automated hardening ensures that security measures are consistently applied across a rapidly evolving infrastructure. This helps organizations keep pace with technological changes and ensures that all systems are appropriately protected against potential security threats.
Additionally, automated hardening helps organizations meet compliance requirements more effectively by ensuring that security configurations are consistently enforced across all systems.
