{
	"id": "d5ea365a-b2ff-4b83-895e-0498124f34f7",
	"created_at": "2026-04-06T00:09:40.578735Z",
	"updated_at": "2026-04-10T03:20:35.310436Z",
	"deleted_at": null,
	"sha1_hash": "1a1bc0ecce902e587eac724087a27cf0ba007f0c",
	"title": "DCOM Security Enhancements in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 - Win32 apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 77728,
	"plain_text": "DCOM Security Enhancements in Windows XP Service Pack 2 and\r\nWindows Server 2003 Service Pack 1 - Win32 apps\r\nBy stevewhims\r\nArchived: 2026-04-05 16:05:07 UTC\r\nWindows Server XP Service Pack 2 (SP2) and Windows Server 2003 Service Pack 1 (SP1) introduce enhanced default\r\nsecurity settings for the Distributed Component Object Model (DCOM). Specifically, they introduce more granular rights\r\nthat enable an administrator to have independent control over local and remote permissions for launching, activating, and\r\naccessing COM servers.\r\nThe Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating\r\nbinary software components that can interact. The Distributed Component Object Model (DCOM) allows applications to be\r\ndistributed across locations that make the most sense to you and to the application. The DCOM wire protocol transparently\r\nprovides support for reliable, secure, and efficient communication between COM components.\r\nWho does this feature apply to?\r\nIf you use COM only for in-process COM components, this feature does not apply to you.\r\nThis feature applies to you if you have a COM server application that meets one of the following criteria:\r\nThe access permission for the application is less stringent than the launch permission, which is necessary to run the\r\napplication.\r\nThe application is usually activated by a remote COM client without using an administrative account.\r\nThe application is meant to be used only locally. This means you can restrict your COM server application so it is not\r\nremotely accessible.\r\nWhat new functionality is added to this feature in Windows XP Service Pack 2 and\r\nWindows Server 2003 Service Pack 1?\r\nComputer-wide restrictions\r\nA change has been made in COM to provide computer-wide access controls that govern access to all call, activation, or\r\nlaunch requests on the computer. The simplest way to think about these access controls is as an additional AccessCheck call\r\nthat is done against a computer-wide access control list (ACL) on each call, activation, or launch of any COM server on the\r\ncomputer. If the AccessCheck fails, the call, activation, or launch request is denied. This is in addition to any AccessCheck\r\nthat is run against the server-specific ACLs. In effect, it provides a minimum authorization standard that must be passed to\r\naccess any COM server on the computer. There is a computer-wide ACL for launch permissions to cover activate and launch\r\nrights, and a computer-wide ACL for access permissions to cover call rights. These can be configured through the\r\nComponent Services Microsoft Management Console (MMC).\r\nThese computer-wide ACLs provide a way to override weak security settings specified by a specific application through\r\nCoInitializeSecurity or application-specific security settings. This provides a minimum security standard that must be\r\npassed, regardless of the settings of the specific server.\r\nThese ACLs are checked when the interfaces exposed by RPCSS are accessed. This provides a method to control access to\r\nthis system service.\r\nThese ACLs provide a centralized location where an administrator can set general authorization policy that applies to all\r\nCOM servers on the computer.\r\nNote\r\nChanging the computer-wide security settings will affect all COM server applications, and might prevent them from\r\nworking properly. If there are COM server applications that have restrictions that are less stringent than the computer-wide\r\nrestrictions, reducing the computer-wide restrictions might expose these applications to unwanted access. Conversely, if you\r\nincrease the computer-wide restrictions, some COM server applications might no longer be accessible by calling\r\napplications.\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 1 of 9\n\nBy default, Windows XP SP2 computer restriction settings are:\r\nPermission Administrator Everyone Anonymous\r\nLaunch\r\nLocal Launch\r\nLocal Activation\r\nRemote Launch\r\nRemote Activation\r\nLocal Launch\r\nLocal Activation\r\nAccess\r\nLocal Access\r\nRemote Access\r\nLocal Access\r\nBy default, Windows Server 2003 SP 1 computer restriction settings are as follows.\r\nPermission Administrator\r\nDistributed COM Users (Built in\r\nGroup)\r\nEveryone Anonymous\r\nLaunch\r\nLocal Launch\r\nLocal Activation\r\nRemote Launch\r\nRemote\r\nActivation\r\nLocal Launch\r\nLocal Activation\r\nRemote Launch\r\nRemote Activation\r\nLocal Launch\r\nLocal\r\nActivation\r\nN/A\r\nAccess N/A\r\nLocal Access\r\nRemote Access\r\nLocal Access\r\nRemote Access\r\nLocal Access\r\nRemote Access\r\nNote\r\nDistributed COM Users is a new built-in group included with Windows Server 2003 SP1 to expedite the process of adding\r\nusers to the DCOM computer restriction settings. This group is part of the ACL used by the MachineAccessRestriction and\r\nMachineLaunchRestriction settings, so removing users from this group will affect those settings.\r\nWhy is this change important? What threats does it help mitigate?\r\nMany COM applications include some security-specific code (for example, calling CoInitializeSecurity), but use weak\r\nsettings, often allowing unauthenticated access to the process. There is currently no way for an administrator to override\r\nthese settings to force stronger security in earlier versions of Windows.\r\nCOM infrastructure includes the RPCSS, a system service that runs during system startup and always runs after that. It\r\nmanages activation of COM objects and the running object table and provides helper services to DCOM remoting. It\r\nexposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote access, these\r\ninterfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users\r\non remote, unauthenticated computers.\r\nIn earlier versions of Windows, there was no way for an administrator to understand the exposure level of the COM servers\r\non a computer. An administrator got an idea of the exposure level by systematically checking the configured security\r\nsettings for all the registered COM applications on the computer, but, given that there are about 150 COM servers in a\r\ndefault installation of Windows, that task was daunting. There was no way to view the settings for a server that incorporates\r\nsecurity in the software, short of reviewing the source code for that software.\r\nDCOM computer-wide restrictions mitigate these three problems. It also gives an administrator the capability to disable\r\nincoming DCOM activation, launch, and calls.\r\nWhat works differently?\r\nBy default, the Everyone group is granted local launch, local activation, and local access call permissions. This enables all\r\nlocal scenarios to work without modification to the software or the operating system.\r\nBy default, in Windows XP SP2, the Everyone group is granted remote access call permissions. In Windows Server 2003\r\nSP1, the Everyone and Anonymous groups are granted remote access permissions. This enables most COM client scenarios,\r\nincluding the common case where a COM client passes a local reference to a remote server, in effect turning the client into a\r\nserver. In Windows XP SP2, this might disable scenarios that require unauthenticated remote access calls.\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 2 of 9\n\nAlso by default, only members of the Administrators group are granted remote activation and launch permissions. This\r\ndisables remote activations by non-administrators to installed COM servers.\r\nHow do I resolve these issues?\r\nIf you implement a COM server and expect to support remote activation by a non-administrative COM client, then you\r\nshould consider whether the risk associated with enabling this process is acceptable or if you should modify your\r\nimplementation to not require remote activation by a non-administrative COM client or remote unauthenticated calls.\r\nIf the risk is acceptable and you want to enable remote activation by a non-administrative COM client or remote\r\nunauthenticated calls, you must change the default configuration for this feature.\r\nNote\r\nChanging the computer-wide security settings will affect all COM server applications, and might prevent them from\r\nworking properly. If there are COM server applications that have restrictions that are less stringent than the computer-wide\r\nrestrictions, reducing the computer-wide restrictions may expose these applications to unwanted access. Conversely, if you\r\nincrease the computer-wide restrictions, some COM server applications might no longer be accessible by calling\r\napplications.\r\nYou can change the configuration settings using either the Component Services Microsoft Management Console (MMC) or\r\nthe Windows registry.\r\nIf you use the Component Services MMC snap-in, these settings can be configured on the COM Security tab of the\r\nProperties dialog box for the computer you are managing. The Access Permissions area has been modified to enable you to\r\nset computer-wide limits in addition to the standard default settings for COM servers. Additionally, you can provide separate\r\nACL settings for local and remote access under both limits and defaults.\r\nIn the Launch and Activation Permissions area, you can control the local and remote permissions as well as the computer-wide limits and the defaults. You can specify both local and remote activation and launch permissions independently.\r\nAlternatively, you can configure these ACL settings using the registry.\r\nThese ACLs are stored in the registry at the following locations:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Ole\\MachineAccessRestriction=ACL\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Ole\\MachineLaunchRestriction=ACL\r\nThese are named values of type REG_BINARY that contain data that describe the ACL of the principals that can access any\r\nCOM class or COM object on the computer. The access rights in the ACL are:\r\nCOM_RIGHTS_EXECUTE 1\r\nCOM_RIGHTS_EXECUTE_LOCAL 2\r\nCOM_RIGHTS_EXECUTE_REMOTE 4\r\nCOM_RIGHTS_ACTIVATE_LOCAL 8\r\nCOM_RIGHTS_ACTIVATE_REMOTE 16\r\nThese ACLs can be created using normal security functions.\r\nNote\r\nTo provide backward compatibility, an ACL can exist in the format used before Windows XP SP2 and Windows Server 2003\r\nSP1, which uses only the access right COM_RIGHTS_EXECUTE, or it can exist in the new format used in Windows XP\r\nSP2 and Windows Server 2003 SP1, which uses COM_RIGHTS_EXECUTE together with a combination of\r\nCOM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL, and\r\nCOM_RIGHTS_ACTIVATE_REMOTE. Note that COM_RIGHTS_EXECUTE\u003e must always be present; the absence of\r\nthis right generates an invalid security descriptor. Also note that you must not mix the old format and the new format within\r\na single ACL; either all access control entries (ACEs) must grant only the COM_RIGHTS_EXECUTE access right, or they\r\nall must grant COM_RIGHTS_EXECUTE together with a combination of COM_RIGHTS_EXECUTE_LOCAL,\r\nCOM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL, and\r\nCOM_RIGHTS_ACTIVATE_REMOTE.\r\nNote\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 3 of 9\n\nOnly users with Administrator rights can modify these settings.\r\nWhat existing functionality is changing in Windows XP Service Pack 2 and Windows\r\nServer 2003 Service Pack 1?\r\nRPCSS runs as a network service\r\nRPCSS is a key service for the RPC Endpoint Mapper and DCOM infrastructure. This service ran as Local System in\r\nprevious versions of Windows. To reduce the attack surface of Windows and provide defense in depth, the RPCSS service\r\nfunctionality was split into two services. The RPCSS service with all the original functionality that did not require Local\r\nSystem privileges now runs under the Network Service account. A new DCOMLaunch service that includes functionality\r\nthat requires Local System privileges runs under the Local System account.\r\nWhy is this change important?\r\nThis change reduces the attack surface and provides defense in depth for the RPCSS service because an elevation of\r\nprivilege in the RPCSS service is now limited to the Network Service privilege.\r\nWhat works differently?\r\nThis change should be transparent to users because the combination of the RPCSS and DCOMLaunch services is equivalent\r\nto the previous RPCSS service provided in prior versions of Windows.\r\nMore specific COM permissions\r\nCOM server applications have two types of permissions: launch permissions and access permissions. Launch permissions\r\ncontrol authorization to start a COM server during COM activation if the server is not already running. These permissions\r\nare defined as security descriptors that are specified in registry settings. Access permissions control authorization to call a\r\nrunning COM server. These permissions are defined as security descriptors provided to the COM infrastructure through the\r\nCoInitializeSecurity API, or using registry settings. Both launch and access permissions allow or deny access based on\r\nprincipals, and make no distinction as to whether the caller is local to the server or remote.\r\nThe first change distinguishes the COM access rights, based on distance. The two distances that are defined are Local and\r\nRemote. A Local COM message arrives by way of the Local Remote Procedure Call (LRPC) protocol, while a Remote\r\nCOM message arrives by way of a remote procedure call (RPC) host protocol like transmission control protocol (TCP).\r\nCOM activation is the act of getting a COM interface proxy on a client by calling CoCreateInstance or one of its variants.\r\nAs a side effect of this activation process, sometimes a COM server must be started to fulfill the client's request. A launch\r\npermissions ACL asserts who is allowed to start a COM server. An access permissions ACL asserts who is allowed to\r\nactivate a COM object or call that object once the COM server is already running.\r\nThe second change is that the call and activation rights are separated to reflect to two distinct operations and to move the\r\nactivation right from the access permission ACL to the launch permission ACL. Because activation and launching are both\r\nrelated to acquiring an interface pointer, activation and launch access rights logically belong together in one ACL. And\r\nbecause you always specify launch permissions through configuration (as compared to access permissions, which are often\r\nspecified programmatically), putting the activation rights in the launch permission ACL provides the administrator with\r\ncontrol over activation.\r\nThe launch permission access control entries (ACEs) are broken into four access rights:\r\nLocal Launch (LL)\r\nRemote Launch (RL)\r\nLocal Activate (LA)\r\nRemote Activate (RA)\r\nThe access permission security descriptor is split into two access rights:\r\nLocal Access Calls (LC)\r\nRemote Access Calls (RC)\r\nThis allows the administrator to apply very specific security configurations. For example, you can configure a COM server\r\nso that it accepts local access calls from everyone, while only accepting remote access calls from Administrators. These\r\ndistinctions can be specified through changes to the COM permissions security descriptors.\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 4 of 9\n\nWhy is this change important? What threats does it help mitigate?\r\nEarlier versions of the COM server application have no way to restrict an application so that it can only be used locally\r\nwithout exposing the application on the network by way of DCOM. When a user has access to a COM server application,\r\nthey have access for both local and remote use.\r\nA COM server application might expose itself to unauthenticated users to implement a COM callback scenario. In this\r\nscenario, the application must also expose its activation to unauthenticated users, which might not be desirable.\r\nPrecise COM permissions give flexibility to the administrator to control a computer's COM permission policy. These\r\npermissions enable security for the described scenarios.\r\nWhat works differently? Are there any dependencies?\r\nTo provide backward compatibility, existing COM security descriptors are interpreted to allow or deny both local and\r\nremote access simultaneously. That is, an access control entry (ACE) either allows both local and remote, or denies both\r\nlocal and remote.\r\nThere are no backward-compatibility issues for call or launch rights. There is, however, an activation rights compatibility\r\nissue. If, in the existing security descriptors for a COM server, the configured launch permissions are more restrictive than\r\nthe access permissions and are more restrictive than what is minimally required for client activation scenarios, then the\r\nlaunch permissions ACL must be modified to give the authorized clients the appropriate activation permissions.\r\nFor COM applications that use the default security settings, there are no compatibility issues. For applications that are\r\ndynamically started using COM activation, most have no compatibility issues, because the launch permissions must already\r\ninclude anyone who is able to activate an object. Otherwise, such applications generate activation failures even before\r\napplying Windows XP SP2 or Windows Server 2003 SP1, when callers without launch permission try to activate an object\r\nand the COM server is not already running.\r\nThe applications of most concern for compatibility issues are COM applications that are already started by some other\r\nmechanism, such as Windows Explorer, or Service Control Manager. You can also start these applications by a previous\r\nCOM activation, which overrides the default access and launch permissions and specifies launch permissions that are more\r\nrestrictive than the call permissions. For more details about addressing this compatibility issue, see \"How do I resolve these\r\nissues?\" in the next section.\r\nIf a system that is upgraded to Windows XP SP2 or Windows Server 2003 SP1 is rolled back to an earlier state, any ACE\r\nthat was edited to allow local access, remote access, or both, is interpreted to allow both local and remote access. Any ACE\r\nthat was edited to deny local access, remote access, or both, is interpreted to deny both local and remote access. Whenever\r\nyou uninstall a service pack, you should ensure that no newly set ACEs cause applications to stop working.\r\nHow do I resolve these issues?\r\nIf you implement a COM server and you override the default security settings, confirm that the application-specific launch\r\npermissions ACL grants activation permission to appropriate users. If it does not, you must change your application-specific\r\nlaunch permission ACL to give appropriate users activation rights so applications and Windows components that use DCOM\r\ndo not fail. These application-specific launch permissions are stored in the registry.\r\nThe COM ACLs can be created or modified using normal security functions.\r\nWhat settings are added or changed in Windows XP Service Pack 2?\r\nCaution\r\nImproper use of these settings can cause applications and Windows components that use DCOM to fail.\r\nIn the following table, these abbreviations are used:\r\nLL - Local Launch\r\nLA - Local Activation\r\nRL - Remote Launch\r\nRA - Remote Activation\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 5 of 9\n\nLC - Local Access Calls\r\nRC - Remote Access Calls\r\nACL - Access Control List\r\nSetting name Location\r\nPrevious\r\ndefault\r\nvalue\r\nDefault value Possible valu\r\nMachineLaunchRestriction\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nEveryone -\r\nLL, LA,\r\nRL, RA\r\nAnonymous\r\n-\r\nLL, LA,\r\nRL, RA\r\n(This is a\r\nnew\r\nregistry\r\nkey. Based\r\non existing\r\nbehavior,\r\nthese are\r\nthe\r\neffective\r\nvalues.)\r\nAdministrator:\r\nLL, LA, RL,\r\nRA\r\nACL\r\nMachineAccessRestriction\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nEveryone -\r\nLC, RC\r\nAnonymous\r\n- LC, RC\r\n(This is a\r\nnew\r\nregistry\r\nkey. Based\r\non existing\r\nbehavior,\r\nthese are\r\nthe\r\neffective\r\nvalues.)\r\nEveryone: LC,\r\nRC\r\nAnonymous:\r\nLC\r\nACL\r\nCallFailureLoggingLevel HKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nNot\r\napplicable.\r\nThis registry\r\nkey is not\r\npresent;\r\nhowever, a\r\nmissing key or\r\nvalue is\r\ninterpreted as\r\n2.\r\nThis event is\r\nnot logged by\r\ndefault. If you\r\nchange this\r\nvalue to 1 to\r\nstart logging\r\nthis\r\ninformation to\r\nhelp you\r\n1 - Always lo\r\nfailures durin\r\nCOM Server\r\n2 - Never log\r\nfailures durin\r\ncall server pr\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 6 of 9\n\nSetting name Location\r\nPrevious\r\ndefault\r\nvalue\r\nDefault value Possible valu\r\ntroubleshoot\r\nan issue, be\r\nsure to\r\nmonitor the\r\nsize of your\r\nevent log,\r\nbecause this is\r\nan event that\r\ncan generate a\r\nlarge number\r\nof entries.\r\nInvalidSecurityDescriptorLoggingLevel\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nNot\r\napplicable.\r\nThis registry\r\nkey is not\r\npresent;\r\nhowever, a\r\nmissing key or\r\nvalue is\r\ninterpreted\r\nas 1.\r\nThis event is\r\nlogged by\r\ndefault. It\r\nshould rarely\r\noccur.\r\n1 - Always lo\r\nfailures when\r\ninfrastructure\r\ninvalid securi\r\n2 - Never log\r\nfailures when\r\ninfrastructure\r\ninvalid securi\r\nDCOM:Machine Launch Restrictions in\r\nSecurity Descriptor Definition Language\r\n(SDDL) Syntax\r\n(Group Policy object) Computer\r\nConfiguration \\Windows Settings\\Local\r\nPolicies \\Security Options\r\nNot\r\napplicable.\r\nNot defined\r\nAccess contro\r\nSDDL forma\r\nthis policy ov\r\nin\r\nMachineLaun\r\npreviously.\r\nDCOM:Machine Access Restrictions in\r\nSecurity Descriptor Definition Language\r\n(SDDL) Syntax\r\n(Group Policy object) Computer\r\nConfiguration \\Windows Settings \\Local\r\nPolicies \\Security Options\r\nNot\r\napplicable.\r\nNot defined\r\nAccess contro\r\nSDDL forma\r\nthis policy ov\r\nin\r\nMachineAcce\r\npreviously.\r\nWhat settings are added or changed in Windows Server 2003 Service Pack 1?\r\nNote\r\nImproper use of these settings can cause applications and Windows components that use DCOM to fail.\r\nIn the following table, these abbreviations are used:\r\nLL - Local Launch\r\nLA - Local Activation\r\nRL - Remote Launch\r\nRA - Remote Activation\r\nLC - Local Access Calls\r\nRC - Remote Access Calls\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 7 of 9\n\nACL - Access Control List\r\nSetting name Location\r\nPrevious\r\ndefault\r\nvalue\r\nDefault value Possible val\r\nMachineLaunchRestriction\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nEveryone:\r\nLL, LA, RL,\r\nRA\r\nAnonymous:\r\nLL, LA, RL,\r\nRA\r\n(This is a\r\nnew registry\r\nkey. Based\r\non existing\r\nbehavior,\r\nthese would\r\nbe the\r\neffective\r\nvalues.)\r\nAdministrator:\r\nLL, LA, RL,\r\nRA\r\nEveryone: LL,\r\nLA\r\nDistributed\r\nCOM users:\r\nLL, LA, RL,\r\nRA\r\nACL\r\nMachineAccessRestriction\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nEveryone:\r\nLC, RC\r\nAnonymous:\r\nLC, RC\r\n(This is a\r\nnew registry\r\nkey. Based\r\non existing\r\nbehavior,\r\nthese would\r\nbe the\r\neffective\r\nvalues.)\r\nEveryone: LC,\r\nRC\r\nAnonymous:\r\nLC, RC\r\nACL\r\nCallFailureLoggingLevel HKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nNot\r\napplicable.\r\nThis registry\r\nkey is not\r\npresent;\r\nhowever, a\r\nmissing key or\r\nvalue is\r\ninterpreted as\r\n2.\r\nThis event is\r\nnot logged by\r\ndefault. If you\r\nchange this\r\nvalue to 1 to\r\nstart logging\r\nthis\r\ninformation to\r\nhelp you\r\ntroubleshoot\r\nan issue, be\r\nsure to\r\nmonitor the\r\nsize of your\r\nevent log,\r\n1 - Always lo\r\nfailures whe\r\ninfrastructur\r\ninvalid secur\r\n2 - Never log\r\nfailures whe\r\ninfrastructur\r\ninvalid secur\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 8 of 9\n\nSetting name Location\r\nPrevious\r\ndefault\r\nvalue\r\nDefault value Possible val\r\nbecause this is\r\nan event that\r\ncan generate a\r\nlarge number\r\nof entries.\r\nInvalidSecurityDescriptorLoggingLevel\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\\r\nMicrosoft\\Ole\r\nNot\r\napplicable.\r\nThis registry\r\nkey is not\r\npresent;\r\nhowever, a\r\nmissing key or\r\nvalue is\r\ninterpreted\r\nas 1.\r\nThis event is\r\nlogged by\r\ndefault. It\r\nshould rarely\r\noccur.\r\n1 - Always lo\r\nfailures whe\r\ninfrastructur\r\ninvalid secur\r\n2 - Never log\r\nfailures whe\r\ninfrastructur\r\ninvalid secur\r\nDCOM:Machine Launch Restrictions in\r\nSecurity Descriptor Definition Language\r\n(SDDL) Syntax\r\n(Group Policy object) Computer\r\nConfiguration \\Windows Settings \\Local\r\nPolicies \\Security Options\r\nNot\r\napplicable.\r\nNot defined.\r\nAccess contr\r\nSDDL forma\r\nthis policy o\r\nin\r\nMachineLau\r\npreviously.\r\nDCOM:Machine Access Restrictions in\r\nSecurity Descriptor Definition Language\r\n(SDDL) Syntax\r\n(Group Policy object) Computer\r\nConfiguration \\Windows Settings \\Local\r\nPolicies \\Security Options\r\nNot\r\napplicable.\r\nNot defined.\r\nAccess contr\r\nSDDL forma\r\nthis policy o\r\nin\r\nMachineAcc\r\npreviously.\r\nSecurity in COM\r\nSource: https://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-se\r\nrvice-pack-1\r\nhttps://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows/desktop/com/dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1"
	],
	"report_names": [
		"dcom-security-enhancements-in-windows-xp-service-pack-2-and-windows-server-2003-service-pack-1"
	],
	"threat_actors": [],
	"ts_created_at": 1775434180,
	"ts_updated_at": 1775791235,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1a1bc0ecce902e587eac724087a27cf0ba007f0c.pdf",
		"text": "https://archive.orkl.eu/1a1bc0ecce902e587eac724087a27cf0ba007f0c.txt",
		"img": "https://archive.orkl.eu/1a1bc0ecce902e587eac724087a27cf0ba007f0c.jpg"
	}
}