Aprimoramentos de segurança do DCOM no Windows XP Service Pack 2 e no Windows Server 2003 Service Pack 1

O Windows Server XP Service Pack 2 (SP2) e o Windows Server 2003 Service Pack 1 (SP1) introduzem configurações de segurança padrão aprimoradas para o DCOM (Modelo de Objeto de Componente Distribuído). Especificamente, eles introduzem direitos mais granulares que permitem que um administrador tenha controle independente sobre permissões locais e remotas para iniciar, ativar e acessar servidores COM.

O que o DCOM faz?

O COM (Microsoft Component Object Model) é um sistema independente de plataforma, distribuído e orientado a objetos para criar componentes de software binário que podem interagir. O DCOM (Modelo de Objeto de Componente Distribuído) permite que os aplicativos sejam distribuídos entre locais que fazem mais sentido para você e para o aplicativo. O protocolo de transmissão DCOM fornece suporte transparente para comunicação confiável, segura e eficiente entre componentes COM.

A quem esse recurso se aplica?

Se você usar COM apenas para componentes COM em processo, esse recurso não se aplicará a você.

Esse recurso se aplica a você se você tiver um aplicativo de servidor COM que atenda a um dos seguintes critérios:

• A permissão de acesso para o aplicativo é menos rigorosa do que a permissão de inicialização, o que é necessário para executar o aplicativo.
• O aplicativo geralmente é ativado por um cliente COM remoto sem usar uma conta administrativa.
• O aplicativo deve ser usado apenas localmente. Isso significa que você pode restringir seu aplicativo de servidor COM para que ele não seja acessível remotamente.

Qual nova funcionalidade é adicionada a esse recurso no Windows XP Service Pack 2 e no Windows Server 2003 Service Pack 1?

Restrições em todo o computador

Foi feita uma alteração no COM para fornecer controles de acesso em todo o computador que regem o acesso a todas as solicitações de chamada, ativação ou inicialização no computador. A maneira mais simples de pensar sobre esses controles de acesso é como uma chamada AccessCheck adicional feita em uma ACL (lista de controle de acesso) em todo o computador em cada chamada, ativação ou inicialização de qualquer servidor COM no computador. Se o AccessCheck falhar, a chamada, a ativação ou a solicitação de inicialização serão negadas. Isso se soma a qualquer do AccessCheck que seja executada nas ACLs específicas do servidor. Na verdade, ele fornece um padrão mínimo de autorização que deve ser passado para acessar qualquer servidor COM no computador. Há uma ACL em todo o computador para permissões de inicialização para cobrir os direitos de ativação e inicialização e uma ACL em todo o computador para permissões de acesso para cobrir os direitos de chamada. Elas podem ser configuradas por meio do MMC (Console de Gerenciamento da Microsoft) dos Serviços de Componentes.

Essas ACLs em todo o computador fornecem uma maneira de substituir configurações de segurança fracas especificadas por um aplicativo específico por meio de CoInitializeSecurity ou configurações de segurança específicas do aplicativo. Isso fornece um padrão de segurança mínimo que deve ser passado, independentemente das configurações do servidor específico.

Essas ACLs são verificadas quando as interfaces expostas pelo RPCSS são acessadas. Isso fornece um método para controlar o acesso a esse serviço do sistema.

Essas ACLs fornecem um local centralizado em que um administrador pode definir uma política de autorização geral que se aplica a todos os servidores COM no computador.

Nota

Alterar as configurações de segurança em todo o computador afetará todos os aplicativos de servidor COM e poderá impedi-los de funcionar corretamente. Se houver aplicativos de servidor COM que tenham restrições menos rigorosas do que as restrições em todo o computador, a redução das restrições em todo o computador poderá expor esses aplicativos a acesso indesejado. Por outro lado, se você aumentar as restrições em todo o computador, alguns aplicativos de servidor COM poderão não estar mais acessíveis chamando aplicativos.

Por padrão, as configurações de restrição de computador do Windows XP SP2 são:

Permissão	Administrador	Todos	Anônimo
Lançar	Inicialização local Ativação local Inicialização remota Ativação remota	Inicialização local Ativação local
Acesso		Acesso Local Acesso Remoto	Acesso Local

Por padrão, as configurações de restrição de computador do Windows Server 2003 SP 1 são as seguintes.

Permissão	Administrador	Usuários com distribuídos (grupo interno)	Todos	Anônimo
Lançar	Inicialização local Ativação local Inicialização remota Ativação remota	Inicialização local Ativação local Inicialização remota Ativação remota	Inicialização local Ativação local	N/A
Acesso	N/A	Acesso Local Acesso Remoto	Acesso Local Acesso Remoto	Acesso Local Acesso Remoto

Nota

Usuários COM Distribuídos é um novo grupo interno incluído no Windows Server 2003 SP1 para agilizar o processo de adição de usuários às configurações de restrição do computador DCOM. Esse grupo faz parte da ACL usada pelo MachineAccessRestriction e configurações de MachineLaunchRestriction, portanto, a remoção de usuários desse grupo afetará essas configurações.

Por que essa mudança é importante? Quais ameaças isso ajuda a atenuar?

Muitos aplicativos COM incluem alguns códigos específicos de segurança (por exemplo, chamar CoInitializeSecurity), mas usam configurações fracas, geralmente permitindo acesso não autenticado ao processo. No momento, não há como um administrador substituir essas configurações para forçar uma segurança mais forte em versões anteriores do Windows.

A infraestrutura COM inclui o RPCSS, um serviço de sistema que é executado durante a inicialização do sistema e sempre é executado depois disso. Ele gerencia a ativação de objetos COM e a tabela de objetos em execução e fornece serviços auxiliares à comunicação remota do DCOM. Ele expõe interfaces RPC que podem ser chamadas remotamente. Como alguns servidores COM permitem acesso remoto não autenticado, essas interfaces podem ser chamadas por qualquer pessoa, incluindo usuários não autenticados. Como resultado, o RPCSS pode ser atacado por usuários mal-intencionados em computadores remotos e não autenticados.

Em versões anteriores do Windows, não havia como um administrador entender o nível de exposição dos servidores COM em um computador. Um administrador teve uma ideia do nível de exposição verificando sistematicamente as configurações de segurança configuradas para todos os aplicativos COM registrados no computador, mas, considerando que há cerca de 150 servidores COM em uma instalação padrão do Windows, essa tarefa foi assustadora. Não havia como exibir as configurações de um servidor que incorpora a segurança no software, a não ser examinar o código-fonte desse software.

As restrições de todo o computador DCOM reduzem esses três problemas. Ele também fornece a um administrador a capacidade de desabilitar a ativação, inicialização e chamadas de DCOM de entrada.

O que funciona de forma diferente?

Por padrão, o grupo Todos recebe permissões locais de inicialização, ativação local e chamada de acesso local. Isso permite que todos os cenários locais funcionem sem modificação no software ou no sistema operacional.

Por padrão, no Windows XP SP2, o grupo Todos recebe permissões de chamada de acesso remoto. No Windows Server 2003 SP1, os grupos Todos e Anônimos recebem permissões de acesso remoto. Isso habilita a maioria dos cenários de cliente COM, incluindo o caso comum em que um cliente COM passa uma referência local para um servidor remoto, transformando o cliente em um servidor. No Windows XP SP2, isso pode desabilitar cenários que exigem chamadas de acesso remoto não autenticadas.

Também por padrão, somente os membros do grupo Administradores recebem permissões de ativação remota e inicialização. Isso desabilita ativações remotas por não administradores para servidores COM instalados.

Como resolver esses problemas?

Se você implementar um servidor COM e esperar dar suporte à ativação remota por um cliente COM não administrativo, considere se o risco associado à habilitação desse processo é aceitável ou se você deve modificar sua implementação para não exigir ativação remota por um cliente COM não administrativo ou chamadas remotas não autenticadas.

Se o risco for aceitável e você quiser habilitar a ativação remota por um cliente COM não administrativo ou chamadas remotas não autenticadas, você deverá alterar a configuração padrão para esse recurso.

Nota

Alterar as configurações de segurança em todo o computador afetará todos os aplicativos de servidor COM e poderá impedi-los de funcionar corretamente. Se houver aplicativos de servidor COM que tenham restrições menos rigorosas do que as restrições em todo o computador, a redução das restrições em todo o computador poderá expor esses aplicativos a acesso indesejado. Por outro lado, se você aumentar as restrições em todo o computador, alguns aplicativos de servidor COM poderão não estar mais acessíveis chamando aplicativos.

Você pode alterar as configurações usando o MMC (Console de Gerenciamento da Microsoft) dos Serviços de Componentes ou o Registro do Windows.

Se você usar o snap-in MMC dos Serviços de Componentes, essas configurações poderão ser configuradas na guia de Segurança com da caixa de diálogo Propriedades do para o computador que você está gerenciando. A área Permissões de Acesso foi modificada para permitir que você defina limites em todo o computador, além das configurações padrão padrão para servidores COM. Além disso, você pode fornecer configurações de ACL separadas para acesso local e remoto sob limites e padrões.

Na área permissões de inicialização e ativação, você pode controlar as permissões locais e remotas, bem como os limites de todo o computador e os padrões. Você pode especificar as permissões de ativação local e remota e inicialização de forma independente.

Como alternativa, você pode definir essas configurações de ACL usando o Registro.

Essas ACLs são armazenadas no registro nos seguintes locais:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction=ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction=ACL

Esses são valores nomeados do tipo REG_BINARY que contêm dados que descrevem a ACL das entidades de segurança que podem acessar qualquer classe COM ou objeto COM no computador. Os direitos de acesso na ACL são:

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

Essas ACLs podem ser criadas usando funções de segurança normais.

Nota

Para fornecer compatibilidade com versões anteriores, uma ACL pode existir no formato usado antes do Windows XP SP2 e do Windows Server 2003 SP1, que usa apenas o COM_RIGHTS_EXECUTE direito de acesso ou pode existir no novo formato usado no Windows XP SP2 e no Windows Server 2003 SP1, que usa COM_RIGHTS_EXECUTE junto com uma combinação de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL e COM_RIGHTS_ACTIVATE_REMOTE. Observe que COM_RIGHTS_EXECUTE> deve estar sempre presente; a ausência desse direito gera um descritor de segurança inválido. Observe também que você não deve misturar o formato antigo e o novo formato em uma única ACL; todas as ACEs (entradas de controle de acesso) devem conceder apenas o direito de acesso COM_RIGHTS_EXECUTE ou todos eles devem conceder COM_RIGHTS_EXECUTE junto com uma combinação de COM_RIGHTS_EXECUTE_LOCAL, COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL e COM_RIGHTS_ACTIVATE_REMOTE.

Nota

Somente usuários com direitos de administrador podem modificar essas configurações.

Qual funcionalidade existente está mudando no Windows XP Service Pack 2 e no Windows Server 2003 Service Pack 1?

O RPCSS é executado como um serviço de rede

O RPCSS é um serviço de chave para a infraestrutura RPC Endpoint Mapper e DCOM. Esse serviço foi executado como Sistema Local em versões anteriores do Windows. Para reduzir a superfície de ataque do Windows e fornecer defesa detalhadamente, a funcionalidade do serviço RPCSS foi dividida em dois serviços. O serviço RPCSS com toda a funcionalidade original que não exigia privilégios do Sistema Local agora é executado na conta do Serviço de Rede. Um novo serviço DCOMLaunch que inclui a funcionalidade que requer privilégios do Sistema Local é executado na conta do Sistema Local.

Por que essa mudança é importante?

Essa alteração reduz a superfície de ataque e fornece defesa detalhada para o serviço RPCSS porque uma elevação de privilégio no serviço RPCSS agora está limitada ao privilégio do Serviço de Rede.

O que funciona de forma diferente?

Essa alteração deve ser transparente para os usuários porque a combinação dos serviços RPCSS e DCOMLaunch é equivalente ao serviço RPCSS anterior fornecido em versões anteriores do Windows.

Permissões COM mais específicas

Os aplicativos de servidor COM têm dois tipos de permissões: permissões de inicialização e permissões de acesso. Inicie a autorização de controle de permissões para iniciar um servidor COM durante a ativação com se o servidor ainda não estiver em execução. Essas permissões são definidas como descritores de segurança especificados nas configurações do Registro. Permissões de acesso controlam a autorização para chamar um servidor COM em execução. Essas permissões são definidas como descritores de segurança fornecidos para a infraestrutura COM por meio da APICoInitializeSecurityou usando as configurações do Registro. As permissões de inicialização e acesso permitem ou negam acesso com base em entidades de segurança e não fazem distinção se o chamador é local para o servidor ou remoto.

A primeira alteração distingue os direitos de acesso COM, com base na distância. As duas distâncias definidas são Local e Remota. Uma mensagem COM local chega por meio do protocolo LRPC (Chamada de Procedimento Remoto Local), enquanto uma mensagem COM Remota chega por meio de um protocolo de host RPC (chamada de procedimento remoto), como o protocolo de controle de transmissão (TCP).

A ativação COM é o ato de obter um proxy de interface COM em um cliente chamando CoCreateInstance ou uma de suas variantes. Como efeito colateral desse processo de ativação, às vezes um servidor COM deve ser iniciado para atender à solicitação do cliente. Uma ACL de permissões de inicialização declara quem tem permissão para iniciar um servidor COM. Uma ACL de permissões de acesso declara quem tem permissão para ativar um objeto COM ou chamar esse objeto depois que o servidor COM já estiver em execução.

A segunda alteração é que os direitos de chamada e ativação são separados para refletir para duas operações distintas e para mover a ativação diretamente da ACL de permissão de acesso para a ACL de permissão de inicialização. Como a ativação e a inicialização estão relacionadas à aquisição de um ponteiro de interface, os direitos de acesso de ativação e inicialização pertencem logicamente em uma ACL. E como você sempre especifica permissões de inicialização por meio da configuração (em comparação com as permissões de acesso, que geralmente são especificadas programaticamente), colocar os direitos de ativação na ACL de permissão de inicialização fornece ao administrador controle sobre a ativação.

As ACEs (entradas de controle de acesso) de permissão de inicialização são divididas em quatro direitos de acesso:

• Início Local (LL)
• Inicialização Remota (RL)
• Ativação Local (LA)
• Ativação Remota (RA)

O descritor de segurança de permissão de acesso é dividido em dois direitos de acesso:

• LC (Chamadas de Acesso Local)
• RC (Chamadas de Acesso Remoto)

Isso permite que o administrador aplique configurações de segurança muito específicas. Por exemplo, você pode configurar um servidor COM para que ele aceite chamadas de acesso local de todos, aceitando apenas chamadas de acesso remoto de Administradores. Essas distinções podem ser especificadas por meio de alterações nos descritores de segurança de permissões COM.

Por que essa mudança é importante? Quais ameaças isso ajuda a atenuar?

As versões anteriores do aplicativo de servidor COM não têm como restringir um aplicativo para que ele só possa ser usado localmente sem expor o aplicativo na rede por meio do DCOM. Quando um usuário tem acesso a um aplicativo de servidor COM, ele tem acesso para uso local e remoto.

Um aplicativo de servidor COM pode se expor a usuários não autenticados para implementar um cenário de retorno de chamada COM. Nesse cenário, o aplicativo também deve expor sua ativação a usuários não autenticados, o que pode não ser desejável.

As permissões COM precisas dão flexibilidade ao administrador para controlar a política de permissão COM de um computador. Essas permissões habilitam a segurança para os cenários descritos.

O que funciona de forma diferente? Há dependências?

Para fornecer compatibilidade com versões anteriores, os descritores de segurança COM existentes são interpretados para permitir ou negar o acesso local e remoto simultaneamente. Ou seja, uma ACE (entrada de controle de acesso) permite local e remota ou nega local e remota.

Não há problemas de compatibilidade com versões anteriores para direitos de chamada ou inicialização. No entanto, há um problema de compatibilidade de direitos de ativação. Se, nos descritores de segurança existentes de um servidor COM, as permissões de inicialização configuradas forem mais restritivas do que as permissões de acesso e forem mais restritivas do que o mínimo necessário para cenários de ativação do cliente, a ACL de permissões de inicialização deverá ser modificada para conceder aos clientes autorizados as permissões de ativação apropriadas.

Para aplicativos COM que usam as configurações de segurança padrão, não há problemas de compatibilidade. Para aplicativos que são iniciados dinamicamente usando a ativação COM, a maioria não tem problemas de compatibilidade, pois as permissões de inicialização já devem incluir qualquer pessoa que seja capaz de ativar um objeto. Caso contrário, esses aplicativos geram falhas de ativação antes mesmo de aplicar o Windows XP SP2 ou o Windows Server 2003 SP1, quando os chamadores sem permissão de inicialização tentam ativar um objeto e o servidor COM ainda não está em execução.

Os aplicativos mais preocupantes para problemas de compatibilidade são aplicativos COM que já são iniciados por algum outro mecanismo, como o Windows Explorer ou o Service Control Manager. Você também pode iniciar esses aplicativos por uma ativação COM anterior, que substitui as permissões de acesso e inicialização padrão e especifica permissões de inicialização mais restritivas do que as permissões de chamada. Para obter mais detalhes sobre como resolver esse problema de compatibilidade, consulte "Como resolvo esses problemas?" na próxima seção.

Se um sistema atualizado para o Windows XP SP2 ou Windows Server 2003 SP1 for revertido para um estado anterior, qualquer ACE que tenha sido editado para permitir acesso local, acesso remoto ou ambos, será interpretado para permitir acesso local e remoto. Qualquer ACE que foi editado para negar acesso local, acesso remoto ou ambos é interpretado para negar acesso local e remoto. Sempre que você desinstalar um service pack, você deve garantir que nenhum ACEs recém-definido faça com que os aplicativos parem de funcionar.

Como resolver esses problemas?

Se você implementar um servidor COM e substituir as configurações de segurança padrão, confirme se a ACL de permissões de inicialização específicas do aplicativo concede permissão de ativação aos usuários apropriados. Caso contrário, você deverá alterar a ACL de permissão de inicialização específica do aplicativo para conceder direitos de ativação aos usuários apropriados para que aplicativos e componentes do Windows que usam DCOM não falhem. Essas permissões de inicialização específicas do aplicativo são armazenadas no Registro.

As ACLs COM podem ser criadas ou modificadas usando funções de segurança normais.

Quais configurações são adicionadas ou alteradas no Service Pack 2 do Windows XP?

Cuidado

O uso incorreto dessas configurações pode fazer com que aplicativos e componentes do Windows que usam DCOM falhem.

Na tabela a seguir, essas abreviações são usadas:

LL – Inicialização local

LA – Ativação local

RL – Inicialização remota

RA – Ativação remota

LC – Chamadas de acesso local

RC – Chamadas de acesso remoto

ACL – Lista de Controle de Acesso

Nome da configuração	Localização	Valor padrão anterior	Valor padrão	Valores possíveis
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos - LL, LA, RL, RA Anônimo- LL, LA, RL, RA (Esta é uma nova chave do Registro. Com base no comportamento existente, esses são os valores efetivos.)	Administrador: LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos - LC, RC Anônimo - LC, RC (Esta é uma nova chave do Registro. Com base no comportamento existente, esses são os valores efetivos.)	Todos: LC, RC Anônimo: LC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Não aplicável.	Essa chave do Registro não está presente; no entanto, uma chave ou valor ausente é interpretado como 2. Esse evento não é registrado por padrão. Se você alterar esse valor para 1 para começar a registrar essas informações para ajudá-lo a solucionar um problema, certifique-se de monitorar o tamanho do log de eventos, pois esse é um evento que pode gerar um grande número de entradas.	1 – Sempre registrar falhas no log de eventos durante uma chamada no processo do servidor COM. 2 – Nunca registre falhas no log de eventos durante uma chamada no processo do servidor de chamadas.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Não aplicável.	Essa chave do Registro não está presente; no entanto, uma chave ou valor ausente é interpretado como 1. Esse evento é registrado por padrão. Raramente deve ocorrer.	1 – Sempre registra falhas no log de eventos quando a infraestrutura COM encontra um descritor de segurança inválido. 2 – Nunca registre falhas no log de eventos quando a infraestrutura COM encontrar um descritor de segurança inválido.
Restrições de inicialização de DCOM:Machine na sintaxe SDDL (Security Descriptor Definition Language)	(Objeto Política de Grupo) Configuração do Computador \Configurações do Windows\Políticas Locais \Opções de Segurança	Não aplicável.	Não definido	Lista de controle de acesso no formato SDDL. A existência dessa política substitui valores em MachineLaunchRestriction, anteriormente.
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax	(Objeto Política de Grupo) Configuração do computador \Configurações do Windows \Políticas Locais \Opções de Segurança	Não aplicável.	Não definido	Lista de controle de acesso no formato SDDL. A existência dessa política substitui valores em MachineAccessRestriction, anteriormente.

Quais configurações são adicionadas ou alteradas no Windows Server 2003 Service Pack 1?

Nota

O uso incorreto dessas configurações pode fazer com que aplicativos e componentes do Windows que usam DCOM falhem.

Na tabela a seguir, essas abreviações são usadas:

LL – Inicialização local

LA – Ativação local

RL – Inicialização remota

RA – Ativação remota

LC – Chamadas de acesso local

RC – Chamadas de acesso remoto

ACL – Lista de Controle de Acesso

Nome da configuração	Localização	Valor padrão anterior	Valor padrão	Valores possíveis
MachineLaunchRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos: LL, LA, RL, RA Anônimo: LL, LA, RL, RA (Esta é uma nova chave do Registro. Com base no comportamento existente, esses seriam os valores efetivos.)	Administrador: LL, LA, RL, RA Todos: LL, LA Usuários com distribuídos: LL, LA, RL, RA	ACL
MachineAccessRestriction	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Todos: LC, RC Anônimo: LC, RC (Esta é uma nova chave do Registro. Com base no comportamento existente, esses seriam os valores efetivos.)	Todos: LC, RC Anônimo: LC, RC	ACL
CallFailureLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Não aplicável.	Essa chave do Registro não está presente; no entanto, uma chave ou valor ausente é interpretado como 2. Esse evento não é registrado por padrão. Se você alterar esse valor para 1 para começar a registrar essas informações para ajudá-lo a solucionar um problema, certifique-se de monitorar o tamanho do log de eventos, pois esse é um evento que pode gerar um grande número de entradas.	1 – Sempre registra falhas no log de eventos quando a infraestrutura COM encontra um descritor de segurança inválido. 2 – Nunca registre falhas no log de eventos quando a infraestrutura COM encontrar um descritor de segurança inválido.
InvalidSecurityDescriptorLoggingLevel	HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Ole	Não aplicável.	Essa chave do Registro não está presente; no entanto, uma chave ou valor ausente é interpretado como 1. Esse evento é registrado por padrão. Raramente deve ocorrer.	1 – Sempre registra falhas no log de eventos quando a infraestrutura COM encontra um descritor de segurança inválido. 2 – Nunca registre falhas no log de eventos quando a infraestrutura COM encontrar um descritor de segurança inválido.
Restrições de inicialização de DCOM:Machine na sintaxe SDDL (Security Descriptor Definition Language)	(Objeto Política de Grupo) Configuração do computador \Configurações do Windows \Políticas Locais \Opções de Segurança	Não aplicável.	Não definido.	Lista de controle de acesso no formato SDDL. A existência dessa política substitui valores em MachineLaunchRestriction, anteriormente.
DCOM:Machine Access Restrictions in Security Descriptor Definition Language (SDDL) Syntax	(Objeto Política de Grupo) Configuração do computador \Configurações do Windows \Políticas Locais \Opções de Segurança	Não aplicável.	Não definido.	Lista de controle de acesso no formato SDDL. A existência dessa política substitui valores em MachineAccessRestriction, anteriormente.

Tópicos relacionados

segurança do no COM